Skip to content
Commits on Source (2)
mesa (18.0.0~rc4-1ubuntu3) bionic; urgency=medium
* dont-enable-10bpc-by-default.diff: Replace the drirc hack, just flip
the default to not enable 10bpc configs by default for gallium drivers.
(LP: #1752123)
-- Timo Aaltonen <tjaalton@debian.org> Wed, 28 Feb 2018 19:34:58 +0200
mesa (18.0.0~rc4-1ubuntu2) bionic; urgency=medium
* control: Remove libtxc-* Recommends which were left over after a
......
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">
......@@ -9,4 +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
dont-enable-10bpc-by-default.diff