Preventing the kernel from responding to input devices
Tony Houghton
devices? I've got a DVB card with a remote control and the kernel thinks
it's a keyboard, outputting key events on /dev/console, and worse, it
now shuts down if I press the Power button, which has only started
happening recently (since kernel 2.6.29 I think).
This means I can't use the power button to do anything else useful in
applications. The keyboard events are also a nuisance because I find it
best to read the input device directly to deal with debounce and repeat
instead of pretending it's a keyboard, so if I want it to respond to the
real keyboard too it gets two events for one press of certain keys. I've
worked around that by specifiying the keyboard device in xorg.conf but I
have to reconfigure it every so often when the event device numbers
change.
I've tried removing the device's keyboard-related properties in the HAL
configuration, but it didn't stop the key press problem. I haven't tried
removing the power button property so far.
--
TH * http://www.realh.co.uk
wisdomkiller & pain
> Is there a way to stop the kernel from responding to certain input
> devices? I've got a DVB card with a remote control and the kernel thinks
> it's a keyboard, outputting key events on /dev/console, and worse, it
> now shuts down if I press the Power button, which has only started
> happening recently (since kernel 2.6.29 I think).
>
The dvb card module probably has a switch to turn off the remote.
Like, as an example,
options saa7134 disable_ir=1
(to place into some modprobe.conf file, depending upon distribution).
A working acpi configuration usually does graceful shutdown after pressing
the power button, if you want to define your own actions you have to change
them in a file you probably find under /etc/acpi.
Tony Houghton
But I do want to use the remote, but I want to use the devinput events
only in applications without the kernel or something responding to them
too in unhelpful ways. I've disabled the power button in acpi but that
means I can't use the power button on the case either.
Tony Houghton
Tony Houghton <h...@realh.co.uk> wrote:
> Is there a way to stop the kernel from responding to certain input
> devices? I've got a DVB card with a remote control and the kernel thinks
> it's a keyboard, outputting key events on /dev/console, and worse, it
> now shuts down if I press the Power button, which has only started
> happening recently (since kernel 2.6.29 I think).
Looks like I need a more specialist forum for this. Can anyone recommend
one? The trouble is I'm not entirely sure whether it's to do with the
kernel or hal.
John Hasler
> Looks like I need a more specialist forum for this. Can anyone recommend
> one? The trouble is I'm not entirely sure whether it's to do with the
> kernel or hal.
So wshat happens when you shut down Hal?
--
John Hasler
jo...@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
The Natural Philosopher
Well the sorting out IIRC is at UDEV level.
I suspect a better line of approach might be to hack UDEV rules to
differentiate between them.
Star off my running udevmonitor,( or udevadm monitor in later releases),
to trace what happens when it gets plugged in.
Then have a peek at /etc/udev/rules.d (I think) to see if you can work
out what default its falling under, and either hack that, or write a new
one to deal with it in a special way.
Of course if whatever its meant to control is expecting it to look like
a keyboard..you are in shit.
The Natural Philosopher
> Tony Houghton writes:
>> Looks like I need a more specialist forum for this. Can anyone recommend
>> one? The trouble is I'm not entirely sure whether it's to do with the
>> kernel or hal.
>
Don't you get to win the chess game and proceed to Jupiter or something?
John Hasler
> Looks like I need a more specialist forum for this. Can anyone recommend
> one? The trouble is I'm not entirely sure whether it's to do with the
> kernel or hal.
I wrote:
> So what happens when you shut down Hal?
The Natural Philosopher writes:
> Don't you get to win the chess game and proceed to Jupiter or something?
Daisy, Daisy...
Hald needs an audio clip to play when it catches a TERM signal.
Tony Houghton
The Natural Philosopher <t...@invalid.invalid> wrote:
> Tony Houghton wrote:
> > On Sun, 19 Apr 2009 19:47:44 +0100
> > Tony Houghton <h...@realh.co.uk> wrote:
> >
> >> Is there a way to stop the kernel from responding to certain input
> >> devices? I've got a DVB card with a remote control and the kernel thinks
> >> it's a keyboard, outputting key events on /dev/console, and worse, it
> >> now shuts down if I press the Power button, which has only started
> >> happening recently (since kernel 2.6.29 I think).
> >
> > Looks like I need a more specialist forum for this. Can anyone recommend
> > one? The trouble is I'm not entirely sure whether it's to do with the
> > kernel or hal.
>
> Well the sorting out IIRC is at UDEV level.
>
> I suspect a better line of approach might be to hack UDEV rules to
> differentiate between them.
>
> Star off my running udevmonitor,( or udevadm monitor in later releases),
> to trace what happens when it gets plugged in.
I can't do that for a start because it's a PCI card. I don't think it
"knows" whether the IR sensor is plugged in. I've got a second card with
the same chip, but it doesn't come with a remote or even have a socket
for the sensor, but it still has en event device node.
> Then have a peek at /etc/udev/rules.d (I think) to see if you can work
> out what default its falling under, and either hack that, or write a new
> one to deal with it in a special way.
AFAICT I can't do much with udev apart from change the name and
permissions etc of the device node. It might be possible to "hide" it
from the things I don't want responding to it by renaming the device
node, but that's an ugly hack.
ISTM it should be HAL that's responsible for what sort of events it
generates, but removing the unwanted event properties in an FDI file
(see below) has no effect. Well it does stop the properties from
appearing according to hal-device, but it doesn't stop /dev/console and
acpid from responding to them.
> Of course if whatever its meant to control is expecting it to look like
> a keyboard..you are in shit.
No, the only thing I want to respond to it is boxstar which reads
/dev/input/event* directly. VDR can also work like this, and there's
also inputlirc in case I needed it to work with anything else.
Anyway, here's that FDI file:
<?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.xkb.rules" />
<remove key="input.xkb.model" />
<remove key="input.xkb.layout" />
<remove key="input.xkb.variant" />
<remove key="info.capabilities" type="strlist">input.keys</remove>
<remove key="info.capabilities" type="strlist">button</remove>
</match>
</device>
</deviceinfo>