[PATCH xserver v2] xf86cmap: Use old palette system for pseudocolour.

[Maarten Maathuis]

2011/2/11 Keith Packard <keithp at keithp.com>:
> On Thu, 10 Feb 2011 15:23:27 -0800, Keith Packard <keithp at keithp.com> wrote:
>
>> I'm taking a look at this stuff to see if I can't at least figure out
>> how it's supposed to work. I don't want to ship half-a-fix when we know
>> it's broken, just not precisely how badly.
>
> Ok, upon further review, it seems that this patch:
>
>        Author: Maarten Maathuis <madman2003 at gmail.com>  2008-12-17 07:56:26
>        Committer: Maarten Maathuis <madman2003 at gmail.com>  2008-12-17 08:03:12
>        Parent: 1556815d34cecb4b4b62d2a4ce813b1435a937ec (Cygwin/X: Initialize native HWND atom when built !XWIN_MULTIWINDOWEXTWM)
>        Child:  bf65523ab0b39774f07a7ae478ff3f5653fad469 (Cygwin/X: Fix for mis-aligned icon data creates bad background masks (#4491))
>        Branches: many (259)
>        Follows: xorg-server-1.5.99.1
>        Precedes: xorg-server-1.6.99.900
>
>            randr: Improve per-crtc gamma support.
>
>            - The Gamma values from the monitor section are now used during initial config.
>            - The old colormap system is disabled when gamma set hook is available.
>            - Gamma values are now persistent for the lifetime of the xserver.
>            - This requires no driver changes and should be driver ABI compatible.
>
> might have benefitted from further review. This patch completely
> disables all colormaps for any driver supporting the CRTC-based gamma
> functions.
>
> This means that no visuals other than TrueColor will work
> correctly with the current code.
>
> Your patch will disable the RandR gamma code for pseudo-color screens,
> which isn't optimal either (although, probably better than the current
> situation).
>
> A 'correct' solution would merge the current colormap data with the
> per-crtc gamma data and store that using the new gamma LUT writing
> function (gamma_set). All of that code exists, in the old colormap code,
> except it uses the screen gamma table instead of the per-crtc one.
>
> That seems like a couple of hours of typing to me, at least.
>
> However, armed with this knowledge, I would suggest that a better
> short-term fix would be to re-enable the old colormap code for any
> hardware which is using something other than true color for the default
> visual. This will leave direct color visuals on 15/16/24 bit hardware
> broken, but at least it will let 8-bit hardware work again.
>
> --
> keith.packard at intel.com
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>

I'm willing to look at this again, but i can't give a timeframe right
now. So if anyone is in a rush or thinks he/she can fix this
relatively quickly, be my guest, otherwise i'll have a look again.

I'll admit i wasn't thinking about "odd" visuals when i did this and
at the time the review process of patches certainly wasn't what it is
today.

Maarten.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.