[patch] VRAM detection in controlfb
Michael Schmitz
schmitz at zirkon.biophys.uni-duesseldorf.de
Thu Jun 8 01:20:54 EST 2000
> > Now you understand the fix is very simple:
> > - fPtr->fboff = fPtr->fix.smem_len & (PAGE_SIZE-1);
> > + fPtr->fboff = fPtr->fix.smem_start & (PAGE_SIZE-1);
>
> That's not sufficient (perhaps it is in this case, though): both fix.smem_start
> and fix.smem_len may be not page aligned. To catch all cases, you have to use
> the formula from my previous posting.
Did that just get lost between XFree release 3 and 4, or did we have it
wrong all along? I wonder if that was what caused problems on some m68k
Mac video hardware ...
> > Yes, this is wrong as the authur noted, but interestingly this code spreads
> > over the all drivers supporting fbdev, though I can't distinguish which is
> > the original :^) Maybe polite solution is to fix each driver, but quick
> > fix will be
> >
> > + pScrn->displayWidth = fPtr->fix.line_width /
> > + (fPtr->var.bits_per_pixel >> 3)
>
> Typo: the field is called `line_length', not `line_width'.
>
> And that formula is valid for chunky displays only, not for interleaved
> bitplanes (I suppose pScrn->displayWidth is the width of one line in memory,
> counted in pixel units?).
>
> If line_length is 0, you must fallback to xres_virtual / bytes_per_pixel.
Is the displayWidth / xres_virtual synonymous to the line length (offset
between start of subsequent lines), or might displayWidth be used for
something else altogether? displayWidth seems a misnomer (on some
hardware, there's no video RAM between the end of one scan line and the
probably page aligned start of the next ...)?
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev
mailing list