Peter Korsgaard wrote: > Because it is arguable wrong as far as I understand the HW. > There's two parts here: > > - 1: Format of framebuffer memory > - 2: Wiring of LCD (RGB/BGR order and number of bits) > > >From the datasheet, the following framebuffer formats are supported: > > 1, 2, 4, 8 bits per pixel (palletized), 16, 24 bits per pixel > (non-palletized) for TFT. > > So it doesn't really support RGB555 mode. The controller reads up to > 32bit of framebuffer data and outputs 24bit on the LCD pins. You CAN > wire up a RGB555 panel by just skipping the LSB green of a RGB565 > wiring, but that is independent of the framebufffer format. The > controller/driver doesn't do any RGB/BGR swapping, so the RBG/BGR wiring > settings are just used as a software hint (in FBIOGET_VSCREENINFO) about > the meaning of the individual bits of a pixel in the framebuffer. > > Similar you can connect a 12bit 4:4:4 panel by just connecting it to the > MSB LCD pins. If you're connecting an RGB555 or RGB444 panel, don't you want the software using the framebuffer to know this so it will dither appropriately? E.g. gradients look "bandy" if drawn in RGB565 then green's LSB is dropped. -- Jamie -- 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
