I don't want my IR handset to act like a keyboard
On Tue, 12 Jan 2010 19:25:11 +0100 Éric Piel e.a.b.p...@tudelft.nl wrote: Op 10-01-10 19:04, Tony Houghton schreef: I've got a DVB card with an IR controller which appears as an input device. I want my applications to read the input device directly, not as a keyboard. Among other reasons, it's because I want to use the OK button while mplayer is running, but it generates an Enter keypress which mplayer interprets as please quit. Interestingly, someone has been complaining of exactly the opposite: http://www.kernellabs.com/blog/?p=1309 That's obsolete too now, because of X not using hal any more. Maybe in your case, what you need is just a special keymap for the remote control, and make sure that applications listen to it only via X. The trouble with that is that I like my application, boxstar, to handle the remote presses and pass on commands to mplayer via its slave interface, but mplayer grabs focus away from boxstar, depriving it of X keyboard events. I don't want to have to rely on making special exceptions in the window manager. -- TH * http://www.realh.co.uk ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: I don't want my IR handset to act like a keyboard
On Tue, 12 Jan 2010 13:07:03 -0800 Paul Bender peben...@san.rr.com wrote: My solution to this problem is customized udev scripts. Essentially, if the device is a remote, then udev does not set x11_driver. Since x11_driver is not set, Xorg ignores the device completely. Oh good, that is still possible. Could you tell me how? I couldn't work out what to do, or even if there was anything I could do, from the udev docs. -- TH * http://www.realh.co.uk ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: I don't want my IR handset to act like a keyboard
On Tue, 12 Jan 2010 14:55:09 -0800 Dan Nicholson dbn.li...@gmail.com wrote: On Tue, Jan 12, 2010 at 2:50 PM, Tony Houghton h...@realh.co.uk wrote: On Tue, 12 Jan 2010 13:07:03 -0800 Paul Bender peben...@san.rr.com wrote: My solution to this problem is customized udev scripts. Essentially, if the device is a remote, then udev does not set x11_driver. Since x11_driver is not set, Xorg ignores the device completely. Oh good, that is still possible. Could you tell me how? I couldn't work out what to do, or even if there was anything I could do, from the udev docs. It's gone in master (and probably soon from debian/ubuntu). The server just grabs everything marked with ID_INPUT by udev. And I suppose if I removed ID_INPUT I wouldn't get the events I want from /dev/input/event* either. -- TH * http://www.realh.co.uk ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: I don't want my IR handset to act like a keyboard
On Mon, 11 Jan 2010 00:02:32 +0100 Tino Keitel tino.keitel+x...@tikei.de wrote: On Sun, Jan 10, 2010 at 18:04:35 +, Tony Houghton wrote: I've got a DVB card with an IR controller which appears as an input device. I want my applications to read the input device directly, not as a keyboard. Among other reasons, it's because I want to use the OK button while mplayer is running, but it generates an Enter keypress which mplayer interprets as please quit. You can use lirc to use the event device of the IR receiver and the devinput driver in lirc to define what actions you want for keypresses. There is also a tool called inputlirc, which acts like an lirc daemon but is limited to input devices that send key events, like it's the case in your setup. My problem isn't that I don't know how to make use of the events from /dev/input/..., either via (input)lirc or directly reading the device. The problem is that as well as those events, which I do want, I get X keyboard events as well, which I don't want. One solution would be to not use the devinput events after all and reconfigure my application to recognise the keycodes from the X events, but this means more hassle to prevent problems like the one with mplayer I detailed above. ISTR you can put something in xorg.conf to make it grab devices so other applications can't use them, but I seem to need it to be the other way round. Maybe you can also change the key events using the input-utils package. That could be useful. It might cure the shutdown problem as well as the mplayer one. -- TH * http://www.realh.co.uk ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: I don't want my IR handset to act like a keyboard
On Mon, 11 Jan 2010 16:07:32 -0800
Dan Nicholson dbn.li...@gmail.com wrote:
On Sun, Jan 10, 2010 at 10:04 AM, Tony Houghton h...@realh.co.uk wrote:
[Trying to stop xorg from seeing my IR controller as a keyboard]
Xorg is now picking up devices straight from udev and then configuring
them in xorg.conf{,.d} with InputClass sections. See:
http://who-t.blogspot.com/2010/01/new-configuration-world-order.html
One of the things I'm working on and want to get landed before 1.8 is
the ability to ignore devices. Something like:
Section InputClass
Identifier Ignore IR
MatchProduct Some IR Handset
Ignore yes
EndSection
Then Xorg would just skip that device. Would that help?
Yes, that would be excellent.
In the meantime I think the best solution is to use inputlirc with its
-g (grab) option, which starts before X, and support lirc in my
application, boxstar. It felt kind of incomplete without lirc anyway.
--
TH * http://www.realh.co.uk
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
I don't want my IR handset to act like a keyboard
I've got a DVB card with an IR controller which appears as an input device. I want my applications to read the input device directly, not as a keyboard. Among other reasons, it's because I want to use the OK button while mplayer is running, but it generates an Enter keypress which mplayer interprets as please quit. After trying various things with xorg.conf which always seemed to have unwanted side effects, I solved the problem by creating /etc/hal/fdi/policy/20-ir-input.fdi containing: ?xml version=1.0 encoding=ISO-8859-1? !-- -*- SGML -*- -- deviceinfo version=0.2 device !-- Stop remote control behaving like a keyboard -- match key=input.product contains=saa7146 remove key=input.x11_driver / remove key=input.xkb.rules / remove key=input.xkb.model / remove key=input.xkb.layout / remove key=input.xkb.variant / remove key=info.capabilities type=strlistinput.keys/remove remove key=info.capabilities type=strlistbutton/remove /match /device /deviceinfo but it isn't doing the trick for X any more. I'm now using xserver-xorg 1:7.5+1 from Debian unstable. I wondered if xorg is no longer using HAL because it's deprecated, but what should I do instead? BTW I was also hoping to stop the IR's power button from shutting the system down, but I had to resort to disabling /etc/acpi/powerbtn-acpi-support.sh instead, which also prevents the button on the case from working. -- TH * http://www.realh.co.uk ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Input device problem
On Mon, 15 Dec 2008 13:26:57 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: On Sun, Dec 14, 2008 at 10:25:29PM +, Tony Houghton wrote: On Sat, Dec 13, 2008 at 07:51:50PM +, Tony Houghton wrote: I've got a DVB card (saa7146 chip) with a remote control which appears as a Linux input device. The trouble is certain keys which correspond to keys on an ordinary keyboard also appear on /dev/console when pressed, which I don't want. try upgrading to xserver 1.5.2. This is happening even on the console though, not just in X. well, if it pretends to be a keyboard then it's only natural that the keys end up on the console. The only way to get around that is to grab the event device (google for EVIOCGRAB). I thought I could prevent it by configuriong HAL to remove the properties that say it's a keyboard though, but I failed. The trouble is X would probably crash or whatever it's doing before I got to see the result of evtest, although I suppose I could run it in a console or over ssh with DISPLAY set. evtest is a console program. Oh, it logs console events, not X events? -- TH * http://www.realh.co.uk ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Input device problem
On Mon, 15 Dec 2008 08:01:07 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: On Sat, Dec 13, 2008 at 07:51:50PM +, Tony Houghton wrote: I've got a DVB card (saa7146 chip) with a remote control which appears as a Linux input device. The trouble is certain keys which correspond to keys on an ordinary keyboard also appear on /dev/console when pressed, which I don't want. try upgrading to xserver 1.5.2. This is happening even on the console though, not just in X. I forgot to mention I'm using Debian (unstable), so unless it has xserver 1.5.2 in experimental upgrading could take a lot of work. It's currently based on 1.4.2. (2:1.4.2-9) with xorg in general being R7.3 (1:7.3+18). I thought I could stop this being a problem in X by changing my keyboard's InputDevice section to use the evdev driver with Option Device /dev/input/event0 instead of the keyboard driver. It seemed to do the trick at first, but I soon discovered that with this setup pressing the 4 key on my remote would abruptly terminate my X session, as if I'd pressed Alt-Ctrl-Backspace, and there would be no explanation in /var/log/Xorg.0.log. Anywhere else I can look for clues? please run evtest against the device and check what key is actually emitted when you press 4. That and the output of xkbcomp -xkb :0 - should give us a hint. The trouble is X would probably crash or whatever it's doing before I got to see the result of evtest, although I suppose I could run it in a console or over ssh with DISPLAY set. Anyway, the problem's gone away. I tried making some HAL rules to remove the device's input.key* properties to see if that would stop /dev/console responding to it. It didn't, but I thought I might as well try X's evdev driver again and now I can safely press 4. If it isn't broken any more I guess I should stop trying to fix it even if I'm not sure what cured it. Thanks for your help anyway. -- TH * http://www.realh.co.uk ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
