Re: Re: [Linux-fbdev-devel] bits_per_pixel query

[Geert U. <ge...@li...>]

On 11 Sep 2002, Linux  PPC wrote:
> On Mon, 09 Sep 2002 Antonino Daplas wrote :
> >Just pad the pitch/line_length/stride of the buffer to the next 
> >byte
> >alignment your hardware is capable of.  It is acceptable to have 
> >excess
> >bits/bytes which theoretically your hardware will ignore.
> 
> The padding is at the end of the line_length, or
> at the end of the pixel data? I tried both ways,
> but I'm getting a skewed square, which I draw
> using a user space application.

The padding is at the end of the line.

If fix.line_length != 0, the line length (in bytes) is fix.line_length, and the
padding is fix.line_length-var.xres_virtual*var.bits_per_pixel/8.
If fix.line_length == 0, the line length (in bytes) is
var.xres_virtual*var.bits_per_pixel/8 and there is no padding.
 
> >For static pseudocolor and truecolor, that is true, since 0 is 
> >hardwired
> >to black.  For pseudocolor and directcolor, that depends on how 
> >the
> >DAC/palette is loaded. In most cases, it will produce a black 
> >screen.
> 
> For psuedocolor and direct color, does the pixel
> data, have the index into the colormap or does it
> have actual colors? If it has the index, then the size of the 
> buffer would be lesser: right?

In pseudocolor and directcolor, the pixel data is a colormap index. Pixels
always have a size of var.bits_per_pixel bits.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds