rfc: breaking old userspace gamma for 10-bit support

rfc: breaking old userspace gamma for 10-bit support

[Andrew Lutomirski]

AFAICT intel hardware wants a 129-entry LUT when using high precision
gamma ramps.  Rather than hacking some kind of decimation into the
kernel driver (and thus silently breaking DirectColor), I'd like to
teach userspace how to deal with variable gamma sizes.

gnome-color-manager already more-or-less supports arbitrary gamma ramp
sizes (supposedly), dispwin ought to do it, and there might not be any
other software that really cares.  gnome-screensaver saves and
restores the gamma ramp, and I haven't checked if it works right for
funny sizes.

The worst problem we'll have is that current xf86-drv-intel can't
handle non-256 gamma sizes at all.  So if we change the kernel we'll
break it completely.

One option is to have the kernel report gamma_size = 129 but still
accept 256 and decimate itself.  That might cause current userspace to
keep working (except for DirectColor).

Any thoughts?

Re: rfc: breaking old userspace gamma for 10-bit support

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 1417 bytes --]

On Fri, 23 Jul 2010 14:00:30 -0400, Andrew Lutomirski <luto@mit.edu> wrote:
> AFAICT intel hardware wants a 129-entry LUT when using high precision
> gamma ramps.  Rather than hacking some kind of decimation into the
> kernel driver (and thus silently breaking DirectColor), I'd like to
> teach userspace how to deal with variable gamma sizes.
> 
> gnome-color-manager already more-or-less supports arbitrary gamma ramp
> sizes (supposedly), dispwin ought to do it, and there might not be any
> other software that really cares.  gnome-screensaver saves and
> restores the gamma ramp, and I haven't checked if it works right for
> funny sizes.
> 
> The worst problem we'll have is that current xf86-drv-intel can't
> handle non-256 gamma sizes at all.  So if we change the kernel we'll
> break it completely.
> 
> One option is to have the kernel report gamma_size = 129 but still
> accept 256 and decimate itself.  That might cause current userspace to
> keep working (except for DirectColor).
> 
> Any thoughts?

The kernel doesn't get to break old userspace.  The kernel could support
new userspace that only asks for 129 slots and set a mode that has
better precision in that case.  New interfaces would probably be
required to communicate that up front -- I haven't looked into it, but I
just want to make sure you don't spend a bunch of time going down a path
that will be rejected.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: rfc: breaking old userspace gamma for 10-bit support

[Andrew Lutomirski]

On Fri, Jul 23, 2010 at 4:13 PM, Eric Anholt <eric@anholt.net> wrote:
> On Fri, 23 Jul 2010 14:00:30 -0400, Andrew Lutomirski <luto@mit.edu> wrote:
>> AFAICT intel hardware wants a 129-entry LUT when using high precision
>> gamma ramps.  Rather than hacking some kind of decimation into the
>> kernel driver (and thus silently breaking DirectColor), I'd like to
>> teach userspace how to deal with variable gamma sizes.
>>
>> gnome-color-manager already more-or-less supports arbitrary gamma ramp
>> sizes (supposedly), dispwin ought to do it, and there might not be any
>> other software that really cares.  gnome-screensaver saves and
>> restores the gamma ramp, and I haven't checked if it works right for
>> funny sizes.
>>
>> The worst problem we'll have is that current xf86-drv-intel can't
>> handle non-256 gamma sizes at all.  So if we change the kernel we'll
>> break it completely.
>>
>> One option is to have the kernel report gamma_size = 129 but still
>> accept 256 and decimate itself.  That might cause current userspace to
>> keep working (except for DirectColor).
>>
>> Any thoughts?
>
> The kernel doesn't get to break old userspace.  The kernel could support
> new userspace that only asks for 129 slots and set a mode that has
> better precision in that case.  New interfaces would probably be
> required to communicate that up front -- I haven't looked into it, but I
> just want to make sure you don't spend a bunch of time going down a path
> that will be rejected.
>

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.)

