All of lore.kernel.org
 help / color / mirror / Atom feed
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;

  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.