Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!sri-spam!ames!ucbcad!ucbvax!BFLY-VAX.BBN.COM!cdh
From: cdh@BFLY-VAX.BBN.COM
Newsgroups: comp.windows.x
Subject: Re: Fix to allow Sun 3/110s to use the X windows system
Message-ID: <8703171448.AA12667@ATHENA>
Date: Tue, 17-Mar-87 09:09:14 EST
Article-I.D.: ATHENA.8703171448.AA12667
Posted: Tue Mar 17 09:09:14 1987
Date-Received: Thu, 19-Mar-87 00:36:12 EST
References: <15099@sun.uucp>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 60

David,

Sorry to hear you don't think my changes are sufficient.  Note that
they do work here on our 110 under 3.2.

> This is not too strange -- it has to default to bw2 emulation mode
> because there is no way to go back in time and insert mode-changing code
> in old binaries.  It is *not* necessary to change the the emulation mode
> to run color applications, so it should be left alone unless you have a
> very good reason.

X does have a very good reason; it wants to do a FBIOGTYPE to find out
what kind of display it is running on.  The 3/110 hands back 2 and a
depth of 1, which means that all the following setup will believe that
it is running on a monochrome display.  The only way I've found to
make FBIOGTYPE return correct values for the display type is to tell
it to change the emulation mode to 8.  If you have other ways that are
nicely device independent, it would be nice to hear them.

> This solution is too complicated.  There is no need to do any frame
> buffer ioctls in InitDisplay since all the information needed is encoded
> in the pixrect "PixRect".  Here is the code I have been using:
> 	Display = pw_open(vsdev);
> 	PixRect = Display->pw_pixrect;
> 	info->id = PixRect->pr_depth > 1 ? XDEV_SUN2COLOR : XDEV_SUN2BW;
>	info->planes = PixRect->pr_depth;
> 	info->entries = 1 << PixRect->pr_depth;
>	if (PixRect->pr_depth == 1)
>		pw_reversevideo(Display,0,1);
> 
> (The info->id isn't used for anything so it doesn't have to be exactly
> right.)

Perhaps I'm just slow, but this doesn't look like it will work to me.  
The PixRect->pr_depth I got returned without the ioctls was always 1
on the 3/110.  Therefore, the code you represent would just set the
display up so that it was a true monochrome display.  Not exactly what
you want.

> The most important bug was omitted -- it doesn't work!  The cursor and
> text code relies on the modified semantics of the supplied cg2_batchrop.
> The batchrop functions in the pixrect library (including mem_batchrop)
> follow (documented) pixrect semantics.

Perhaps you can point out to me what doesn't work.  I've been using my
mods here and not had any real trouble with either text or cursor
displays.  (I take that back; the foreground and backgrounds for text
have not been perfect, but I've assumed that was my own clumsiness in
setting them up).

I do apologize to people if my proposed solution was incorrect.  Our
3/110 was delivered with *NO* documentation on the display buffer and
with no indication that it was incompatible with the cg2.  When X
didn't run on it, we were faced with having it always be monochrome or
doing something to make it work.  I did something to make it work, and
thought other people might benefit.  I will gladly accept simpler or
more elegant solutions provided that someone has gone to the time and
effort to test them before posting.

Carl