Bug 1086640 - modesetting driver for intel (Skylake) unusable for multi monitor due to tearing
modesetting driver for intel (Skylake) unusable for multi monitor due to tearing
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: X.Org
Other Other
: P3 - Medium : Enhancement (vote)
: ---
Assigned To: E-mail List
E-mail List
Depends on:
  Show dependency treegraph
Reported: 2018-03-23 10:19 UTC by Peter Sütterlin
Modified: 2019-02-26 11:22 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
sndirsch: needinfo? (P.Suetterlin)


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Sütterlin 2018-03-23 10:19:48 UTC
Because of some issues (boo#1042873) I had switched to using the intel driver for my Laptop (Lenovo T460p, Intel Skylake / HD530).  I switched back to modesetting yesterday, to verify that bug is fixed (it is ;^>).

However, for me the modesetting driver is unusable:  I have a dual monitor setup, the main laptop screen (2560x1440) and an external one (docking station, connected via DP), also 2560x1440 but rotated 90 degrees.
Desktop is Plasma, compositor enabled.
No matter what I enter for 'Tearing prevention' in the system settings for the Compositor, I get extremely strong tearing on both monitors.

The main laptop screen is basically divided by a diagonal, with the two halves not being in sync, on the secondary broad vertical(*) stipes (2-3 over the width)
(*)vertical on the rotated display

The tearing is not there in single monitor use.

The intel driver does not have problems with this.
Comment 1 Stefan Dirsch 2018-03-23 10:51:19 UTC
I'm afraid this is a feature request. There is no TearFree in modesetting driver yet. :-(


Not sure whether anybody is/was working on this already.
Comment 2 Max Staudt 2018-05-04 13:13:19 UTC
Hi Peter,

I'm trying to have a look at this. Unfortunately I'm not sure we can solve this issue ourselves, but hey, let's have a try.

Can you please help me a little further to reproduce your issue? Which desktop environment are you using? Certain compositors, such as the one in Xfce, are known to be unhelpful in the tearing department...
Comment 3 Max Staudt 2018-05-04 13:13:54 UTC
(In reply to Max Staudt from comment #2)
> Can you please help me a little further to reproduce your issue? Which
> desktop environment are you using? Certain compositors, such as the one in
> Xfce, are known to be unhelpful in the tearing department...

Argh, missed that it's Plasma. Thanks!
Comment 4 Max Staudt 2018-05-04 14:32:51 UTC
Hmm, I've tried this on a T450 (Intel Broadwell), and while I can see tearing, it's not the way you described it. I don't have a T460 here I'm afraid. It could well be a Skylake 

Maybe you could try recording it using a camera? Whether it is to be seen in the video is a wholly different question, of course.
Comment 5 Peter Sütterlin 2018-05-04 14:43:51 UTC
Hello Max,

thanks for taking time to look at this :)
During summer I work at a different place, where I don't have a regular secondary monitor.  I'll try to set up a similar configuration here one of the coming days (i.e., next week...) and try to record some movie with an external cam if I can reproduce it.  In any case I'll report back.


Comment 6 Max Staudt 2018-05-08 15:14:56 UTC
Hi Peter,

Since the upstream bug keeps referring people to the compositor, I've searched around for possible causes, and found a hint here:


First of all, please make sure that KWin's compositing is enabled, and that in the "Compositor" settins (right next to the display settings), "Tearing prevention ("vsync")" is actually enabled - if in doubt, try the setting "Full screen repaints".

If you go to the KDE settings > Displays, you can select a "Primary display". Can you experiment with different settings here? Setting the external 4K monitor that I've hooked up to the T450 here as primary helps a lot, at least on the external display. The reason behind this is that a generic hardware interface can only really sync to a single monitor, AFAIK.

Note on the radeon driver, which as mentioned in the upstream bug in Comment 1, has a TearFree option per output: That may be a hardware specific option, which the generic modesetting driver may never be able to implement.
Comment 7 Peter Sütterlin 2018-05-09 15:43:38 UTC
Hi Max,

I finally had some time to try a dualmon setup.  It is quite different from the old one though:  Here I only have a FHD HDMI monitor.  Th old setup had a same-sized monitor connected via DP on the dock.  As the dock doesn't have HDMI it is now connected to the laptop directly.

The tearing is still there, but has improved.  The most anoying one had been in the browser window when scrolling.  This is not really prominent anymore, but the diagonal line(s) can still be seen when slide-changing the desktop.

Full Screen repaints:  I am quite sure I had tried that in the old configuration, and it did not improve things.  Also now, I don't see a real change in tearing whether it is on or off.
I also tried changing the primary display now, but again no change.

On the bad side, now I (sometimes) get strange color artifacts around windows when changing the focus (I use follow mouse, so just moving the cursor around across various windows is enough to trigger it).  This happens on both monitors but not when only one is connected (I'm running modesetting as default, with only one monitor it is having no issues for me at all).

Recording things with an external camera so far was not successful, that's why I tried to describe things....

Yes, as Stefan mentioned in Comment #1 adding the TearFree to the driver, like radeon and nvidia have,  is what is likely the only cure for this.
Comment 8 Stefan Dirsch 2018-06-05 15:31:28 UTC
JFYI, there is an external composition manager called 'compton' which is supposed to be much better than the builtin composition manager of XFCE (and maybe also better than the builtin one of KDE) with aspect to TearFree. So try disabling the builtin one and give compton a try.
Comment 9 Stefan Dirsch 2019-01-24 04:11:05 UTC
Just stumbled across this hint:

If you use Plasma you might get corrupted flickering display. To fix this make sure to disable vsync in the Plasma compositor settings first. Vsync will be handled by the intel driver.

Maybe this helps ...
Comment 10 Peter Sütterlin 2019-01-24 09:25:03 UTC
Thanks for the Tip Stefan!

... and for the reminder about this report.  I'm back to the other location since two weeks and wanted to come back on this myself.

So the first report is that things seem to have improved, at least I did find the flickering (while still present) less disturbing now - it's basically only strong during the slide animation when switching virtual desktops.  Not sure if there had been any changes in the code, or whether it's just me sensing it differently...

About the tip itself:  I tried it.  The vsync was set to 'Automatic', so I switched to 'Never', but couldn't see any difference.  Then I noticed that it seems to be a tip for the Intel driver, not for modesetting :o
Comment 11 Stefan Dirsch 2019-01-24 10:27:29 UTC
Yes, should have emphasized that. The tip is for intel X driver, not modesetting. There is still no tearfree available for modesetting.
Comment 12 Stefan Dirsch 2019-01-26 19:25:05 UTC
Also there was an update for Qt, which has fixed such flickering issues as well.
Please give the tip on intel a try. And also the QT fix.
Comment 13 Peter Sütterlin 2019-01-28 14:00:45 UTC
OK, I just did an update to current TW (20190125), and also installed the xf86-video-intel driver (2.99.917+git8674.25c9a2fcc-1.1).

Two disclaimers:
 - I did not have problems with tearing with the intel driver initially (see 
   first post), and 
 - I did (only) use modesetting in the last ~9 months.  So no good comparison 

That said: I rebooted after the update, so using the intel driver.  I could see some flicker in fast redrawing applications (gkrellm) during desktop change 'slide' animation.  I then switched the compositor vsync from 'Automatic' to 'Never'.  I did not see the flicker after that.  So I'd assume that tip does help.  However, I then switched back to automatic, and still got no flicker.  But maybe the intel tearing prevention was still active after that?
I noticed that when I set vsync to 're-use screen content' my gkrellm wouldn't properly update anymore unless the cursor is in it's area.  Other modes seemed to work.

As for the modesetting:  I then restarted X using ms.  No change to previous behavior.  Tearing is still there with all settings in the compositor.  The QT fix wouldn't need any user interaction, is it?
Comment 14 Stefan Dirsch 2019-01-28 14:45:15 UTC
Thanks for the feedback. For the QT fix to apply you would need update the QT package with the fix. Where to find it? Honestly I don't know. I no longer find the bugreport for it. :-(
Comment 15 Stefan Dirsch 2019-02-26 11:22:27 UTC
Ok. Let's close the bug as fixed assuming the QT fix works for you. It should be in TW meanwhile. Otherwise please feel free to reopen and I will add our Qt maintainers. They might be able to find the bugreport again.