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