[comp.windows.x] Problems with Apollo SR10.0 & X.V11R2

paul@cacilj.UUCP (Paul Close) (09/09/88)

I've just finished getting X11 R2 up and (mostly) running on an Apollo 4000
running the brand new SR 10.0 (FCS [First Customer Ship]).  Well, MOST of
it works!  I have not built an Apollo X before, so I don't know of any "tricks"
that may be required.  Here are my problems:

Building:

    o	the new cpp is up to making Makefiles, so I did.  Make sure and
	define "-A nansi" since cpp doesn't do token concatenation like
	ANSI says it should (a##b -> ab).  Apollo, are you out there?

    o	server/ddx/apollo/ap_text.h is missing a #endif!  I don't know
	why this wasn't noticed earlier!  server/ddx/apollo/apc/apctext.h
	has the same problem.  Also, do an obj2coff on apcfont.bin.

    o   After the fixes, lib/X/XConnDis.c references <netinet/tcp.h>
	which doesn't exist.  I just commented this out.  Will this
	cause problems?

That's all I remember.  After that, most things worked.  The notables that do
work are xterm, xclock, xinit (Xapollo), xconq (yea!), xmille, and xedit.  On
to the problems:

    o	in xconq, a call was made to usleep which bombed for some reason.
	I replaced it with a call to select.

    o	The cursors (i.e. the "X" cursor, the "I" xterm cursor, etc) in
	monochrome are not correct.  The "X" doesn't have a white
	border, the "I" is actually just a "X" with the edges trimmed,
	and the "L" uwm cursor is actually an arrow!  This is only
	in monochrome--color works just fine in this respect.

    o	programs that use SendXYImage hang up in _XSend doing an infinite
	loop through WritevToServer (a/k/a writev) and _XWaitForWritable.
	what happens is writev returns -1 with errno=EWOULDBLOCK, which
	causes a trip through _XWaitForWritable which immediately says
	"go ahead", and writev returns the same thing, causing an infinite
	loop.  What's up here?  Are Apollo's sockets not working?!?
	The program that doesn't work is xphoon (and setroot -bitmap).
	Note--this is a rather hefty sized bitmap (960x848), but it
	*should* work.  xsetroot -bitmap hangs in the same way on really
	large bitmaps.

    o	if the above bug doesn't bite xsetroot -bitmap, on bitmaps like
	"flagdown" (48x48) or "woman" (75x75), the tiling doesn't work
	correctly.  The tiles run all the way across the top of my screen,
	wiping out my xterm!  The "top" happens to be the top of my other
	xterm window.  Sounds like an algorithm bug....

    o	for reasons unknown, the keyboard and mouse will freeze up and I
	have to reboot.  The machine still seems to be running, but I
	can't do anything without a keyboard or mouse!  Once it happened
	after running fine all night, another time during testing of
	xphoon (see above).  Is this the server jamming up, or what?

    o	not really a bug, but who decided to put "meta(POP)" so far away
	from "shift([v])" and "control([^])"?!?  Try doing a "M-shift" as
	required for uwm (do people actually use this server?!?).  I have
	a "type-3" keyboard, and I'd like to use it, thank you.

I can't proceed from here.  Any help would definitely be appreciated!
I hope X11R3 works better than this!

Thanks for listening,
-- 
Paul Close	paul@cacilj.CTS.COM 	...!{uunet, ucsd, crash}!cacilj!paul

Shaw's Principle:
  Build a system that even a fool can use, and only a fool will want to use it.