xorg fbdev support for < 8 bits per pixel

[Jonathan Morton]

> >> Anyway, just would like to find out, how much effort it would take to
> >> add support for devices with 1/2 bits/pixel depth. I noticed that the
> >> current xorg-fbdev implementation doesn't support these depths.
> >>
> >> Just to add context to the question, I'm working on an embedded device
> >> with a monochrome LCD. The CPU can generate grayscale images by upping
> >> the frame-rate and modulating the pixels but the hardware implementation
> >> limits the max FR so I can only support about 2 bits per pixel depth.
> >
> > Would it be sufficient to use an 8bpp greyscale framebuffer and simply
> > ignore the low-order bits on scanout?

> Maybe I'm a bit out of my depth (hehe) here, could you elaborate on this 
> please? The CPU (iMX.25) LCD peripheral (LCDC module) uses a chunk of 
> memory to scan out and the bit depth is determined by the video mode 
> used. My understanding is, the X FB drv writes directly to this chunk of 
> memory (please correct me if I'm wrong). What step are you referring to 
> as scanout?

Scanout refers to the chunk of hardware between the framebuffer memory
and the physical display panel.  In olden times this was a RAMDAC of
some description, these days the output is more usually digital.

Essentially I'm saying: let the xserver pretend there's a 256-grey
display, and deal with the mismatch between that and reality in that
piece of hardware.  This is already done by the extremely common TN LCD
panels, which typically have only 6-bit per colour resolution and dither
up the remaining two in hardware.

If the output to your panel is parallel per pixel, then you can let the
scanout provide 8 bits and simply not connect wires to 6 of them.

-- 
------
From: Jonathan Morton
      jonathan.morton at movial.com