I'll look in to whether we can switch between 256 and 129 slot modes
without flicker.  We can maybe take advantage of the fact that current
userspace doesn't even check the reported gamma ramp size but just
blindly shoves 256 entries at the kernel.

--Andy

Re: rfc: breaking old userspace gamma for 10-bit support

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 2266 bytes --]

On Fri, 23 Jul 2010 16:29:06 -0400, Andrew Lutomirski <luto@mit.edu> wrote:
> On Fri, Jul 23, 2010 at 4:13 PM, Eric Anholt <eric@anholt.net> wrote:
> > On Fri, 23 Jul 2010 14:00:30 -0400, Andrew Lutomirski <luto@mit.edu> wrote:
> >> AFAICT intel hardware wants a 129-entry LUT when using high precision
> >> gamma ramps.  Rather than hacking some kind of decimation into the
> >> kernel driver (and thus silently breaking DirectColor), I'd like to
> >> teach userspace how to deal with variable gamma sizes.
> >>
> >> gnome-color-manager already more-or-less supports arbitrary gamma ramp
> >> sizes (supposedly), dispwin ought to do it, and there might not be any
> >> other software that really cares.  gnome-screensaver saves and
> >> restores the gamma ramp, and I haven't checked if it works right for
> >> funny sizes.
> >>
> >> The worst problem we'll have is that current xf86-drv-intel can't
> >> handle non-256 gamma sizes at all.  So if we change the kernel we'll
> >> break it completely.
> >>
> >> One option is to have the kernel report gamma_size = 129 but still
> >> accept 256 and decimate itself.  That might cause current userspace to
> >> keep working (except for DirectColor).
> >>
> >> Any thoughts?
> >
> > The kernel doesn't get to break old userspace.  The kernel could support
> > new userspace that only asks for 129 slots and set a mode that has
> > better precision in that case.  New interfaces would probably be
> > required to communicate that up front -- I haven't looked into it, but I
> > just want to make sure you don't spend a bunch of time going down a path
> > that will be rejected.
> >
> 
> 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.)

I don't really know.  But if you want to change the userspace API, you
need to explain why your change doesn't break existing users of the
userspace API.  That may mean figuring out what existing users actually
do :)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: rfc: breaking old userspace gamma for 10-bit support

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 1825 bytes --]

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.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: rfc: breaking old userspace gamma for 10-bit support

[Jesse Barnes]

On Tue, 27 Jul 2010 11:03:56 -0400
Adam Jackson <ajax@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

Re: rfc: breaking old userspace gamma for 10-bit support

[Andrew Lutomirski]

On Wed, Apr 20, 2011 at 3:05 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Tue, 27 Jul 2010 11:03:56 -0400
> Adam Jackson <ajax@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?

Nope.  I gave up because I couldn't even get the mode to set. :)

One issue was that the RandR apis aren't really designed for cards
that can accept more than one gamma ramp size.  Someone (I forget who)
suggested adding a display property to control it.  It might be
possible to kill two birds with one stone by adding a property with
two settings:

 - Low depth: the logic you implemented: the bit depth is set to match
the framebuffer when possible and the gamma ramp size is set according
to the framebuffer depth.
 - High depth: the bit depth is set to the maximum that the encoder,
connector, and monitor support at the requested resolution and the
gamma ramp size is set to whatever gives the highest precision in each
entry.

Presumably, people would prefer the low depth mode if they care about
DirectColor (does anyone care about DirectColor?) or if they want to
save a little bit of power and people would use high depth if they
plan to use the gamma ramp for calibration.

--Andy

>
> Thanks,
> --
> Jesse Barnes, Intel Open Source Technology Center
>

Re: rfc: breaking old userspace gamma for 10-bit support

[Jesse Barnes]

