Your message dated Wed, 25 Apr 2007 23:35:24 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#338245: framebuffer driver does not set display width
properly if used without Shadow
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: xserver-xorg
Version: 6.8.2.dfsg.1-7
Severity: important
Tags: patch
The framebuffer driver does not set the display width properly if used
without Shadow, but keeps the old value from the probed built-in mode.
If the horizontal resolution of the later selected video mode differs,
this is a problem. The patch below fixes this.
Peter Teichmann
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->rotate==FBDEV_ROTATE_CW || fPtr->rotate==FBDEV_ROTATE_CCW)
{
- height = pScrn->virtualX;
- width = pScrn->displayWidth = pScrn->virtualY;
+ height = pScrn->virtualX;
+ width = pScrn->displayWidth = pScrn->virtualY;
} else {
- height = pScrn->virtualY;
- width = pScrn->virtualX;
+ height = pScrn->virtualY;
+ width = pScrn->virtualX;
+ }
+ 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);
}
if(fPtr->rotate && !fPtr->PointerMoved) {
--- End Message ---
--- Begin Message ---
This bug is supposed to be fixed upstream since novembre 2005, so this
should work fine at least in Xorg/Etch, closing.
Brice
--- End Message ---
