On 05/23/2013 10:57 AM, Geert Uytterhoeven wrote: > On Thu, May 23, 2013 at 6:27 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: >>> + >>> + cpt += field->length; >>> + } >>> + >>> + format->bits_per_pixel = ((cpt + 7) / 8) * 8; >> >> Should this error-check that isn't > 32? > > So pixels can't be larger than 32 bits? > IIRC, some SGI and Sun graphics cards had e.g. 80 bit pixels (incl. Z buffer). That's a good point. Out of curiosity, how does the FB core treat these format definitions? Are they expected to fit into a 16-/32-/64-/128- bit power-of-two bit-size, or are they treated as a string of bytes that get serialized into memory LSB first (or perhaps MSB first on BE systems?) The difference would be that from a CPU perspective only, if you pack the RGB components into a u32, then write that to RAM as a u32, then the in-memory byte-by-byte order is different on different endian systems, whereas if the FB core treats it as a series of bytes only, then presumably the in-memory byte-by-byte order is identical irrespective of host CPU endianness. -- 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
