[GRASS5] Windows native Xdriver

[Glynn Clements]

Mike Thomas wrote:

> Since last I worked on the Grass native Windows Xdriver two things seem
> to have gone wrong under Windows XP:
> 
> 1.  It doesn't work at all in the CVS head version of Grass.
> 
> 2.  It displays maps (d.rast, d.vect, d,erase etc) in the
> releasebranch_26_april_2002_5_0_0 tag version

Odd. As the name implies, releasebranch_26_april_2002_5_0_0 was only
created a few days ago; the code in that branch should be almost
identical to the head (certainly, there shouldn't be any differences
which affect the drivers).

> but doesn't react to
> being exposed (after being covered by other windows) or resized, until
> AFTER a new Grass display command (d.rast,d.vect, d,erase etc) is
> executed.  For example, if a raster map is displayed and the Xdriver
> window is covered over by another window then uncovered, the white patch
> does not go away until a command like d.vect is executed.  
> 
> In other words, events seem to be getting buffered somewhere, whereas
> once they were not.
> 
> Having a few weeks holiday at the moment I am poking around in the
> source, but so far with no headway.  Has anyone any hints about changes
> made since last November which might affect event handling in this way?

I can think of one change which might cause this. When no client is
connected, XDRIVER no longer polls the monitor socket; instead, it
uses select() to wait until either a client connects, or until an
event can be read from the connection to the X server.

For this to work with libW11, the descriptor returned by
ConnectionNumber() would have to be readable according to select().

Currently, libW11/w32/xlib.c has:

int
XConnectionNumber(Display* display)
{
	int fd;
	NT_debug ("XConnectionNumber\n");
	fd = open ("/tmp/windows", O_NONBLOCK, 0);
	return 999;
}

This won't work, but returning "fd" might.

-- 
Glynn Clements <glynn.clements at virgin.net>