Re: Control fb problem on 8500

Michel Dänzer wrote:

Michel Lanners wrote:

quoted

On  18 Aug, this message from Daniel Jacobowitz echoed through cyberspace:

quoted

quoted

In fact, before, the line length was exactly hpixels * bytes/pixel,
whereas now there's an additional 0x20 bytes in each line. I have not
been able to boot a 2.4.0 kernel with any fix applied, but you could try
and build a version without those 0x20 bytes added (they are found in a
few spots inside controlfb.c).

As to why these 0x20 bytes were added, anybody know an explanation? And,
if they do serve a purpose (I suppose so ;-), it would be better to add
the exact number of bytes as a #define somewhere...

*sigh*

I have no idea where this came from, but 0x20 means it has something to
do with cursor support, I'd bet.  I seem to recall someone talking
about that a few months ago... that is how hardware cursor is generally
implemented, by a 32 pixel block at the end of the scanline.

That's what I was thinking about. However, I'm not sure that XFree
supports a display with discontiguous lines in video memory. I think I
read that somewhere in some mailing list or X doc... Can any of the
XFree specialists confirm?

It does support that, if not directly then certainly via shadowfb. Maybe the
shadowfb RefreshArea function would have to be modified to take account of
this.

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.


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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/