On 05/18/2013 04:29 AM, Alexandre Courbot wrote:
> On Thu, Apr 4, 2013 at 11:39 AM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
>> +struct simplefb_format {
>> + const char *name;
>> + u32 bits_per_pixel;
>> + struct fb_bitfield red;
>> + struct fb_bitfield green;
>> + struct fb_bitfield blue;
>> + struct fb_bitfield transp;
>> +};
>> +
>> +struct simplefb_format simplefb_formats[] = {
>> + { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
>> +};
>
> I have been adding a few extra formats to this list, and I wonder if
> this could not simply be turned into a function that would directly
> convert the name string into the corresponding right format. The
> mapping between name and format seems to be a 1:1 and this would
> probably avoid errors in the future. I'm especially thinking about
> color order here - I started adding a mode that reads
>
> { "r8g8b8a8", 32, {0, 8}, {8, 8}, {16, 8}, {24, 8} },
>
> while it should probably be called "a8b8g8r8" as the order of colors
> is not the same as your r5g6b5.
>
> I can submit a patch if there is no issue with that idea.
I chose r5g6b5 rather than rgb565 specifically to make that format
trivially name machine-parsable. So, I'm not opposed to converting that
table to code. I'm not 100% sure if it's worth it or necessary by the
time we get to just 2 formats in the array, but I don't see any big
disadvantage, so why not. The DT binding documentation might want
enhancing with a more general description of how formats should be
represented if this is implemented.
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
