bits_per_pixel query

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

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