nanogui: nano-X driver stability discussion
Subject:
RE: nano-X driver stability discussion
From:
Alex Holden ####@####.####
Date:
20 May 1999 19:13:43 -0000
Message-Id: <Pine.LNX.4.04.9905201945180.382-100000@hyperspace>
On Thu, 20 May 1999, Greg Haerr wrote:
> Okay. I admit I haven't spent too much time playing with the client/server
> configuration. (Also there was a bug in the GrText() call over the network
> that I never could figure out)
I had a look at it, and the problem was just that the client wasn't
reading all the data returned from an earlier call, and that data was
staying queued in the network buffers, so when it sent the GrText() call,
it was reading garbage back. Due to the total lack of error handling, the
server and client both ended up blocked forever in read() as they were
expecting the other to send them something. The real answer is the total
rewrite I'm working on now, which does things much closer to the way X
does it, ie. it packages calls up in a message queue, and sends them all
at once when the client does a Grflush(), or any call which reads data
back from the server.
> Probably a good idea. I was just looking for some stable driver
> release.
Hopefully it shouldn't be too long.
> I'll wait. BTW, I've created a portable VGA 4 planes driver that
> runs unmodifed on linux, dos, and elks. My first release included assembly
> language, but, after looking at Ben's bogl-vga16.c, I have found a way to
> make a common driver from it that doesn't include os specific headers...
Cool.
--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------