Re: vfb.c (ruby)

[Petr V. <VAN...@vc...>]

On 31 May 00 at 10:37, James Simmons wrote:
> > static u_long get_line_length(int xres_virtual, int bpp)
> > {
> >     u_long length;
> > 
> >     length = (xres_virtual+bpp-1)/bpp;
> 
> This returns the number of bytes wide the screen is. For 640 at 8 bpp that
> would be 640/8 = 80 bytes wide. If we where at 16 bpp we have 640/16 =
> 40 words wide. Why the above formula? It rounds up the number of we
It is obviously wrong... For xres = 640 at 16bpp you should get
1280 bytes and for 8bpp 640 bytes...

length = xres_virtual * bpp / 8;

works for cfb modes with xres_virtual * bpp is multiple of 8. As other
videomodes are impossible on majority of hardware... and generic procedure
cannot say what happens with `overflowed' pixels - maybe that line
length will be 'length = (xres_virtual * bpp + 7) / 8' or
'length = (xres_virtual * bpp + 63) / 64 * 8' or ... 
So let fbdev driver round xres_virtual up to match hardware...

> >     length = (length+31)&-32;
> 
> > What is/should be the return value? 32 bit aligned bytes?
> 
> Yes.

It is wrong... If I say that I want xres_virtual = 1235, then
(if hardware supports such vxres), length must be 1235 * 3 bytes
for 24bpp. No more, no less. Just exactly 3705 bytes... It is
driver responsibility to eventually round xres_virtual up if 
hardware cannot do xres_virtual = 1235... 
> > I thought:
> > 
> >     length = (xres + bpp-1) * bpp;
> > 
> > would be right. But, as I mentioned, I'm a bit confused ;-)
With xres_virtual it is right...

> Length is the value that placed in fb_fix-screeninfo line_length which is
> the number of bytes wide the way th card sees a scanline. Take a voodoo
> card for example. No matter what mode you set the card in line_length is
> 1024. So take for example 800x600. We have video memory layed out like
> this:
Then easiest thing is that driver will always report xres_virtual = 1024.
Or it can compute line_length as it wants, but for such hardware then 
get_line_length() should not depend on xres_virtual.
                                                Petr Vandrovec
                                                van...@vc...