How to capture ALL key events, no focus/No-GUI

Hi everybody,
I've tried to figure out for some days, how I can capture ALL key events
even if I have no focus on my window or if my app is running without GUI.
Failed sofar :(
Using Fremantle/Hildon/GTK

Any suggestions are welcome!

Thanks!

On Thursday 28 January 2010 10:33:20 ext Stefan Iwanowitsch, you wrote:
> Hi everybody,
> I've tried to figure out for some days, how I can capture ALL key events
> even if I have no focus on my window or if my app is running without GUI.
> Failed sofar :(
> Using Fremantle/Hildon/GTK
>
> Any suggestions are welcome!

If you actually want to steal the keyboard input from other application, you
would normally send a GrabKeyboard request to the X server (XGrabKeyboard via
Xlib or xcb_grab_keyboard via XCB).

If you just want to see keyboard input, then you'd open the corresponding
file(s) in /dev/input/.

--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

On Thu, 2010-01-28 at 09:33 +0100, Stefan Iwanowitsch wrote:
> Hi everybody,
> I've tried to figure out for some days, how I can capture ALL key events
> even if I have no focus on my window or if my app is running without GUI.
> Failed sofar :(
> Using Fremantle/Hildon/GTK
>
> Any suggestions are welcome!

Have a look at the XTEST extension.

Xav

Rémi Denis-Courmont schrieb:
> On Thursday 28 January 2010 10:33:20 ext Stefan Iwanowitsch, you wrote:
>
>> Hi everybody,
>> I've tried to figure out for some days, how I can capture ALL key events
>> even if I have no focus on my window or if my app is running without GUI.
>>
> If you actually want to steal the keyboard input from other application, you
> would normally send a GrabKeyboard request to the X server (XGrabKeyboard via
> Xlib or xcb_grab_keyboard via XCB).
>
>
I want normal processing of keyboard events and just want to trigger
actions upon certain key combinations/sequences.
According to the documentation XGrabKeyboard() seems to prevent further
processing in other applications and there is no easy way to re-enqueue
key events I'm not interested in.
> If you just want to see keyboard input, then you'd open the corresponding
> file(s) in /dev/input/.
>
>
Can I read from /dev/input without interfering with other consumers? And
do you happen to know, where I can find specs on the input device files?

Thanks!

From: Stefan Iwanowitsch <stiw@ised.de>

> Hi everybody,
> I've tried to figure out for some days, how I can capture ALL key events
> even if I have no focus on my window or if my app is running without GUI.
> Failed sofar :(
> Using Fremantle/Hildon/GTK

I suppose that you are talking about all key events redirected to your
app.

You can try to install a key snooper:

http://library.gnome.org/devel/gtk/stable/gtk-General.html#gtk-key-snooper-install

If you are thinking in all key events in the device, I suppose that
this would be more complex.

===
API (apinheiro@igalia.com)

Piñeiro schrieb:
> From: Stefan Iwanowitsch <stiw@ised.de>
>
>
>> Hi everybody,
>> I've tried to figure out for some days, how I can capture ALL key events
>> even if I have no focus on my window or if my app is running without GUI.
>> Failed sofar :(
>> Using Fremantle/Hildon/GTK
>>
>
> I suppose that you are talking about all key events redirected to your
> app.
>
> You can try to install a key snooper:
>
> http://library.gnome.org/devel/gtk/stable/gtk-General.html#gtk-key-snooper-install
>
> If you are thinking in all key events in the device, I suppose that
> this would be more complex.
>
> ===
> API (apinheiro@igalia.com)
>
Key snooping just gives you an early view of key events intended for
your app. As soon as you loose focus you get nothing.
Isn't there perhaps a special window attribute or kind of a top level
where I can attach?!?


--

On Thursday 28 January 2010 11:53:13 ext Stefan Iwanowitsch, you wrote:
> > If you just want to see keyboard input, then you'd open the corresponding
> > file(s) in /dev/input/.
>
> Can I read from /dev/input without interfering with other consumers?

It should work yes.

> And do you happen to know, where I can find specs
> on the input device files?

/sys/class/input provides informations on each entries.

The protocol is documented in Documentation/input/ in the kernel sources:

| You can use blocking and nonblocking reads, also select() on the
| /dev/input/eventX devices, and you'll always get a whole number of input
| events on a read. Their layout is:
|
| struct input_event {
| struct timeval time;
| unsigned short type;
| unsigned short code;
| unsigned int value;
| };
|
| 'time' is the timestamp, it returns the time at which the event happened.
| Type is for example EV_REL for relative moment, EV_KEY for a keypress or
| release. More types are defined in include/linux/input.h.
|
| 'code' is event code, for example REL_X or KEY_BACKSPACE, again a complete
| list is in include/linux/input.h.
|
| 'value' is the value the event carries. Either a relative change for
| EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for
| release, 1 for keypress and 2 for autorepeat.

--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

On Thu, 2010-01-28 at 10:53 +0100, ext Stefan Iwanowitsch wrote:
> Rémi Denis-Courmont schrieb:
...
> >
> I want normal processing of keyboard events and just want to trigger
> actions upon certain key combinations/sequences.
> According to the documentation XGrabKeyboard() seems to prevent further
> processing in other applications and there is no easy way to re-enqueue
> key events I'm not interested in.

So you want keyboard shortcuts? Like shift+ctrl+p and the like? Then
you should use XGrabKey to grab that key combination only. See
libmatchbox2 sources for code.

Grabbing or monitoring the whole keyboard for a keyboard shortcut is not
the right way...

-Kimmo

> > If you just want to see keyboard input, then you'd open the corresponding
> > file(s) in /dev/input/.
> >
> >
> Can I read from /dev/input without interfering with other consumers? And
> do you happen to know, where I can find specs on the input device files?
>
> Thanks!

>
>> I want normal processing of keyboard events and just want to trigger
>> actions upon certain key combinations/sequences.
>> According to the documentation XGrabKeyboard() seems to prevent further
>> processing in other applications and there is no easy way to re-enqueue
>> key events I'm not interested in.
>>
>
> So you want keyboard shortcuts? Like shift+ctrl+p and the like? Then
> you should use XGrabKey to grab that key combination only. See
> libmatchbox2 sources for code.
>
> Grabbing or monitoring the whole keyboard for a keyboard shortcut is not
> the right way...
>
> -Kimmo
>

Hi, I managed to issue a grab after some fussing around, but I see no
reaction - shouldn't the grabbed keys be delivered to my application
just as as if I had the focus? Or do I need something special to receive
the grabbed keys?
Thanks for your help!

Rémi Denis-Courmont schrieb:
> On Thursday 28 January 2010 11:53:13 ext Stefan Iwanowitsch, you wrote:
>
>>> If you just want to see keyboard input, then you'd open the corresponding
>>> file(s) in /dev/input/.
>>>
>> Can I read from /dev/input without interfering with other consumers?
>>
>
> It should work yes.
>
>
>> And do you happen to know, where I can find specs
>> on the input device files?
>>
>
> /sys/class/input provides informations on each entries.
>
> The protocol is documented in Documentation/input/ in the kernel sources:
>
> | You can use blocking and nonblocking reads, also select() on the
> | /dev/input/eventX devices, and you'll always get a whole number of input
> | events on a read. Their layout is:
> |
> | struct input_event {
> | struct timeval time;
> | unsigned short type;
> | unsigned short code;
> | unsigned int value;
> | };
> |
> | 'time' is the timestamp, it returns the time at which the event happened.
> | Type is for example EV_REL for relative moment, EV_KEY for a keypress or
> | release. More types are defined in include/linux/input.h.
> |
> | 'code' is event code, for example REL_X or KEY_BACKSPACE, again a complete
> | list is in include/linux/input.h.
> |
> | 'value' is the value the event carries. Either a relative change for
> | EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for
> | release, 1 for keypress and 2 for autorepeat.
>
>
I set up some testcode to check the /dev/input/* files but I didn't read
a single byte from them.
Does this work with scratchbox?
Thanks for your help!