On Tue, 27 Jul 2010 11:03:56 -0400 Adam Jackson <a...@redhat.com> wrote:
> On Fri, 2010-07-23 at 16:29 -0400, Andrew Lutomirski wrote: > > > Does that include not breaking DirectColor? If we program the gamma > > ramp to 129 slots, old userspace submits 256 entries that are not > > monotonic, and we decimate the gamma ramp, we'll display the wrong > > thing. I have no idea if there are any programs *at all* that do > > that, though. (If they did, presumably they'd make the entire screen > > look rather odd.) > > If I'm remembering this right, it's like this: > > GM45 and earlier can only do 10bpc with 10-bit, 129-stop interpolated > LUT. There is no way to support DirectColor with this, the hardware > assumes that each step is monotonically increasing and will do very > weird things if it's not. So the DDX driver needs to simply not set up > any DC visuals when run at 10bpc on this hardware. That's fine though: > DC is a pretty rarely-used feature, and it brings with it all the > colormap-flashing nightmares you remember from pseudocolor. > > Ironlake and later can do 30bpc as either 10-bit 1024-stop, or 12-bit > 512-stop interpolated. For the 12-bit ramp you'd need to do the same as > for the GM45 10-bit ramp: DDX driver doesn't set up DC visuals. > > Once you've done this, the DRM driver can unambiguously determine what > gamma ramp size to use based on what DDX passes down. At least in > current RANDR you only get to pick one ramp size. You could in > principle wire up an output property to change this, but I suggest that > you don't bother. > > There are some places in the server where we assume 256 stops, and some > other places where we make the weaker assumption that all CRTCs have the > same ramp size. > > Having done all that you'd need to go out to gnome-color-manager and > friends and make sure they don't assume they have 2^n stops of gamma for > an n bpc display. [Resurrecting this ancient thread now that 30bpp has been posted] I think we'll also want a kernel getparam flag to indicate whether the kernel can handle the larger ramp sizes, otherwise a new DDX and old kernel will silently break horribly. Current DDX always assumes a 256 entry ramp, and we'd want to preserve that for old kernels w/o support for other sizes. For new DDX and new kernel, we should be able to key the palette load based on the size passed in to the gamma_set callback. For some reason that callback includes a 'start' value, but fortunately the ioctl makes you load the whole thing everytime, so the start value is always 0. Sounds like dealing with chipset variations will be a bit of a pain though, so we'll want per-chipset gamma_set functions at least. Andrew, do you have anything hacked together for this yet? Thanks, -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
