2

I know there has been a few of these, but a lot of the answers always to have a lot of buts, ifs, and you shouldn't do that.

What I'm trying to do is have a background program that can monitor the keyboard events from X11. This is on an embedded device, and it will have a main app basically running in something like a kiosk mode. We want to have a background app that manages a few things, and probably a back doors hook. But this app generally will not have focus.

I can't use the main app, because its partially there for a fail safe if the main app ever fails, or to do some dev type things to bypass the main app.

The best question I found is a few years old, so I'm not sure how up to date it is. This was extremely easy to do with windows.

X KeyPress/Release events capturing irrespective of Window in focus

Community
  • 1
  • 1
Kevin
  • 320
  • 5
  • 17
  • It's not clear, are you trying to assign a few "hotkey" combinations to the background application (each of which would do a particular operation or bring it to focus) or do you need to be able to enter long inputs into the background app while having the same input also delivered to whatever is currently focused? The first scenario can be achieved using XCB (xcb_grab_key) and that is the normal way to achieve such goals, while the second does not make much sense to me. – resistor May 27 '14 at 08:37

1 Answers1

6

The correct way for doing that is using Xlib. Using this library you can write code like this:

while (1)  {
    XNextEvent(display, &report);
    switch  (report.type) {

        case KeyPress:
            if (XLookupKeysym(&report.xkey, 0) == XK_space)  {
                fprintf (stdout, "The space bar was pressed.\n");
            }
            break;
    }
}

// This event loop is rather simple. It only checks for an expose event. 
// XNextEvent waits for an event to occur. You can use other methods to get events,
// which are documented in the manual page for XNextEvent.
    
// Now you will learn how to check if an event is a certain key being pressed.
// The first step is to put case KeyPress: in your switch for report.type.
// Place it in a similar manner as case Expose.

Also you could use poll or select on the special device file that is mapped to your keyboard. In my case is /dev/input/event1.

If you have doubts about what's the special file mapped to your keyborad, read the file /var/log/Xorg.0.log (search for the word keyboard).

Here you have another link of interest: Linux keyboard event capturing /dev/inputX

TheGoldenTree
  • 158
  • 4
  • 16
Raydel Miranda
  • 13,825
  • 3
  • 38
  • 60
  • Doesn't reading from the event device consume the event and i'll have to forward it to X? Also The event devices change, so I'd prefer not to have to manage figuring out which ones are keyboards (theres more than event devices GPIO keys and i2c key pads... ) – Kevin May 24 '14 at 00:31
  • I think I just found what you're looking for. Try **xlib** (http://tronche.com/gui/x/xlib/). Specialy section 10 **Events**. – Raydel Miranda May 26 '14 at 12:21
  • Hmm. I don't think i'll be finding a more up to date way. This way doesn't seem to work at all and I imagine I need a window to get it to work as specified by the link i provided. – Kevin May 27 '14 at 02:58
  • Well some time ago I used for controlling the pointer using a PlayStation 2 Joystick (USB), and I get some good results(no windows allows, just atached to the global screen). I'll search into my legacy code and see if I can find the code. – Raydel Miranda May 27 '14 at 12:08
  • great, i took some time to look into events again. I might be wrong about how events are read from process. Evtest doesn't appear to consume the event. I read somewhere that you need to pass the event along but that doesnt' look to be the case. And I'm poking around in the evtest code it definitely doesn't look like it passes the event to X. And evtest seems to work perfectly fine with X. – Kevin May 27 '14 at 18:52
  • Yeah, I was reading some docs to and saw some functions you can use for getting the "root window" of the active display. So you don't need create a new window for start to receiving events from `X`.And of of course if you are watching for events on the root window, you will be able to see all events. – Raydel Miranda May 27 '14 at 19:00
  • @BЈовић Thanks, since they do not give information about where they have move the content, I just remove the link. – Raydel Miranda Jul 20 '18 at 19:04