Bug#338245: framebuffer driver does not set display width properly if used without Shadow

[Peter Teichmann <peter@peter-teichmann.de>]

Am Mittwoch, 9. November 2005 13:14 schrieb Michel Dänzer:
> On Wed, 2005-11-09 at 00:20 +0100, Peter Teichmann wrote:
> > diff -urd xc.orig/programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c
> > xc/programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c ---
> > xc.orig/programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c	2005-10-25
> > 23:02:32.000000000 +0200 +++
> > xc/programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c	2005-10-25
> > 22:55:14.000000000 +0200 @@ -672,11 +672,19 @@
[...]
> > +	if (!fPtr->shadowFB)
> > +	{
> > +		int fbbpp;
> > +		/* FIXME: this doesn't work for all cases, e.g. when each scanline
> > +			has a padding which is independent from the depth (controlfb) */
> > +		fbdevHWGetDepth(pScrn,&fbbpp);
> > +		pScrn->displayWidth = fbdevHWGetLineLength(pScrn)/(fbbpp >> 3);
> >  	}
>
> Why doesn't the same code in FBDevPreInit() work? Because it gets a line
> length from a different mode? If so, shouldn't you just move the code
> from FBDevPreInit() here?

In FBDevPreInit, it gets the line length for the "built-in" mode that is 
present at the framebuffer device at the beginning. Here it is for that 
special mode which was selected for display. Without this patch, the line 
length from the "built-in" mode is preserved. But it can happen that the 
selected mode has a different line length, I believe that this is even the 
normal case ;-) The only reason why this bug was not fixed long before is 
probably, that it only shows without Shadow. But Shadow is the default, and 
on typical hardware with slow screen memory read speed you will not want to 
disable it.

I am not sure if I am just not able to see it, but it seems to me that parts 
of the framebuffer driver are not especially clearly coded...

> PS: It might be better if you submitted your patches upstream at
> https://bugs.freedesktop.org/ first and only asked for them to be
> backported to the Debian packages necessary once they've been applied
> upstream.

I can still do that. How can we "stop" these bug reports?

Peter Teichmann