hanche@imf.unit.no (Harald Hanche-Olsen) (03/07/91)
We have been trying to build and operate the Xapollo (R4) server from the MIT source, with rather mixed success. When run in gpr mode, it operates fairly well, except for certain startup problems that I will make the subject of a separate posting. However, on monochrome displays we want to run it in mfb mode, as our experiments reveal this to be much faster. There is one small problem... Some clients display both foreground and background as black, whereas others appear to work normally. A little poking reveals that those which try to specify colors by name or rgb values turn out all black, while those who rely on WhitePixel and BlackPixel work OK. For example, xterm and xclock are all black if foreground and background are specified, but normal otherwise. So we wrote a minimal client which calls XQueryColor(d, DefaultColormap(d,s), ...) and prints out the resulting rgb values for pixel values 0 and 1. When run against the Xapollo server in gpr mode, the output is pixel 0: rgb = 0/0/0 pixel 1: rgb = 65535/65535/65535 but if run against the server in mfb mode, it is pixel 0: rgb = 0/0/0 pixel 1: rgb = 0/0/0 which seems crazy and ought to explain the odd behaviour of the server. Only question then is, why is this happening? I tried reading the server code, but found I could not make much sense out of it. If this is a known bug or similar problems have been seen by others, could someone please tell me? (The boring details: Machine is Apollo DN3000 with 19'' monochrome screen, operating system is SR10.3 (bsd4.3), compiler used is cc 6.8, source used is standard X11R4 distribution with fixes 1-18 applied). - Harald Hanche-Olsen <hanche@imf.unit.no> Division of Mathematical Sciences The Norwegian Institute of Technology N-7034 Trondheim, NORWAY
hanche@imf.unit.no (Harald Hanche-Olsen) (03/07/91)
In another post, I talked about our problems with the X11R4 Xapollo
server, as compiled from the standared sources and run in mfb mode.
Now I want to talk about problems with the same server in gpr mode:
It seems to work ok except for certain startup problems.
At the heart of the problem are three (undocumented?) calls
gpr_$init_wm(...), gpr_$$inq_rectangle_id(...), aws_$init(...) where
the latter returns the status code:
06090001 (not an resource ID (graphics/IDM/RM resource manager))
In the log file, I find this
----------------
apUnitScreenInit: aws_$init failed. 06090001
Fatal server bug!
no screens found
----------------
After this Xapollo exits, xdm starts a new one, and the process
repeats a number of times -- maybe zero, frequently two or three
times, occasionally up to ten times -- until the call succeeds and the
server comes up. The relevant code from
mit/server/ddx/apollo/ap_init.c looks like this (with some omissions):
----------------
static Bool
apUnitScreenInit(screenIndex, pScreen, argc, argv)
int screenIndex;
ScreenPtr pScreen;
int argc; /* these two may NOT be changed */
char **argv;
{
aws_$display_t scr;
scr.unit = 0;
scr.screen = pDisp->display_unit - 1;
/* Initializing a bunch of of data structures, deleted */
/*=>*/ gpr_$init_wm (gpr_$borrow, (short)(pDisp->display_unit),
disp, hi_plane, &pDisp->display_bitmap, &status);
apXSolo = (status.all == status_$ok);
if (apXSolo)
{
gpr_$rect_id_t rectID;
/* Get rectangle ID from gpr bitmap for root rectangle */
/*=>*/ rectID = gpr_$$inq_rectangle_id (&pDisp->display_bitmap, &status);
if (status.all != status_$ok)
{
xfree (pDisp);
return FALSE;
}
/* Init aws */
/*=>*/ (void) aws_$init (scr, rectID, &status);
if (status.all != status_$ok)
{
ErrorF("apUnitScreenInit: aws_$init failed. %08x\n", status.all);
----------------
and this is where we get the error message from.
Now, I cannot find any documentation for the three calls marked /*=>*/ above,
but it seems apparent that aws_$init will not accept the rectID
returned by gpr_$$inq_rectangle_id just before!?
Can anybody tell me where those calls are documented? Why do they
sometimes fail and sometimes succeed? If that is the way it has to
be, maybe I could let Xapollo loop on these calls until success,
rather than exiting and forcing xdm to start another Xapollo? So many
questions - and I have none of the answers. Suggestions are welcome.
- Harald Hanche-Olsen <hanche@imf.unit.no>
Division of Mathematical Sciences
The Norwegian Institute of Technology
N-7034 Trondheim, NORWAY