From: Michel Dänzer <daenzerm@student.ethz.ch>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: mlan@cpu.lu, linuxppc-dev@lists.linuxppc.org, dmj+@andrew.cmu.edu
Subject: Re: Control fb problem on 8500
Date: Mon, 21 Aug 2000 15:14:38 +0200 [thread overview]
Message-ID: <39A12B3E.44294E59@student.ethz.ch> (raw)
In-Reply-To: Pine.LNX.4.10.10008211241460.371-100000@cassiopeia.home
[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]
Geert Uytterhoeven wrote:
>
> On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
> > That's not even needed, the fbdev driver is just broken. Line 430:
> >
> > pScrn->displayWidth = pScrn->virtualX; /* FIXME: might be wrong */
> >
> > is indeed wrong. virtualX is obvious, but displayWidth should be the
> > memory pitch of a scanline.
> >
> > Now you just have to find out where to get the correct value for
> > displayWidth.
>
> I suppose
>
> if (fix.line_length)
> pScrn->displayWidth = fix.line_length*8/var.bits_per_pixel;
> else
> pScrn->displayWidth = var.xres_virtual;
>
> should work fine, except on hardware were
> fix.line_length*8/var.bits_per_pixel might not be integer (e.g. if
> 1280x1024x24 mode requires a line_length of 4096).
I've thought of this as well. The problem is that the mode hasn't been
initialized when displayWidth is set and used.
The best I can think of ATM is the attached patch. This should make it work
with ShadowFB, which is on by default anyway.
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
[-- Attachment #2: fbdev.diff --]
[-- Type: text/plain, Size: 2224 bytes --]
diff -ru ../xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c
--- ../xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c Mon Jul 3 09:04:53 2000
+++ xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c Mon Aug 21 12:01:10 2000
@@ -419,6 +419,13 @@
}
int
+fbdevHWGetLineLength(ScrnInfoPtr pScrn)
+{
+ fbdevHWPtr fPtr = FBDEVHWPTR(pScrn);
+ return fPtr->fix.line_length;
+}
+
+int
fbdevHWGetType(ScrnInfoPtr pScrn)
{
fbdevHWPtr fPtr = FBDEVHWPTR(pScrn);
diff -ru ../xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.h xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.h
--- ../xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.h Sun May 28 01:32:00 2000
+++ xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.h Mon Aug 21 11:57:01 2000
@@ -14,6 +14,7 @@
char* fbdevHWGetName(ScrnInfoPtr pScrn);
int fbdevHWGetDepth(ScrnInfoPtr pScrn);
+int fbdevHWGetLineLength(ScrnInfoPtr pScrn);
int fbdevHWGetType(ScrnInfoPtr pScrn);
int fbdevHWGetVidmem(ScrnInfoPtr pScrn);
diff -ru ../xc/programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c xc/programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c
--- ../xc/programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c Sun Jun 18 16:23:22 2000
+++ xc/programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c Mon Aug 21 14:36:29 2000
@@ -138,6 +138,7 @@
"fbdevHWGetName",
"fbdevHWGetDepth",
+ "fbdevHWGetLineLength",
"fbdevHWGetVidmem",
/* colormap */
@@ -426,7 +427,14 @@
if (NULL == pScrn->modes)
fbdevHWUseBuildinMode(pScrn);
pScrn->currentMode = pScrn->modes;
- pScrn->displayWidth = pScrn->virtualX; /* FIXME: might be wrong */
+
+ if (fPtr->shadowFB)
+ pScrn->displayWidth = pScrn->virtualX; /* ShadowFB handles this correctly */
+ else
+ /* FIXME: this doesn't work for all cases, e.g. when each scanline
+ has a padding which is independent from the depth (controlfb) */
+ pScrn->displayWidth = fbdevHWGetLineLength(pScrn)/(fbdevHWGetDepth(pScrn) >> 3);
+
xf86PrintModes(pScrn);
/* Set display resolution */
@@ -512,7 +520,7 @@
unsigned char *src, *dst;
Bpp = pScrn->bitsPerPixel >> 3;
- FBPitch = pScrn->displayWidth * Bpp;
+ FBPitch = fbdevHWGetLineLength(pScrn);
while(num--) {
width = (pbox->x2 - pbox->x1) * Bpp;
next prev parent reply other threads:[~2000-08-21 13:14 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-08-15 17:45 Control fb problem on 8500 Kevin M. Myer
2000-08-15 18:26 ` Michel D nzer
2000-08-15 19:41 ` Michel Lanners
2000-08-18 21:02 ` Michel Lanners
2000-08-19 6:47 ` Daniel Jacobowitz
2000-08-19 7:18 ` Michel Lanners
2000-08-19 11:59 ` Benjamin Herrenschmidt
2000-08-19 14:15 ` XF4 hangs on 2.4 kernel (was: Re: Control fb problem on 8500) Michel Lanners
2000-08-19 15:16 ` Martin Costabel
2000-08-23 12:18 ` Kostas Gewrgiou
2000-08-19 12:12 ` Control fb problem on 8500 Geert Uytterhoeven
2000-08-21 11:25 ` Michael Schmitz
2000-08-21 13:19 ` Michel Dänzer
2000-08-21 16:44 ` Geert Uytterhoeven
2000-08-21 17:11 ` Michael Schmitz
2000-08-19 13:20 ` Michel Dänzer
2000-08-21 8:57 ` Michel Dänzer
2000-08-21 10:46 ` Geert Uytterhoeven
2000-08-21 13:14 ` Michel Dänzer [this message]
2000-08-21 16:45 ` Geert Uytterhoeven
2000-08-22 8:33 ` Michel Dänzer
2000-08-22 9:42 ` Geert Uytterhoeven
2000-08-22 10:14 ` Michel Dänzer
2000-08-22 21:15 ` Michel Lanners
2000-08-22 21:55 ` Michel Dänzer
2000-08-23 11:51 ` Geert Uytterhoeven
2000-08-22 21:10 ` Michel Lanners
2000-08-22 22:39 ` Michel Dänzer
2000-08-23 8:11 ` Michael Schmitz
2000-08-23 8:21 ` Michel Dänzer
2000-08-21 11:33 ` Michael Schmitz
2000-08-19 14:40 ` David Riley
[not found] <200008160459.XAA20764@lists.linuxppc.org>
2000-08-22 10:51 ` William H. Schultz
2000-08-22 11:56 ` Benjamin Herrenschmidt
2000-08-22 16:52 ` Geert Uytterhoeven
2000-08-23 14:03 ` William H. Schultz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=39A12B3E.44294E59@student.ethz.ch \
--to=daenzerm@student.ethz.ch \
--cc=dmj+@andrew.cmu.edu \
--cc=geert@linux-m68k.org \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=mlan@cpu.lu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.