>From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
>[entropy wrote:]
>>Additionally, it looks like Xcfbpmax and/or mfb.c are out of whack
>>again.  I had to lie in mfb.c by setting fi->fi_type.fi_width to 2048
>>to get a usable X display on this machine.  (That has the unhealthy
>>side effect of making almost half the X display invisible, but at
>>least the visible part is sort of usable.)
>
>Uh, oh. It works okay for me on a cfb.  I seem to remember you have a
>machine with an MFB; is this it?  has an MFB in it.  The raster lines
>in an MFB are indeed 2048 bytes apart in memory.  I'm guessing
>that's the problem.   If it is an MFB, which Xserver are you using?

It is an mfb ("cnfg 0" reports: PMAG-AA DEC V1.0a TCF0 (MX -- d=1))
and I used Xcfbpmax.  I also tried Xmfbpmax just for completeness's
sake...with different incorrect results on the display.  At one time I
think Xsfbpmax also worked on this hardware, but that seems to have
been obsoleted and removed from the distribution.  Is there an old
copy anywhere I could try?

I believe your description of the raster memory matches what I
remember from the last time we visited this type of problem.  My
suspicion is that older Xcfbpmax's read and used the fi_linebytes
field but the newer one is ignoring this field in favor of the
geometry reported in fi_type.fb_width.  I don't have X server source
so this is only a guess.

>I think your fix is going to cause xdpyinfo to show the screen
>as being 2048x1024, which is wrong; it should be 1280x1024.

Yes, that is the case.  I don't expect this to be used as a real "fix"
since it's clearly wrong in unacceptable ways, but it's useful as a
temporary kludge.

Cheers,
entropy

--
entropy -- it's not just a good idea, it's the second law.