[AD] X: sending input events down a different display connection

[George Foot <gfoot@xxxxxxxxxx>]

Some time ago Michael Bukin suggested that the input events,
which form the main part of the asynchronous traffic on the X
display connection, could be routed through a different
connection.  This means that all X operations performed inside
the SIGALRM handler must use the special display connection; the
advantage is that the user can use the main connection without
having to disable the interrupts.

I'm attaching a patch which nearly does this.  The new
connection is set up and used for event tracking.  There are two
things which aren't done yet.  Firstly, Expose events -- these
cannot be handled on the new display connection, because they
involve drawing to the window which is only allowed on the
display connection that created it (I think).  Secondly, the
close button doesn't work -- AFAICS the event never arrives on
the new connection.

Currently the expose problem is just not solved -- so the main
connection is still being used inside the signal handler.  The
close button just doesn't work.

My only suggestion for fixing these things is to have a separate
event handler for Expose events and ClientMessage events.  These
would be handled by the main display (_xwin.display), while all
other events would still be handled by the dedicated
_xwin.event_display.  The default would be to poll both displays
for events inside the signal handler, which requires users to
wrap up any of their own X code neatly.  The automatic polling
of the main display would be optional though -- the user would
be able to choose to do this manually.  The main result of this
would be that if the user doesn't frequently poll for events,
the window's contents will get temporarily corrupted.

Does anybody have any comments about these changes?  I'm
reluctant to make changes just for the sake of AllegroGL which
would have a negative impact on normal programs.  So far these
changes should have no impact, but the solution is not
especially neat, and even if it's done this way there will still
be the need for the event polling call, which does not really
match up with anything else in Allegro.

There are other solutions to the problem AllegroGL is facing
here, which I'm going to put in separate emails.

George

-- 
Random project update:
09/05/2000: Libnet 0.10.8 uploaded -- a few bugfixes
        http://www.canvaslink.com/libnet/  (try changes-0.10.8.txt)