Linux / X11 I / O library without window creation

Is there a good library for collecting user input on Linux with the mouse / keyboard / joystick that doesn't force you to create a visible window for this? The SDL allows you to enter the user in a reasonable way, but it seems to make you create a window, which is unpleasant if you have abstract control, so the control machine should not be the same as the rendering machine. However, if the control and rendering machines are the same, this leads to an ugly little SDL window on top of your display.

Edit to clarify :
The renderer has an output window, in its usual case, this window is full-screen, except when they both work on the same computer, so you can give the focus of the controller. In fact, there may be several visualizers displaying different representations of the same data on different computers that are controlled by the same controller, therefore, the complete decoupling of input from the output (taking advantage of the built-in client / server in X11 for display is less suitable for use ) It is also possible to use several controllers for one visualization tool. Communication between controllers and visualization tools is done through sockets.

+7
linux user-input sdl
source share
2 answers

OK, if you are under X11 and want to get kbd, you need to do a capture. If you do not, my only good answer is ncurses from the terminal.

Here's how you select everything from the keyboard and release again:

 / * Demo code, needs more error checking, compile
  * with "gcc nameofthisfile.c -lX11".

 / * weird formatting for markdown follows.  argh!  * /

#include <X11/Xlib.h>

 int main (int argc, char ** argv)
 {
    Display * dpy;
    XEvent ev;
    char * s;
    unsigned int kc;
    int quit = 0;

    if (NULL == (dpy = XOpenDisplay (NULL))) {
       perror (argv [0]);
       exit (1);
    }

    / *
     * You might want to warp the pointer to somewhere that you know
     * is not associated with anything that will drain events.
     * (void) XWarpPointer (dpy, None, DefaultRootWindow (dpy), 0, 0, 0, 0, x, y);
     * /

    XGrabKeyboard (dpy, DefaultRootWindow (dpy),
                  True, GrabModeAsync, GrabModeAsync, CurrentTime);

    printf ("KEYBOARD GRABBED! Hit 'q' to quit! \ n"
           "If this job is killed or you get stuck, use Ctrl-Alt-F1 \ n"
           "to switch to a console (if possible) and run something that \ n"
           "ungrabs the keyboard. \ n");


    / * A very simple event loop: start at "man XEvent" for more info.  * /
    / * Also see "apropos XGrab" for various ways to lock down access to
     * certain types of info.  coming out of or going into the server * /
    for (;! quit;) {
       XNextEvent (dpy, & ev);
       switch (ev.type) {
          case KeyPress:
             kc = ((XKeyPressedEvent *) & ev) -> keycode;
             s = XKeysymToString (XKeycodeToKeysym (dpy, kc, 0));
             / * s is NULL or a static no-touchy return string.  * /
             if (s) printf ("KEY:% s \ n", s);
             if (! strcmp (s, "q")) quit = ~ 0;
             break;
          case Expose:
                / * Often, it a good idea to drain residual exposes to
                 * avoid visiting Blinky Fun Club.  * /
                while (XCheckTypedEvent (dpy, Expose, & ev)) / * empty body * /;
             break;
          case ButtonPress:
          case ButtonRelease:
          case KeyRelease:
          case MotionNotify:
          case ConfigureNotify:
          default:
             break;
       }
    }

    XUngrabKeyboard (dpy, CurrentTime);

    if (XCloseDisplay (dpy)) {
       perror (argv [0]);
       exit (1);
    }

    return 0;
 }

Run this from the terminal, and all kbd events should hit it. I test it under Xorg but it uses the venerable, stable Xlib mechanisms.

Hope this helps.

BE CAREFUL with captures under X. When you are new to them, sometimes it’s a good idea to start a time delay process that will cancel the server when you are checking the code and letting it sit and run and take pictures every couple of minutes. This saves on killing or switching from the server to the external reset state.

From here I will leave it to you to decide how to multiplex the rendering. Read XGrabKeyboard documents and XEvent documents to get started. If there are small windows at the corners of the screen, you can mash the pointer into one corner to select a controller. XWarpPointer can drag the pointer to one of them, as well as from the code.

Another point: you can grab a pointer, as well as other resources. If you had one controller running on the box in front of which you are sitting, you can use keyboard and mouse input to switch between open sockets with different renders. With this approach, you no longer need to resize the output window to full screen. With a lot of work, you could actually reset the alpha-mixed overlays on top with the SHAPE and COMPOSITE extensions to get a nice overlay function in response to user input (which can be considered gilding lilies).

+7
source share

You can use GPM for the mouse.

I'm not sure from the top of my head for a keyboard or joystick.

Perhaps it would not be so bad to read the files there /dev , if necessary.

Hope this helps

+2
source share

All Articles