30-bit Deep Color For GNOME On Wayland Will Likely Take Some Time

As written about at the start of the month, well known GNOME contributor Daniel van Vugt of Canonical/Ubuntu has added tackling deep color support to his TODO list for being able to properly handle 30-bit color on the desktop.

Last week he opened a merge request that would remove the hard-coded selection of the XRGB8888 GBM format so instead EGL could gracefully choose the highest color depth.

Daniel noted with that merge request, "In practice this means most systems should now get 30-bit color instead of 24-bit...There is no change in memory bandwidth requirements since both the old and new formats are 4 bytes per pixel. Compositing of native Wayland GL clients is made slightly faster and more efficient using 30-bit because they already default to XR30 or AR30 formats when possible. Only legacy Xwayland clients and most SHM clients still using 24-bit color will see slightly slower compositing."

But in the comments to that merge request was a bit of a dust up between developers. In particular, there is hard-coded formats elsewhere throughout the stack that need to be addressed. Red Hat's Jonas Ådahl argued that the approach is wrong due to this merge request alone would present multiple regressions elsewhere and those other areas should first be addressed and tested.

Jonas then marked the code as work-in-progress "as it is guaranteed to break things, and is incomplete." Before he will let the code land, Daniel or others first need to make sure the other areas are handled right with their pixel format handling and ensuring the primary plane supports the desired format and ensuring the dependent software is still gracefully running.

Long story short, the 30-bit deep color support won't be ready in time for next month's GNOME 3.38 release and will likely be a while longer before everything is squared away.