On Fri, 11 Feb 2011 13:16:38 +0100, Maarten Maathuis <madman2...@gmail.com> wrote: > 2011/2/11 Keith Packard <kei...@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.pack...@intel.com
pgpheWoW8fg0X.pgp
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
