Closed GoogleCodeExporter closed 9 years ago
Hi,
Thank you for your input! Contrary to public perception, this project is very
much alive, but only further worked on time-permitting. I'm letting features
and bugs pile up before I swipe them all in the next development iteration. 8-)
I would be interested in your implementation and how you are grabbing events
from two keyboards at the same time (or one at a time but without restarting
logkeys). If you wish, you can attach relevant files here. Much obliged.
However, I'm not sure this is entirely right place for your suggestion. I
welcome your contribution, but I have absolutely nothing to do with xbindkeys.
Perhaps you should report this idea upstream (e.g.
https://savannah.nongnu.org/projects/xbindkeys/) or to other appropriate
group/place(s).
Thanks again. :-)
Original comment by kernc...@gmail.com
on 20 Dec 2010 at 1:25
I guess I was too much brief in my previous post. The behaviour is the
same that previously, one keyboard at a time. My embeded system (an
"smart-tv") consists of two keyboards. One acts (and looks) like a
remote control like those on a TV or Video recorder. The second one
acts (and looks) like a normal keyboard. I was just interested in
trapping keys pressed from the first one, so that a user can power
on/off by pressing a key in the "remote", while the normal keyboard
continues to work as always. Since both keyboards shared the same
keycodes for some physical keys, I was forced to enable/disable one or
other depending on the context where the user was at that moment,
since there is no way in X to differentiate where the key event came
from.
Also the system had an extra dependency on X (the fewer dependencies,
the best ;) ).
I send attached the custom modified logkeys.cc. As you will see it
probably has nothing interesting at this moment, It just disables a
few thing that didn't match my purposes as a xbindkeys replacement. In
particular I allowed repeated keys to be logged as repeated keys, and
disabled the check for Ctrl+D/Ctrl+C, so that an auxiliar background
process could easely parse the generated logfile and react in a few
tens of second to each key press.
OK. Capturing keys at kernel level offers a lot of potencial for
embedded and desktop systems, not just for logging purposes so I
thought it could be an interesting feature request.
You are wellcome! Thanks to you!
Original comment by enrique....@gmail.com
on 20 Dec 2010 at 5:37
Original issue reported on code.google.com by
enrique....@gmail.com
on 20 Dec 2010 at 10:57