> To: Herb Peyerl <hpeyerl@beer.org>
> Subject: Re: How I got multi-headed X to work on my 370 
> From: Jason Thorpe <thorpej@nas.nasa.gov>
> Date: Tue, 15 Oct 1996 13:43:09 -0700
> 
> On Tue, 15 Oct 1996 07:57:53 -0600 
>  Herb Peyerl <hpeyerl@beer.org> wrote:
> 
>  > Anyway, Jason has physically stood in front of my machine and seen it himself
>  > so he can attest that I'm not on drugs as has been suggested (HI DAVE!). 
>  > Neither of us has any idea what's wrong. It looks to me like some sort of 
>  > weird mapping problem but I have O(0) familiarity with the workings of X
>  > so it could be almost anything...
> 
> Yah, I've actually seen it, and to be honest, I can't really explain it.
> 
> I was guessing that the GRFIOCMAP ioctl was getting the mapping wrong
> (it basically `emulates' the call to mmap()), but you'll notice that
> it nails down the address at 0x1000000 in the non-fixed case.
> Really, the X server shouldn't need to say "map it here", it just
> needs to say "map it" ... and the last I checked, it just just say
> "map it".  My thought was that the process was mapping both
> framebuffers non-fixed and getting them both at the same VA!
> I'm almost wondering how it can work at all!  Of course, I may be
> missing something (Mike? :-)
> 
> So, you'll noticed the bit of code in grfmap() that's got all of the
> XXX's next to it... that should probably be re-written...
> 
It has been a long time since we did multiple displays on our BSD.
As I recall we did it with a topcat and a davinci card and using the HP-UX
X server so my experience is of little value.

We had a problem once with "exploded" text using the ITE interface.  That
turned out to be a problem with how we unpacked the default font stored in
the ROM.  You could possibly get a similar garbage effect if the framebuffer
DESCRIBE ioctl was returning incorrect geometry info for the second display.

It seems unlikely that the two framebuffers are mapped at the same location,
the effect would be much more destructive I think.

The most amusing garbage display we ever had was when we were accidentally
getting the wrong address (0) and size (very large) for a copy to the
framebuffer.  Wound up dumping a large portion of the kernel to the display.
Nothing like visualizing your kernel, not a very interesting picture however.