From: Gerd K. <kr...@by...> - 2003-08-20 09:45:24
|
> there alot of places where handling them as keyboard keys would help out > alot (apps that dont use the lirc client lib) but you're right mixing > these might be hard, maybe setting an option for the decoding deamon > that will tell it how to send them back? The input layer allows to grab a input device, i.e. ask for exclusive access to that device. By default every process having /dev/input/event<x> opened will see all input events. If someone grabs the device nobody else will see those events (including the linux console layer). That can be used to enable/disable the linux console seeing the IR keys. I think it is next to impossible to do that with the current implemenation (lirc client library does focus handling), because this scheme requires that all clients see all IR events. Thus it isn't a option to "grab" the input device. Handling the focus in the client library has another fundamental issue too: two application may have a different idea of who the focus currently has. So it might be worth rethinking that approach. Another issue already raised on that list are multimedia keyboards. It makes sense to handle the vol+/- keys on multimedia keyboards much like vol+/- keys on the IR remote. One way to do that is having lirc (either lircd or client library) read from keyboards events via /dev/input/event<x> and react on the multimedia keys like in IR input. Again it is problematic to grab the device in that scenatio because that would disable the whole keyboard which is probably not what you want. It would probably be useful to have some better event routing and/or filtering capabilities in the input layer ... Gerd -- sigfault |