The patch titled
input: allow root to inject unknown scan codes
has been added to the -mm tree. Its filename is
input-allow-root-to-inject-unknown-scan-codes.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
------------------------------------------------------
Subject: input: allow root to inject unknown scan codes
From: Randy Dunlap <randy.dunlap@xxxxxxxxxx>
Allow root to inject unknown scan codes for input device.
http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=250bc863956a93a8eab7991b0dc7f040eb5d25cc
The current code refuses to synthesise any keyboard events that don't appear
in the mask of supported keycodes for the associated device. We've found that
it's sometimes helpful to be able to inject "fake" keyboard events through the
keyboard device. Consider the following scenario:
1) User presses ACPI hotkey that corresponds to volume up
2) Userspace turns ACPI event into volume up key, either via uinput or
injecting into an existing /dev/input node
3) HAL fires off a dbus event based on the volume up key (removes the
need for media players to do unpleasent things with xgrabkey)
Using the existing /dev/input/whatever node, this is all straightforward.
Using uinput, we either need a daemon that provides a uinput device or a new
uinput device every time an ACPI hotkey is pressed. The former solution
requires building some sort of IPC mechanism, and the latter means that every
key will generate a line in dmesg (input: foo as /class/input/input3, and so
on) and HAL will have to notice a new event device, bind to it, launch the
keyboard listener daemon, fire off the dbus message, notice that the device
has vanished and then shut stuff down again. So injection through the
keyboard device is much simpler.
At the moment this fails if the keycode doesn't correspond to one present in
the keyboard mask - the input layer drops it on the floor instead. I'm not
sure that there's an especially good reason for that, so we removed the check
in order to make it easier to put as many input events through the input layer
as possible.
Cc: Dmitry Torokhov <dtor_core@xxxxxxxxxxxxx>
Cc: Matthew Garrett <mgarrett@xxxxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---
drivers/input/input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/input/input.c~input-allow-root-to-inject-unknown-scan-codes drivers/input/input.c
--- a/drivers/input/input.c~input-allow-root-to-inject-unknown-scan-codes
+++ a/drivers/input/input.c
@@ -75,7 +75,7 @@ void input_event(struct input_dev *dev,
case EV_KEY:
- if (code > KEY_MAX || !test_bit(code, dev->keybit) || !!test_bit(code, dev->key) == value)
+ if (code > KEY_MAX || !!test_bit(code, dev->key) == value)
return;
if (value == 2)
_
Patches currently in -mm which might be from randy.dunlap@xxxxxxxxxx are
acpi-add-ibm-r60e-laptop-to-proc-idle-blacklist.patch
disable-acpi-on-some-phoenix-bios.patch
input-allow-root-to-inject-unknown-scan-codes.patch
irda-add-some-ibm-think-pads.patch
8250_pnp-add-support-for-other-wacom-tablets.patch
ata-add-some-nvidia-chipset-ids.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