[-- Attachment #1: Type: text/plain, Size: 2249 bytes --]

> > Andrew, do you have anything hacked together for this yet?
> 
> Nope.  I gave up because I couldn't even get the mode to set. :)

Ok well you should be able to now. :)  Using the patchset I posted
earlier along with the two attached patches, the testdisplay program in
intel-gpu-tools will set a 30bpp mode and draw some nice gradients
(though without a 10bpc gamma ramp loaded).

> One issue was that the RandR apis aren't really designed for cards
> that can accept more than one gamma ramp size.  Someone (I forget who)
> suggested adding a display property to control it.  It might be
> possible to kill two birds with one stone by adding a property with
> two settings:
> 
>  - Low depth: the logic you implemented: the bit depth is set to match
> the framebuffer when possible and the gamma ramp size is set according
> to the framebuffer depth.
>  - High depth: the bit depth is set to the maximum that the encoder,
> connector, and monitor support at the requested resolution and the
> gamma ramp size is set to whatever gives the highest precision in each
> entry.

Well, I haven't implemented anything, gamma-wise.  If you select say
30bpp when you start X *and* you have a kernel with my patches applied,
you'll get 10bpc all the way out to the display if it supports it.  If
the display does *not* support 10bpc, the pipe will dither it to 8bpc
before sending it to the encoder.  Current DDX on an old kernel will
fail to create an FB with 10bpc because the kernel will reject it.

So I guess I don't understand your low vs high distinction; the bit
depth is ultimately tied to the framebuffer and its allocation.
Correction happens after the fact in hw when the plane feeds bits to the
pipe.

Of course that's all separate from the color correction that happens
before the bits get to the pipe.  For that we have to wait until the
DDX starts up and decides what to do.  In a 30bpp mode, I'd hope it
would default to using the 10 bit gamma ramp (1024 entries of 30 bits
each), which I think is what you had in mind?  For that, we'd just need
to check whether we can hand the kernel a 1024 entry table, then do it
if possible, otherwise fall back to the existing 256 entry code.

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #2: cairo-30bpp-support.patch --]
[-- Type: text/x-patch, Size: 7088 bytes --]

diff --git a/src/cairo-debug.c b/src/cairo-debug.c
index b8bdfd1..1aa5779 100644
--- a/src/cairo-debug.c
+++ b/src/cairo-debug.c
@@ -118,6 +118,7 @@ _cairo_debug_check_image_surface_is_defined (const cairo_surface_t *surface)
 	width = image->width*2;
 	break;
     case CAIRO_FORMAT_RGB24:
+    case CAIRO_FORMAT_RGB30:
     case CAIRO_FORMAT_ARGB32:
 	width = image->width*4;
 	break;
