On Fri, Feb 16, 2007 at 05:00:07PM +0000, Tim Phipps wrote: > Anyway, I wasted a fair amount of time wondering why the OK key of my > remote was the only one not working. I almost convinced myself the button > wasn't physically working and was just about to get the screwdriver and > meths out when I noticed the LED on my DVD player was blinking when I > pressed the OK button. I tried the input-events command and that > reported EV_KEY KEY_ENTER. So then I knew it was inputlirc that was not > passing it on. I reread the man page and finally guessed it was > filtering KEY_ENTER out because it was less than 88. Reading the man > page it looks like the intent of the default filtering number is to stop > you from stuffing yourself up with inputlirc grabbing all key events from > your keyboard and not being able to ctrl-c it. > > If you're not running inputlirc with -g though it won't grab the > keyboard and I don't see the need for the filter code of 88. Could you > add some code to not filter when not grabbed? or set the default to 1 > when not grabbed?
It's a little bit different. Without arguments, inputlircd opens all
input event devices. This allows you to have multiple remotes, and also
process the multimedia keys on contemporary keyboards with lirc. Because
it reads the main keyboard, without filtering any lirc client would be
able to see anything you typed, including passwords!
If you want your remote's OK button not to simulate pressing ENTER on
the keyboard, you should use the -g option, -m 0, and let inputlircd
work only on the input event device corresponding to your remote.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
