Bug 1120172 - KDE Plasma screen tearing in X11 with Intel GPU
Summary: KDE Plasma screen tearing in X11 with Intel GPU
Status: RESOLVED DUPLICATE of bug 1120090
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: X.Org (show other bugs)
Version: Current
Hardware: x86-64 openSUSE Factory
: P3 - Medium : Major with 7 votes (vote)
Target Milestone: ---
Assignee: E-mail List
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-21 08:16 UTC by Yunhe Guo
Modified: 2019-01-25 08:28 UTC (History)
6 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Video camera recording (854.62 KB, video/webm)
2019-01-05 17:36 UTC, Yunhe Guo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yunhe Guo 2018-12-21 08:16:28 UTC
The screen tearing happens after recent snapshot update 2018-12-19. This makes the system totally unusable.

It only happens in KDE Plasma X11 session with Intel GPU.

It doesn't happen in KDE Plasma Wayland session or with AMD GPU.

My CPU is Intel Core i7-4710HQ. My GPU is Intel HD Graphics 4600.
Comment 1 Yunhe Guo 2018-12-21 08:19:53 UTC
Video record of screen tearing is here: https://www.reddit.com/r/kde/comments/a8239k/kde_x11_starts_to_flicker_today_but_wayland_works/
Comment 2 Roger Larsson 2019-01-05 12:55:58 UTC
Did also see this problem (but only on second concurrent session), but a later upgrade fixed it.
Comment 3 Stefan Dirsch 2019-01-05 15:04:03 UTC
Sorry, the reddit Video doesn't work for me? Could you attach it to this bugreport instead? Thanks!
Comment 4 Yunhe Guo 2019-01-05 17:36:13 UTC
Created attachment 793713 [details]
Video camera recording
Comment 5 Yunhe Guo 2019-01-05 17:40:36 UTC
The uploaded attachment seems incomplete. I also tried to upload to YouTube https://youtu.be/2nOPeLQlRcg

