Subject: Re: xfs yet again...
To: maximum entropy <entropy@zippy.bernstein.com>
From: Michael L. Hitch <osymh@terra.oscs.montana.edu>
List: port-pmax
Date: 11/16/1997 20:13:24
On Nov 16,  4:10pm, maximum entropy wrote:
> >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
...
> >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 have no idea of how Xsfbpmax was created, unless it was a modified
version of Xcfbpmax with the framebuffer geometry modified for the sfb.
It may still be available from ftp.unit.no, and I probably still have
one laying around someplace.

  The original Xcfbpmax had the width and height hard-coded as constants
to 1024x864.  I suspect Xsfbpmax was created from this version.  A patch
to Xcfbpmax was later applied that attempted to make it dynamically
support different framebuffers by getting the values returned by an
ioctl().  This was supposed to support the 3100 color display, the TC cfb,
the 5000/xx xcfb, and the TC mfb.

  I think I then modified this to make it work on the TC sfb card, but
I can see now that change would have broken the TC mfb support (not having
an mfb to test it on).

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

  The fi_linebytes value is not available to the X server - only the
display width is available.

  The reason it used to work is that the framebuffer width was being
calculated as:

    scrpixwidth = ((info->max_x + 1023) / 1024 * 1024

which resulted in 1024 for the 3100, cfb, and xcfb, but 2048 for the mfb.
It also tried to use 2048 for the sfb, which is incorrect.

  The current Xcfbpmax uses info->max_x directly, which makes it work
on all the color display, but will break the mfb.

  Since the real framebuffer width isn't directly available to the X server,
the only way I can see to fix it would be to just force the framebuffer width
to be 2048 if the depth is 1.

Michael