Kristian Høgsberg hoegsberg@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?