Re: [patch] VRAM detection in controlfb

quoted

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 ...

quoted

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/