The only solution I found is to remove package xf86-video-intel.
Comment 6 Stefan Dirsch 2019-01-05 17:55:34 UTC
(In reply to Yunhe Guo from comment #5)
> The uploaded attachment seems incomplete. I also tried to upload to YouTube
> https://youtu.be/2nOPeLQlRcg
> 
> The only solution I found is to remove package xf86-video-intel.

Well, we no longer install this package by default for Intel GPUs Gen >=4. You have Haswell, which is I believe Gen 8 or alike.
Comment 7 Yunhe Guo 2019-01-05 18:01:55 UTC
(In reply to Stefan Dirsch from comment #6)
> Well, we no longer install this package by default for Intel GPUs Gen >=4.
> You have Haswell, which is I believe Gen 8 or alike.

I might install the package manually before. So it is still in my system.
Comment 8 Stefan Dirsch 2019-01-05 18:11:46 UTC
(In reply to Yunhe Guo from comment #7)
> (In reply to Stefan Dirsch from comment #6)
> > Well, we no longer install this package by default for Intel GPUs Gen >=4.
> > You have Haswell, which is I believe Gen 8 or alike.
> 
> I might install the package manually before. So it is still in my system.

I know. And thanks for the Youtube video!
Comment 9 S. B. 2019-01-16 20:32:27 UTC
My report #1122227 is probably a duplicate of this.

(In reply to Stefan Dirsch from comment #6)
> > The only solution I found is to remove package xf86-video-intel.
> 
> Well, we no longer install this package by default for Intel GPUs Gen >=4.
> You have Haswell, which is I believe Gen 8 or alike.

Interesting, so openSUSE now defaults to X modesetting for Intel?
Comment 10 Felix Miata 2019-01-16 21:35:00 UTC
(In reply to S. B. from comment #9)
> Interesting, so openSUSE now defaults to X modesetting for Intel?

Fedora did it 2 years ago.

Debian did it 30 months ago.

I did it on all my openSUSEs 2 years ago, except for those too old for modesetting support.
Comment 11 Michael Pujos 2019-01-16 22:03:30 UTC
xf86-video-intel works very well on my UHD 630.
It seems to enable TearFree by default (which works great) allowing
to not have to use a compositor in simple environments such as i3wm or just using a Window Manager.
Comment 12 S. B. 2019-01-16 22:08:17 UTC
(In reply to Michael Pujos from comment #11)
> xf86-video-intel works very well on my UHD 630.
> It seems to enable TearFree by default (which works great) allowing
> to not have to use a compositor in simple environments such as i3wm or just
> using a Window Manager.

Yes, the serious bugs with xf86-video-intel seem to pop up mainly with Plasma's compositor.
https://forum.kde.org/viewtopic.php?t=127575
Who knows who really is at fault, Plasma devs tend to blame xf86-video-intel for having subtle bugs that only the Plasma compositor manages to reveal.
Comment 13 Michael Pujos 2019-01-16 22:16:44 UTC
(In reply to S. B. from comment #12)

> Yes, the serious bugs with xf86-video-intel seem to pop up mainly with
> Plasma's compositor.
> https://forum.kde.org/viewtopic.php?t=127575
> Who knows who really is at fault, Plasma devs tend to blame xf86-video-intel
> for having subtle bugs that only the Plasma compositor manages to reveal.

Actually it can work perfectly without glitches in Plasma, but you have to set 'Tearing prevention ("vsync")' to 'Never' in Plasma Compositor settings.
Basically you disable vsync in the compositor and let the Intel driver handle it. Otherwise they seem to fight each other resulting in a corrupted display.
Comment 14 S. B. 2019-01-16 22:36:15 UTC
(In reply to Michael Pujos from comment #13)
> (In reply to S. B. from comment #12)
> > xf86-video-intel
>
> Actually it can work perfectly without glitches in Plasma, but you have to
> set 'Tearing prevention ("vsync")' to 'Never' in Plasma Compositor settings.
> Basically you disable vsync in the compositor and let the Intel driver
> handle it. Otherwise they seem to fight each other resulting in a corrupted
> display.

Interesting tip! Thanks, I'll have to try that.
Comment 15 Wolfgang Bauer 2019-01-17 12:27:11 UTC
This is probably related to bug#1120090.
Comment 16 Stefan Dirsch 2019-01-24 04:18:38 UTC
(In reply to S. B. from comment #14)
> (In reply to Michael Pujos from comment #13)
> > (In reply to S. B. from comment #12)
> > > xf86-video-intel
> >
> > Actually it can work perfectly without glitches in Plasma, but you have to
> > set 'Tearing prevention ("vsync")' to 'Never' in Plasma Compositor settings.
> > Basically you disable vsync in the compositor and let the Intel driver
> > handle it. Otherwise they seem to fight each other resulting in a corrupted
> > display.
> 
> Interesting tip! Thanks, I'll have to try that.

NEEDINFO
Comment 17 Michael Pujos 2019-01-24 13:18:04 UTC
I can confirm this bug is fixed as of today by the latest TW snapshot with this:

==== kwin5 ====
Subpackages: kwin5-lang

- Add patch to force initialization of OpenGL to fix flickering
(boo#1120090, QTBUG-73122):
* 0001-Fix-flickering-with-Qt-5.12.patch



So I think you can close this bug as fixed.
Comment 18 S. B. 2019-01-24 14:02:26 UTC
(In reply to Stefan Dirsch from comment #16)
> (In reply to S. B. from comment #14)
> > (In reply to Michael Pujos from comment #13)
> > > (In reply to S. B. from comment #12)
> > > > xf86-video-intel
> > >
> > > Actually it can work perfectly without glitches in Plasma, but you have to
> > > set 'Tearing prevention ("vsync")' to 'Never' in Plasma Compositor settings.
> > > Basically you disable vsync in the compositor and let the Intel driver
> > > handle it. Otherwise they seem to fight each other resulting in a corrupted
> > > display.
> > 
> > Interesting tip! Thanks, I'll have to try that.
> 
> NEEDINFO

Still on TW 20190115 this is what I found:

- Xmodesetting + openGL 3.1 + tearing prevention (auto) = good
- Xmodesetting + openGL 3.1 + tearing prevention (never) = large black glitches
- Xmodesetting + openGL 2.0 + tearing prevention (never) = good
- xf86-video-intel + openGL 2.0 or 3.1 + tearing prevention (never) = good
Comment 19 Stefan Dirsch 2019-01-24 14:28:46 UTC
Interesting. How did you switch between OpenGL 2.0 and 3.1?
Comment 20 Michael Pujos 2019-01-24 14:54:24 UTC
(In reply to S. B. from comment #18)
> (In reply to Stefan Dirsch from comment #16)
> > (In reply to S. B. from comment #14)
> > > (In reply to Michael Pujos from comment #13)
> > > > (In reply to S. B. from comment #12)
> > > > > xf86-video-intel
> > > >
> > > > Actually it can work perfectly without glitches in Plasma, but you have to
> > > > set 'Tearing prevention ("vsync")' to 'Never' in Plasma Compositor settings.
> > > > Basically you disable vsync in the compositor and let the Intel driver
> > > > handle it. Otherwise they seem to fight each other resulting in a corrupted
> > > > display.
> > > 
> > > Interesting tip! Thanks, I'll have to try that.
> > 
> > NEEDINFO
> 
> Still on TW 20190115 this is what I found:
> 
> - Xmodesetting + openGL 3.1 + tearing prevention (auto) = good
> - Xmodesetting + openGL 3.1 + tearing prevention (never) = large black
> glitches
> - Xmodesetting + openGL 2.0 + tearing prevention (never) = good
> - xf86-video-intel + openGL 2.0 or 3.1 + tearing prevention (never) = good

The fix I mentioned is in TW 20190121 released today so you may want to try it.
Comment 21 Michael Pujos 2019-01-24 14:57:40 UTC
> The fix I mentioned is in TW 20190121 released today so you may want to try
> it.


Specifically for me:

xf86-video-intel + openGL 2.0 + tearing prevention (auto) = good

Previously it had large black glitches.
Comment 22 S. B. 2019-01-24 15:15:24 UTC
(In reply to Stefan Dirsch from comment #19)
> Interesting. How did you switch between OpenGL 2.0 and 3.1?

https://i.imgur.com/09Vjqfn.png
Comment 23 S. B. 2019-01-24 15:31:52 UTC
(In reply to Michael Pujos from comment #20)

> > 
> > Still on TW 20190115 this is what I found:
> > 
> > - Xmodesetting + openGL 3.1 + tearing prevention (auto) = good
> > - Xmodesetting + openGL 3.1 + tearing prevention (never) = large black
> > glitches
> > - Xmodesetting + openGL 2.0 + tearing prevention (never) = good
> > - xf86-video-intel + openGL 2.0 or 3.1 + tearing prevention (never) = good
> 
> The fix I mentioned is in TW 20190121 released today so you may want to try
> it.

Thanks, the fix seems to work. Now I'm using xf86-video-intel + openGL 3.1 + tearing prevention (Automatic) and I haven't seen any glitches yet.
Comment 24 Stefan Dirsch 2019-01-24 16:40:26 UTC
Thanks to everyone helping to fix this issue!
Comment 25 S. B. 2019-01-24 16:47:18 UTC
(In reply to Stefan Dirsch from comment #24)
> Thanks to everyone helping to fix this issue!

Yes, I neglected to say this, many thanks for the fix!
Comment 26 Wolfgang Bauer 2019-01-25 08:28:29 UTC
(In reply to Michael Pujos from comment #17)
> I can confirm this bug is fixed as of today by the latest TW snapshot with
> this:
> 
> ==== kwin5 ====
> Subpackages: kwin5-lang
> 
> - Add patch to force initialization of OpenGL to fix flickering
> (boo#1120090, QTBUG-73122):
> * 0001-Fix-flickering-with-Qt-5.12.patch
> 
> 
> 
> So I think you can close this bug as fixed.

Let's mark it as duplicate then...

*** This bug has been marked as a duplicate of bug 1120090 ***