Kristian H?gsberg <hoegsberg at gmail.com> writes:
> I already explained to Keith why we use different sets of format codes
> in the DRI interface, but it's always fun to slam other peoples code.
As we discussed, my complaint isn't so much about __DRI_IMAGE_FOURCC,
but the fact that the __DRIimage interfaces use *both*
__DRI_IMAGE_FOURCC and __DRI_IMAGE_FORMAT at different times.
Ok, here's a fine thing we can actually fix -- the pattern that mesa
uses all over the place in converting formats looks like this (not to
pick on anyone, it's repeated everywhere, this is just the first one I
found in gbm_dri.c):
static uint32_t
gbm_dri_to_gbm_format(uint32_t dri_format)
{
uint32_t ret = 0;
switch (dri_format) {
case __DRI_IMAGE_FORMAT_RGB565:
ret = GBM_FORMAT_RGB565;
break;
case __DRI_IMAGE_FORMAT_XRGB8888:
ret = GBM_FORMAT_XRGB8888;
break;
case __DRI_IMAGE_FORMAT_ARGB8888:
ret = GBM_FORMAT_ARGB8888;
break;
case __DRI_IMAGE_FORMAT_ABGR8888:
ret = GBM_FORMAT_ABGR8888;
break;
default:
ret = 0;
break;
}
return ret;
}
The problem here is that any unknown incoming formats get translated to
garbage (0) outgoing. With fourcc codes, there is the slight advantage
that 0 is never a legal value, but it sure would be nice to print a
warning or even abort if you get a format code you don't understand as
there's no way 0 is ever going to do what you want.
Anyone have a preference? Abort? Print an error? Silently continue to do
the wrong thing?
--
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/c4e036f0/attachment.pgp>
