FS#58012 - [mesa/compton] severe display corruption

Attached to Project: Community Packages
Opened by Ng Oon-Ee (ngoonee) - Thursday, 29 March 2018, 02:56 GMT
Last edited by Alexander F. Rødseth (xyproto) - Wednesday, 09 May 2018, 09:30 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Andreas Radke (AndyRTR)
Alexander F. Rødseth (xyproto)
Laurent Carlier (lordheavy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No


My regular [testing] update today brought in a new version of mesa, and my display is severely corrupted. The desktop wallpaper displays perfectly, but all 'active' components such as my terminal (termite), awesomewm components like the status tray and wibars, and applications (e.g. chromium) show corruption. Looks like an 80s era display, various shades of pink and horrendously under-resolution. VTs don't show that issue, and downgrading mesa alone fixes it.

My system is a HP Envy 13 running on Intel graphics (with nvidia's MX150 via bumblebee but that may not be relevant). Using X11 obviously (awesomewm).

Additional info:
* package version(s)
mesa-18.0.0-1 (last known working version on my machine was 17.3.7-1)
* config and/or log files etc.

Steps to reproduce:
Just restart X with the bad version of mesa. Downgrading mesa alone fixes it (other updates like harfbuzz, lightdm, linux, and vulkan-intel not downgraded).
This task depends upon

Closed by  Alexander F. Rødseth (xyproto)
Wednesday, 09 May 2018, 09:30 GMT
Reason for closing:  Fixed
Comment by Ng Oon-Ee (ngoonee) - Thursday, 29 March 2018, 03:08 GMT
Realized I forgot to report something possibly related, I'm running a Kaby Lake R i7 processor.
Comment by kinodont (kinodont) - Thursday, 29 March 2018, 06:36 GMT
Do you use compton as your X compositor?
If so, try terminating it (`killall compton`) while you're in the X11 session that's having the graphic corruption issues.
If the corruption is gone, try using a different compton backend like `compton --backend xr_glx_hybrid`.
Comment by Andreas Radke (AndyRTR) - Thursday, 29 March 2018, 07:42 GMT
I can confirm that using a different backend fixes dosplay corruptions for me too. Not sure, if this is a bug in new mesa or in compton.
Comment by kinodont (kinodont) - Thursday, 29 March 2018, 08:58 GMT
The bug is actually already reported upstream:

Starting compton like this: `env allow_rgb10_configs=false compton --backend glx` gets rid of the screen corruption for me as well.
Comment by Ng Oon-Ee (ngoonee) - Monday, 02 April 2018, 03:26 GMT
I can confirm that the source is compton.
Comment by Matalonder (Matalonder) - Friday, 27 April 2018, 20:38 GMT
This is now fixed in Compton upstream, I think. I installed compton-git from AUR and it works fine.
Comment by Eli Schwartz (eschwartz) - Tuesday, 01 May 2018, 13:54 GMT
@Matalonder, this package is already pinned to the current latest commit in compton, probably due to the fact that upstream has not released a new version in nearly five years -- and the last non-README change was two years ago.

The upstream bugreport linked two comments above yours indicates compton needs changes to support rbg10, which it does not currently do, so there is no way compton-git fixed it for you unless you never had the problem to begin with or forgot to mention that you also changed compton to run with that environment variable workaround.

https://github.com/yshui/compton/commit/bf29b2dd37dc5a35c0387bd21e67226d8aa23790 tries to do the same workaround within compton itself, and is mentioned in the upstream issue.
Comment by Alexander F. Rødseth (xyproto) - Monday, 07 May 2018, 09:52 GMT
Thanks for reporting.

I switched the package over to the yshui/compton repository, which includes this commit:

Avoid using 10bit FBConfigs
Fix weird color issue with Mesa 18.0

The updated package will appear in [community] any second now. Please test.