Fix colormaps with RandR 1.2 capable Xorg drivers

[Michel Dänzer]

On 30.07.2014 19:07, Michel Dänzer wrote:
> On 25.07.2014 03:21, Isaac Kamga wrote:
>>
>> I am Computer Science major who is interested in fixing color maps with
>> Rand 1.2 capable Xorg drivers.
> 
> Great! Things like gamma correction in SDL based games has been broken
> for too long.
> 
> 
>> I have a faint idea of color maps and look-up tables but I need some
>> pointers to more concrete information on this project so I get started
>> developing my EVoC project proposal.
> 
> I don't have much time right now, but have you read the mailing list
> thread around
> http://cgit.freedesktop.org/xorg/xserver/commit/?id=91f73b79b7ae64e5b846d1efeb470bb61a913720
> and looked at the Git commit
> http://cgit.freedesktop.org/xorg/xserver/commit/?id=91f73b79b7ae64e5b846d1efeb470bb61a913720
> which introduced the problem? Hopefully those should give you some idea
> of why things are broken, I'll get back to answering any questions you
> have about that and providing more pointers ASAP.

Basically, the problem is that the commit above simply disables the
colormap related code in hw/xfree86/common/xf86cmap.c (and the gamma
related code in hw/xfree86/common/xf86Helper.c) if the video driver
provides the per-CRTC gamma_set() hook.

However, the RandR 1.2 code in hw/xfree86/modes/xf86Crtc.c and
hw/xfree86/modes/xf86RandR12.c, which calls the gamma_set() hook,
doesn't take the current colormap (or the global gamma ramp) into
account but just directly sets the RandR 1.2 per-CRTC gamma ramp to the
hardware. This can only work correctly for apps using a TrueColor
visual, where there is no colormap which can change the intended
appearance of the pixel values.

The solution is to make the RandR 1.2 code aware of the current
colormap, combining it with the per-CRTC gamma ramp before calling the
gamma_set() hook such that the colour defined by the colormap appears as
modified according to the per-CRTC gamma ramp. Ideally, the global gamma
ramp should be factored in as well, probably by combining it with the
per-CRTC gamma ramp and then the combined gamma ramp with the colormap.

The RandR 1.2 code may also need to be hooked up to more places such
that it will update the per-CRTC hardware LUTs on changes to the
colormap or global gamma ramp.

Keith Packard might have more specific suggestions how the RandR 1.2
code and the colormap code need to interact.


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer