Problem with handling of synthetic X events

Problem with handling of synthetic X events

Post by bme.. » Sat, 22 Nov 1997 04:00:00



First, let me apologize form posting this to a slightly inappropraite
newsgroup --- of the groups available to me, it is the closest matching
one.

Now, as for the problem: I have one nice ALPHA machine running linux,
which has a busted keyboard controller. While I can configure it via
the serial port and use it remotely via telnet, I can not make any
use of X on that machine at the moment.
This prompted me to consider using another machine (my otherwise unused
laptop) as a "fancy keyboard controller", running X on it, grabbing all
the keyboard events and sending them to the ALPHA's X server via
XSendEvent. I wrote a very small program to do so, with the main event
loop the following:

    for (;;) {
        XEvent event;

        XNextEvent(display, &event);

        switch(event.type) {
         case KeyPress:                
         case KeyRelease:
           {
             int x;

             x=XSendEvent(display2,InputFocus,True,eventmask,&event);

             printf("Here we forward events! Got %d\n",x);
             XFlush(display2);
           }
        }
    }

where "display2" is the connection to the ALPHA's X server.

This seems to work fine for some apps (Arena is perfectly happy, XV
is, xev is). Unfortunately, it doesn't work at all for other apps
(xterm, xcalc, emacs). I have tried varying the window and propagate
parameter to XSendEvent, but the above combination seems to work best.

Any idea why that is? Are those apps getting their keypresses by
watching events other than KeyPress and KeyRelease? Or are they paranoid
about synthetic events? I know xterm is, but even when "Allow SendEvents"
is enabled in the menu, it doesn't work.

On a more general note --- would there be some interest for splitting the
keyboard handler into a low level part (that actually talks to the hardware)
and a high (or "not quite so low") level part that handles the visible
side of things, i.e. providing X, the consoles and SVGAlib programs with
keyboard services?
The motive is that I have lots of linux machines, and at the moment need either
a switchbox (always resetting the keyboard, very annoying; Also requiring
me to take away the hands from the keyboard), or lots of keyboards (even
worse) when I want to actually use X or the consoles on a machine other
than my main one. The idea is to have a user level hook between the two
parts of the keyboard driver, allowing to have

a) an input manager that listens for stuff from the low level driver, and
   if it gets it, sends it on to
b) a virtual keyboard manager, which feeds that stuff back to the high
   level driver.

If no input manager had the relevant device open, the kernel could simply
hand everything from the low level to the high level part of the driver,
giving the exact same behaviour as it does now. However, once an input
manager is running, it could serve several virtual keyboard managers on
different machines, switching between them when it receives special
key presses (like Windows-key plus F1, F2 etc).

Well, anyway --- any ideas how I can make that nice ALPHA work with X?

Bernie

--
============================================================================
"It's a magical world, Hobbes ol' buddy...
                                           ...let's go exploring"
Calvin's final words, on December 31st, 1995