[PATCH xserver v2] xf86cmap: Use old palette system for pseudocolour.
Maarten Maathuis
madman2003 at gmail.com
Fri Feb 11 11:00:13 PST 2011
On Fri, Feb 11, 2011 at 7:53 PM, Keith Packard <keithp at keithp.com> wrote:
> On Fri, 11 Feb 2011 13:16:38 +0100, Maarten Maathuis <madman2003 at gmail.com> wrote:
>> 2011/2/11 Keith Packard <keithp at keithp.com>:
>
>> 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.
>
> I think the main issue is that the 'RandR' code lives in parallel with
> the 'classic' code and so we end up supporting essentially two driver
> stacks at this point. At some point, it would be lovely to figure out a
> plan to clean all of this up.
>
> The basic problem is that the driver now exposes two parallel colormap
> setting APIs -- the per-CRTC 'gamma_set' function and the per-screen
> 'LoadPalette' function. Neither of these is the right API -- gamma_set
> loads the whole colormap instead of just a piece (which would make
> StoreColors really slow). The DRM kernel interface also deals only with
> the whole colormap though.
>
> Go check out I830LoadPalette though -- as far as I can tell, it only
> works when called to write the whole colormap, so it should only work
> for StaticGray, StaticColor and TrueColor. Any other visual type will
> cause uninitialized values to get loaded into the LUT.
There are dynamic colormaps?
>
> To recap, it looks like fixing this requires:
>
> 1) Fixing the gamma_set driver API to deal with partial updates. I'd
> suggest that we add a new driver API (set_lut) that provides for
> partial LUT writes and emulating that with gamma_set for existing
> drivers. We can consider renaming 'get_gamma' at some point, but
> I don't see any reason to change its signature.
>
> 2) Emulate the new 'set_lut' function on drivers that don't support it
> by calling the existing LoadPalette function when asked to write
> values to the 'compat_output' crtc.
>
> 3) Rewrite the existing colormap code to do per-crtc LUT computations
> and use the 'set_lut' function to write those to the hardware.
>
> Drivers can be migrated to the 'set_lut' API once we fix the kernel API
> to support partial LUT updates.
>
> I'd love to hear a simpler plan...
>
> --
> keith.packard at intel.com
>
--
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.
More information about the xorg-devel
mailing list