Bug 384882 - Rendering broken after fbconfig visual matching change in XServer
Summary: Rendering broken after fbconfig visual matching change in XServer
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Plasma
Component: platform-x11-standalone (show other bugs)
Version: 5.10.5
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-20 13:49 UTC by Nick Sarnie
Modified: 2017-10-04 15:56 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
good (64.19 KB, image/png)
2017-09-20 13:49 UTC, Nick Sarnie
Details
bad (60.86 KB, image/png)
2017-09-20 13:49 UTC, Nick Sarnie
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Sarnie 2017-09-20 13:49:31 UTC
Created attachment 107913 [details]
good

Hi all,

After Xserver git commit 4486d199bd3bcb5b2b8ad9bc54eb11604d9bd653, the fbconfig visual matching system has changed. This results in incorrect rendering when KWin compositing is enabled. The Xorg developer has reproduced the issue but believes this is a Kwin application bug.

Here is the original xorg bug report: https://bugs.freedesktop.org/show_bug.cgi?id=102806

I am using Mesa on Radeonsi, and both the OpenGL3.1 and 2.0 backends have the same corruption, while the Xrender option is still incorrect, but the incorrect color is a bit less notable.

Please see the attachments for the good and bad behavior.

I can provide any more information, and test any patches.

Thanks,
Sarnex
Comment 1 Nick Sarnie 2017-09-20 13:49:42 UTC
Created attachment 107914 [details]
bad
Comment 2 Martin Flöser 2017-09-20 14:50:10 UTC
could you please try to use the OpenGL/ES compositor? Run:
KWIN_COMPOSE=O2ES kwin_x11 --replace
Comment 3 Nick Sarnie 2017-09-20 22:51:16 UTC
(In reply to Martin Flöser from comment #2)
> could you please try to use the OpenGL/ES compositor? Run:
> KWIN_COMPOSE=O2ES kwin_x11 --replace

Hi Martin,

Same exact color corruption as the normal OpenGL compositor.

Thanks,
Sarnex
Comment 4 Martin Flöser 2017-09-21 15:57:07 UTC
Now I'm tempted to say that's not a bug in our code. It means that both our EGL and GLX code is affected which have different implementations. That just cannot be a problem on our side.

Especially if we now change the code to make it work with the new X Server, how would we ensure it also works with the old one? No, no, that must be fixed in X.
Comment 5 Nick Sarnie 2017-09-21 17:42:03 UTC
(In reply to Martin Flöser from comment #4)
> Now I'm tempted to say that's not a bug in our code. It means that both our
> EGL and GLX code is affected which have different implementations. That just
> cannot be a problem on our side.
> 
> Especially if we now change the code to make it work with the new X Server,
> how would we ensure it also works with the old one? No, no, that must be
> fixed in X.

Okay, I'll report this back to Thomas.
Comment 6 Christoph Feck 2017-10-04 15:56:55 UTC
Bug is assigned to upstream (link in comment #0).