bits_per_pixel query

bits_per_pixel query

[Linux PPC]

Hello there,

I had some doubts regarding the framebuffer struct
usage.

As I understand, the buffer is at fb_info.screen_base
and the size of the buffer is (hres * vres *
bits_per_pixel )/8. The state of the pixel at
location (x,y), would be represented by the value of
byte at screen_base + ((y*hres + x) * bits_per_pixel)/8.

If the display is 8 bit, then it would require only
a byte to represent the value of the pixel. If it were 24 bit, 
then it would require 3 bytes, and so
on. Is that right? What would happen, to the size required for the 
buffer, if the display
requires, say 12 bits per pixel, or 18 bits?

So, if I were to set all the bytes after screen_base
uptil screen_base + (hres*vres*bits_per_pixel/8) to
zeros, then I would get a black screen. Is that right?

I'm asking cos, I'm workin on a framebuffer support
for an LCD panel, and am making the above assumption
which doesn't seem happening.

- 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/



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: bits_per_pixel query

[Antonino Daplas]

On Mon, 2002-09-09 at 00:39, Linux PPC wrote: 

> 
> If the display is 8 bit, then it would require only
> a byte to represent the value of the pixel. If it were 24 bit, 
> then it would require 3 bytes, and so
> on. Is that right? What would happen, to the size required for the 
> buffer, if the display
> requires, say 12 bits per pixel, or 18 bits?
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. Then the
framebuffer size is line_length*yres_virtual. 
> 
> So, if I were to set all the bytes after screen_base
> uptil screen_base + (hres*vres*bits_per_pixel/8) to
> zeros, then I would get a black screen. Is that right?
> 
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. 

Tony 





-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390