linuxconsole-dev

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

Re: vfb.c (ruby)

[James S. <jsi...@ac...>]

> > >     length = (xres_virtual+bpp-1)/bpp;
> It is obviously wrong... For xres = 640 at 16bpp you should get
> 1280 bytes and for 8bpp 640 bytes...

Dah!! I don't know what I was thinking. I was just trying to figure what
the orginal code was doing. Which I stil can't figure it out yet. Petr do
you have a idea what Geert was thinking when he wrote that routine? 


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

Right, you wouldn't need a get_line_length routine. 


Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: vfb.c (ruby)

[Christian H. <ch...@os...>]

On Wed, 31 May 2000, James Simmons wrote:

> 
> > > >     length = (xres_virtual+bpp-1)/bpp;
> > It is obviously wrong... For xres = 640 at 16bpp you should get
> > 1280 bytes and for 8bpp 640 bytes...
> 
> Dah!! I don't know what I was thinking. I was just trying to figure what
> the orginal code was doing. Which I stil can't figure it out yet. Petr do
> you have a idea what Geert was thinking when he wrote that routine? 
> 

Okay ... has anybody tested vfb.c? I didn't. If it works, I don't know how,
because it computes the memory size with get_line_length() to test:

------ vfb.c ------ L245 ------

    line_length = get_line_length(var->xres_virtual, var->bits_per_pixel);
    if (line_length*var->yres_virtual > videomemorysize)
	return -ENOMEM;

Any idea? Maybe nobody got a problem because the get_line_length()-function
always produces to small values to return ENOMEM - and the
default/module_param videomemorysize fitted. 

But:
------ vfb.c ------ L506 ------

    fix->line_length = get_line_length(var->xres_virtual,
					var->bits_per_pixel);

would also 'encode' wrong values.

Christian.

Re: vfb.c (ruby)

[James S. <jsi...@ac...>]

> Okay ... has anybody tested vfb.c? I didn't. If it works, I don't know how,
> because it computes the memory size with get_line_length() to test:

Okay I found out what this code does. I have placed the code with comments
in CVS. Here is the explanation:

static u_long get_line_length(int xres_virtual, int bpp)
{
    u_long length;

    /* Calculate number of bits per display line */
    length = xres_virtual * bpp;
    /* Round up to a multiple of 32 */
    length = (length+31)&~31;
    /* Convert number of bits to number of bytes */
    length >>= 3;
    return(length);
}