diff --git a/src/cairo-image-surface.c b/src/cairo-image-surface.c
index 7097fa4..15af007 100644
--- a/src/cairo-image-surface.c
+++ b/src/cairo-image-surface.c
@@ -101,6 +101,8 @@ _cairo_format_from_pixman_format (pixman_format_code_t pixman_format)
     switch (pixman_format) {
     case PIXMAN_a8r8g8b8:
 	return CAIRO_FORMAT_ARGB32;
+    case PIXMAN_x2b10g10r10:
+	return CAIRO_FORMAT_RGB30;
     case PIXMAN_x8r8g8b8:
 	return CAIRO_FORMAT_RGB24;
     case PIXMAN_a8:
@@ -122,7 +124,6 @@ _cairo_format_from_pixman_format (pixman_format_code_t pixman_format)
     case PIXMAN_yuy2:     case PIXMAN_yv12:
     case PIXMAN_b8g8r8x8:
     case PIXMAN_b8g8r8a8:
-    case PIXMAN_x2b10g10r10:
     case PIXMAN_a2b10g10r10:
     case PIXMAN_x2r10g10b10:
     case PIXMAN_a2r10g10b10:
@@ -300,6 +301,9 @@ _cairo_format_to_pixman_format_code (cairo_format_t format)
     case CAIRO_FORMAT_RGB24:
 	ret = PIXMAN_x8r8g8b8;
 	break;
+    case CAIRO_FORMAT_RGB30:
+	ret = PIXMAN_x2r10g10b10;
+	break;
     case CAIRO_FORMAT_RGB16_565:
 	ret = PIXMAN_r5g6b5;
 	break;
@@ -668,6 +672,8 @@ _cairo_content_from_format (cairo_format_t format)
     switch (format) {
     case CAIRO_FORMAT_ARGB32:
 	return CAIRO_CONTENT_COLOR_ALPHA;
+    case CAIRO_FORMAT_RGB30:
+	return CAIRO_CONTENT_COLOR;
     case CAIRO_FORMAT_RGB24:
 	return CAIRO_CONTENT_COLOR;
     case CAIRO_FORMAT_RGB16_565:
@@ -689,6 +695,8 @@ _cairo_format_bits_per_pixel (cairo_format_t format)
     switch (format) {
     case CAIRO_FORMAT_ARGB32:
 	return 32;
+    case CAIRO_FORMAT_RGB30:
+	return 32;
     case CAIRO_FORMAT_RGB24:
 	return 32;
     case CAIRO_FORMAT_RGB16_565:
@@ -1272,6 +1280,19 @@ _pixel_to_solid (cairo_image_surface_t *image, int x, int y)
 	color.blue = expand_channel ((pixel & 0x1f) << 11, 5);
 	return pixman_image_create_solid_fill (&color);
 
+    case CAIRO_FORMAT_RGB30:
+	pixel = *(uint32_t *) (image->data + y * image->stride + 4 * x);
+	if (pixel == 0)
+	    return _pixman_black_image ();
+	if (pixel == 0x3fffffff)
+	    return _pixman_white_image ();
+
+	color.alpha = 0xc0;
+	color.red = (pixel >> 20) & 0x3fff;
+	color.green = (pixel >> 10) & 0x3fff;
+	color.blue = pixel & 0x3fff;
+	return pixman_image_create_solid_fill (&color);
+
     case CAIRO_FORMAT_ARGB32:
     case CAIRO_FORMAT_RGB24:
 	pixel = *(uint32_t *) (image->data + y * image->stride + 4 * x);
diff --git a/src/cairo-png.c b/src/cairo-png.c
index f5c7cb5..e176043 100644
--- a/src/cairo-png.c
+++ b/src/cairo-png.c
@@ -241,6 +241,10 @@ write_png (cairo_surface_t	*surface,
 	else
 	    png_color_type = PNG_COLOR_TYPE_RGB_ALPHA;
 	break;
+    case CAIRO_FORMAT_RGB30:
+	depth = 30;
+	png_color_type = PNG_COLOR_TYPE_RGB;
+	break;
     case CAIRO_FORMAT_RGB24:
 	depth = 8;
 	png_color_type = PNG_COLOR_TYPE_RGB;
diff --git a/src/cairo-xlib-display.c b/src/cairo-xlib-display.c
index dd60484..bef9c83 100644
--- a/src/cairo-xlib-display.c
+++ b/src/cairo-xlib-display.c
@@ -584,6 +584,7 @@ _cairo_xlib_display_get_xrender_format (cairo_xlib_display_t	*display,
 	    xrender_format = XRenderFindVisualFormat(display->display, visual);
 	    break;
 	}
+	case CAIRO_FORMAT_RGB30:
 	case CAIRO_FORMAT_INVALID:
 	default:
 	    ASSERT_NOT_REACHED;
diff --git a/src/cairo.h b/src/cairo.h
index 3495146..9632592 100644
--- a/src/cairo.h
+++ b/src/cairo.h
@@ -2251,6 +2251,7 @@ cairo_surface_has_show_text_glyphs (cairo_surface_t *surface);
  * @CAIRO_FORMAT_RGB16_565: each pixel is a 16-bit quantity
  *   with red in the upper 5 bits, then green in the middle
  *   6 bits, and blue in the lower 5 bits.
+ * @CAIRO_FORMAT_RGB30: like RGB24 but with 10bpc
  *
  * #cairo_format_t is used to identify the memory format of
  * image data.
@@ -2263,7 +2264,8 @@ typedef enum _cairo_format {
     CAIRO_FORMAT_RGB24     = 1,
     CAIRO_FORMAT_A8        = 2,
     CAIRO_FORMAT_A1        = 3,
-    CAIRO_FORMAT_RGB16_565 = 4
+    CAIRO_FORMAT_RGB16_565 = 4,
+    CAIRO_FORMAT_RGB30     = 5,
 } cairo_format_t;
 
 cairo_public cairo_surface_t *
diff --git a/src/cairoint.h b/src/cairoint.h
index 8d9bd44..efe9424 100644
--- a/src/cairoint.h
+++ b/src/cairoint.h
@@ -1862,7 +1862,7 @@ _cairo_surface_release_device_reference (cairo_surface_t *surface);
  * in cairo-xlib-surface.c--again see -Wswitch-enum).
  */
 #define CAIRO_FORMAT_VALID(format) ((format) >= CAIRO_FORMAT_ARGB32 &&		\
-                                    (format) <= CAIRO_FORMAT_RGB16_565)
+                                    (format) <= CAIRO_FORMAT_RGB30)
 
 /* pixman-required stride alignment in bytes. */
 #define CAIRO_STRIDE_ALIGNMENT (sizeof (uint32_t))
diff --git a/util/cairo-script/cairo-script-operators.c b/util/cairo-script/cairo-script-operators.c
index 647975f..34b534e 100644
--- a/util/cairo-script/cairo-script-operators.c
+++ b/util/cairo-script/cairo-script-operators.c
@@ -2854,6 +2854,7 @@ _image_read_raw (csi_file_t *src,
 	rowlen = 3 * width;
 	break;
     default:
+    case CAIRO_FORMAT_RGB30:
     case CAIRO_FORMAT_INVALID:
     case CAIRO_FORMAT_ARGB32:
 	rowlen = 4 * width;
@@ -2915,6 +2916,7 @@ _image_read_raw (csi_file_t *src,
 #endif
 		}
 		break;
+	    case CAIRO_FORMAT_RGB30:
 	    case CAIRO_FORMAT_INVALID:
 	    case CAIRO_FORMAT_ARGB32:
 		/* stride == width */
@@ -3003,6 +3005,7 @@ _image_read_raw (csi_file_t *src,
 #endif
 	    }
 	    break;
+	case CAIRO_FORMAT_RGB30:
 	case CAIRO_FORMAT_INVALID:
 	case CAIRO_FORMAT_ARGB32:
 	    /* stride == width */
@@ -3038,6 +3041,7 @@ _image_read_raw (csi_file_t *src,
 	case CAIRO_FORMAT_A8:
 	    break;
 
+	case CAIRO_FORMAT_RGB30:
 	case CAIRO_FORMAT_RGB24:
 	case CAIRO_FORMAT_INVALID:
 	default:
diff --git a/util/cairo-trace/trace.c b/util/cairo-trace/trace.c
index 9bdeb01..44dc137 100644
--- a/util/cairo-trace/trace.c
+++ b/util/cairo-trace/trace.c
@@ -1451,6 +1451,7 @@ _format_to_string (cairo_format_t format)
     switch (format) {
 	f(INVALID);
 	f(ARGB32);
+	f(RGB30);
 	f(RGB24);
 	f(RGB16_565);
 	f(A8);
@@ -1584,6 +1585,7 @@ _emit_image (cairo_surface_t *image,
     case CAIRO_FORMAT_RGB16_565: len = 2*width; break;
     case CAIRO_FORMAT_RGB24:     len = 3*width; break;
     default:
+    case CAIRO_FORMAT_RGB30:
     case CAIRO_FORMAT_INVALID:
     case CAIRO_FORMAT_ARGB32: len = 4*width; break;
     }
@@ -1622,6 +1624,7 @@ _emit_image (cairo_surface_t *image,
 	    data += stride;
 	}
 	break;
+    case CAIRO_FORMAT_RGB30:
     case CAIRO_FORMAT_ARGB32:
 	for (row = height; row--; ) {
 	    _write_data (&stream, data, 4*width);
@@ -1681,6 +1684,7 @@ _emit_image (cairo_surface_t *image,
 	    data += stride;
 	}
 	break;
+    case CAIRO_FORMAT_RGB30:
     case CAIRO_FORMAT_ARGB32:
 	for (row = height; row--; ) {
 	    uint32_t *src = (uint32_t *) data;

[-- Attachment #3: testdisplay-30bpp.patch --]
[-- Type: text/x-patch, Size: 384 bytes --]

diff --git a/tests/testdisplay.c b/tests/testdisplay.c
index 5bf5183..eeff97e 100644
--- a/tests/testdisplay.c
+++ b/tests/testdisplay.c
@@ -369,6 +369,8 @@ allocate_surface(int fd, int width, int height, uint32_t depth, uint32_t bpp,
 		format = CAIRO_FORMAT_RGB24;
 		break;
 	case 30:
+		format = CAIRO_FORMAT_RGB30;
+		break;
 	case 32:
 		format = CAIRO_FORMAT_ARGB32;
 		break;

[-- Attachment #4: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: rfc: breaking old userspace gamma for 10-bit support

[Andrew Lutomirski]

On Wed, Apr 20, 2011 at 3:38 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>> > Andrew, do you have anything hacked together for this yet?
>>
>> Nope.  I gave up because I couldn't even get the mode to set. :)
>
> Ok well you should be able to now. :)  Using the patchset I posted
> earlier along with the two attached patches, the testdisplay program in
> intel-gpu-tools will set a 30bpp mode and draw some nice gradients
> (though without a 10bpc gamma ramp loaded).

Will test at home (that's where by 10bpc display is).

>
>> One issue was that the RandR apis aren't really designed for cards
>> that can accept more than one gamma ramp size.  Someone (I forget who)
>> suggested adding a display property to control it.  It might be
>> possible to kill two birds with one stone by adding a property with
>> two settings:
>>
>>  - Low depth: the logic you implemented: the bit depth is set to match
>> the framebuffer when possible and the gamma ramp size is set according
>> to the framebuffer depth.
>>  - High depth: the bit depth is set to the maximum that the encoder,
>> connector, and monitor support at the requested resolution and the
>> gamma ramp size is set to whatever gives the highest precision in each
>> entry.
>
> Well, I haven't implemented anything, gamma-wise.  If you select say
> 30bpp when you start X *and* you have a kernel with my patches applied,
> you'll get 10bpc all the way out to the display if it supports it.  If
> the display does *not* support 10bpc, the pipe will dither it to 8bpc
> before sending it to the encoder.  Current DDX on an old kernel will
> fail to create an FB with 10bpc because the kernel will reject it.
>
> So I guess I don't understand your low vs high distinction; the bit
> depth is ultimately tied to the framebuffer and its allocation.
> Correction happens after the fact in hw when the plane feeds bits to the
> pipe.

I want to have a 24-bit display plane with a 10-bit precision (or
12-bit interpolated) gamma ramp driving a 10bpc pipe and 10bpc over
DisplayPort.  That way I can ask Argyll for a 10bpc gamma ramp and I
get a gamma-corrected display without any banding but also without
having to wait for all the userspace stuff (mesa, compiz, etc.) to be
able to draw to a 30-bit framebuffer.

--Andy