- input-allow-root-to-inject-unknown-scan-codes.patch removed from -mm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The patch titled

     input: allow root to inject unknown scan codes

has been removed from the -mm tree.  Its filename is

     input-allow-root-to-inject-unknown-scan-codes.patch

This patch was dropped because it was nacked by the maintainer

------------------------------------------------------
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
@@ -73,7 +73,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

input-allow-root-to-inject-unknown-scan-codes.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

[Index of Archives]     [Kernel Newbies FAQ]     [Kernel Archive]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux