debian/changelog

-mesa (18.0.0~rc4-1ubuntu2) UNRELEASED; urgency=medium
+mesa (18.0.0~rc4-1ubuntu2) bionic; urgency=medium
 
   * control: Remove libtxc-* Recommends which were left over after a
     merge.
+  * dont-expose-10bpc-to-gnome-shell.diff: Add a workaround to not use
+    10bit RGB config with gnome-shell, until mutter is fixed. (LP:
+    #1752123)
 
- -- Timo Aaltonen <tjaalton@debian.org>  Sun, 18 Feb 2018 19:26:10 +0200
+ -- Timo Aaltonen <tjaalton@debian.org>  Wed, 28 Feb 2018 13:55:43 +0200
 
 mesa (18.0.0~rc4-1ubuntu1) bionic; urgency=medium
 

debian/patches/dont-expose-10bpc-to-gnome-shell.diff

+From cf1b6bf1faf973afb61c80376ae067d2048a535b Mon Sep 17 00:00:00 2001
+From: Mario Kleiner <mario.kleiner.de@gmail.com>
+Date: Thu, 24 Aug 2017 14:20:54 +0200
+Subject: [PATCH 1/2] drirc: Don't expose 10 bpc visuals/configs to
+ gnome-shell. (v2)
+
+Set 'allow_rgb10_configs' false when gnome-shell is the
+client.
+
+Gnome-Shell/Wayland (= Mutter drm/kms wayland backend)
+currently can't handle non RGB8 configs. It will treat
+any framebuffer as RGBX8 or RGBA8, so if provided with
+a RGB10A2 or RGB10X2 framebuffer, the compositors
+kms backend will simply pass it to the kernel as RGBX8
+for scanout, resulting in false colors.
+
+Gnome-Shell/X11 displays 10 bpc drawables correctly without
+any color artifacts if X-Screen DefaultDepth 30 is set.
+
+Both Gnome-Shell Wayland and X11 for some reason seem to
+have problems with hit-testing for RGB10 modes, making them
+almost unusable: Neither context menus (right mouse click)
+on the desktop, nor the icons in the dock, nor any part of
+the menu bar at the top, nor any icons on the desktop,
+respond to any mouse clicks. The same problem appears for
+window decorations (resize, move, close of windows via mouse
+impossible).
+
+The same problem happens when testing with the amdgpu-pro
+proprietary OpenGL library in "DefaultDepth 30" mode, and
+with the NVidia proprietary driver with depth 30 mode, so
+this seems to be a problem inside Gnome-Shell, not in Mesa,
+X or Wayland.
+
+Not exposing RGB10 configs keeps Gnome-Shell usable, and
+still allows other X-Clients to do RGB10 rendering if X
+"DefaultDepth 30" is selected.
+
+No such problems happened under Gnome flashback session
+(Metacity), or with Compiz based UI's, or under KDE-5 with
+or without compositing.
+
+The most likely culprit is to be found in clutters picking
+code, which is based on rendering color coded "actor" id's
+to some framebuffer, then later reading it back at the
+(x,y) picking position and decoding into actor id's again.
+
+Possible starting points / culprits for debugging this:
+
+https://github.com/GNOME/clutter/blob/master/clutter/clutter-stage.c
+_clutter_stage_do_pick(),
+
+and
+
+https://github.com/GNOME/clutter/blob/master/clutter/clutter-main.c
+_clutter_pixel_to_id() and _clutter_id_to_color()
+
+v2: Renamed option from expose_rgb10_configs to allow_rgb10_configs.
+    Add some hints to the possible location of the clutter problems.
+
+Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
+---
+ src/util/drirc | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/src/util/drirc
++++ b/src/util/drirc
+@@ -166,6 +166,9 @@ TODO: document the other workarounds.
+ 
+         <application name="Observer" executable="TheObserver-Linux-Shipping">
+             <option name="allow_glsl_cross_stage_interpolation_mismatch" value="true"/>
++
++        <application name="gnome-shell" executable="gnome-shell">
++            <option name="allow_rgb10_configs" value="false"/>
+         </application>
+ 
+         <application name="Steamroll" executable="Steamroll-Linux-Shipping">

debian/patches/series

@@ -9,3 +9,4 @@ egl-platform-mir.patch
 egl-platform-rs.patch
 khr_platform_mir.patch
 dri3-reinstate-get_dri_screen-callback.diff
+dont-expose-10bpc-to-gnome-shell.diff