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

Keith Packard keithp at keithp.com
Fri Feb 11 10:53:34 PST 2011


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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110211/df6ff77c/attachment.pgp>


More information about the xorg-devel mailing list