[GRASS5] Windows native Xdriver

GRASS GRASS developer
1

Hi all.

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, 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 am also conscious that the driver reportedly does not work on Windows 98, so will also try and look into that. It would help if someone could briefly report the symptoms so that I know whether they are the same as listed above or not.

Has anyone used the native Windows Xdriver to do real work with Grass?

Cheers

Mike Thomas

2

On Tue, Apr 30, 2002 at 07:34:11PM +1000, Mike Thomas wrote:

Hi all.

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, 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 am also conscious that the driver reportedly does not work on Windows 98, so will also try and look into that. It would help if someone could briefly report the symptoms so that I know whether they are the same as listed above or not.

Has anyone used the native Windows Xdriver to do real work with Grass?

Hi Mike,

my boss uses it all the day... On windows2000.

Also others run it successfully.

Markus

3

my boss uses it all the day... On windows2000.

Also others run it successfully.

Good news. Do you know which versions from CVS they are using?

4

On Tue, Apr 30, 2002 at 08:43:44PM +1000, Mike Thomas wrote:

> my boss uses it all the day... On windows2000.
>
> Also others run it successfully.

Good news. Do you know which versions from CVS they are using?

Here we compiled it from pre3. The others are probably using
our binary version which is on the web site.
However, I cannot remember recent changes.

May it be related to the $LOCATION change (I guess not)?

Markus

5

Hi Markus.

Here we compiled it from pre3. The others are probably using
our binary version which is on the web site.
However, I cannot remember recent changes.

Thanks.

May it be related to the $LOCATION change (I guess not)?

I'll have to look that one up as I've been an inattentive mailing list
reader lately. Does it apply to both head and prerelease?

Mike Thomas.

6

Hi Mike,

On Tue, Apr 30, 2002 at 09:16:34PM +1000, Mike Thomas wrote:

> May it be related to the $LOCATION change (I guess not)?

I'll have to look that one up as I've been an inattentive mailing list
reader lately. Does it apply to both head and prerelease?

Yes, that's correct. The $LOCATION must be constructed now.
In scripts the 'g.gisenv' is evaluated (see the scripts in
$GISBASE/scripts/).

However, I didn't find any LOCATION in
src/display/devices/windows/
so the problem will be different.

Markus

7

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@virgin.net>

8

Hi Glynn.

Thanks for the help.

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.

I was afraid you might say this, as I was getting nonsense from the call to
open() when I tried returning the fd instead of 999 (and also in a small
test program which I am following up in more detail).

I was hoping that this might not have been relevant to the problem, but it
seems that we have both arrived at the same place.

Cheers

Mike Thomas.

9

Mike Thomas wrote:

> 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.

I was afraid you might say this, as I was getting nonsense from the call to
open() when I tried returning the fd instead of 999 (and also in a small
test program which I am following up in more detail).

I'm wondering if this code was meant to open "/dev/windows" instead.

I've committed a change which uses /dev/windows. This works at first,
but eventually XDRIVER dies. I'd appreciate feedback on what happens
on NT/2K/XP, in case this is another Win9x bug.

Note: nothing should actually be read from /dev/windows. The
descriptor returned by XConnectionNumber() is passed to select(), in
get_connection_sock(), and in Get_Xevent(). Both of these functions
use select() to wait until either the monitor socket or the X
connection become readable.

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