On 2019-03-06 5:00 p.m., Adam Jackson wrote: > On Wed, 2019-03-06 at 15:52 +1100, Graeme Gill wrote: >> Adam Jackson wrote: >> >>> The second, which games typically use, is setting per-channel gamma >>> (implicitly for the whole screen) as single floating-point values with >>> the xf86vidmode extension. >> >> Typically this is too crude a control for color management use. >> My assumption (which could be wrong) is that this is overridden >> by the per-crtc LUT. > > Technically I think what happens is the vidmode gamma is applied to > RANDR's "compat" output, which is chosen by some handwavey heuristic.
Before xserver 1.19, the xf86VidMode per-X-screen ramp (with the global gamma value controlled by xgamma incorporated) and the RandR per-CRTC ramp were each directly applied to the hardware LUT for the RandR compatibility output without coordination, so whichever was set last stuck. (Colormaps were ineffective with RandR 1.2 capable drivers since xserver 1.7) As of xserver 1.19, if the Xorg driver calls xf86HandleColormaps(), all relevant mappings (colormap, global gamma, xf86VidMode per-X-screen ramp, RandR per-CRTC ramp) are composed, and the result is applied to the hardware LUT for all CRTCs. (A bug snuck into 1.19 which resulted in the composed mapping being incorrect for the RandR compatibility output between setting the global gamma value and setting the RandR per-CRTC ramp. This is fixed in 1.20.4) -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
