Re: Re: bits_per_pixel query

2 messages, 2 authors, 2002-09-11 · open the first message on its own page

Re: Re: bits_per_pixel query

From: Linux PPC <hidden>
Date: 2002-09-11 12:38:04

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.
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?

Thanks,

- navin.

__________________________________________________________
Give your Company an email address like
ravi @ ravi-exports.com.  Sign up for Rediffmail Pro today!
Know more. http://www.rediffmailpro.com/signup/



-------------------------------------------------------
In remembrance
www.osdn.com/911/

Re: Re: bits_per_pixel query

From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2002-09-11 12:43:59

On 11 Sep 2002, Linux  PPC wrote:
On Mon, 09 Sep 2002 Antonino Daplas wrote :
quoted
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.
 
quoted
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 -- geert@linux-m68k.org

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



-------------------------------------------------------
In remembrance
www.osdn.com/911/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help