* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: fix typo in keycode validation supporting large scancodes Input: aiptek - tighten up permissions on sysfs attributes Input: sysrq - pass along lone Alt + SysRq
Check the input_keymap_entry keycode size (u32) instead of the device's (void*) when validating that keycode value can be stored in the keymap. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=22722 Signed-off-by: Mattia Dongili <malattia@linux.it> Tested-by: Norbert Preining <preining@logic.at> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
The big kernel lock has been removed from all these files at some point, leaving only the #include. Remove this too as a cleanup. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Sysfs attributes affecting device behavior should not be, by default, world-writeable. If distributions want to allow console users access these attributes they need to employ udev and friends to adjust permissions as needed. Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Sometimes input handlers (as opposed to input devices) have a need to inject (or re-inject) events back into input core. For example sysrq filter may want to inject previously suppressed Alt-SysRq so that user can take a screen print. In this case we do not want to pass such events back to the same same handler that injected them to avoid loops. Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
It is not allowed to call input_free_device() after calling input_unregister_device() because input devices are refcounted and unregister will free the device if we were holding he last referenc. The preferred style in input/ is to make input_register_device() the last function in the probe which can fail. That way we don't need to call input_unregister_device(). Also do not need to call input_set_drvdata() as nothing in the driver uses the data. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Add a missing usb_free_urb() in usb_acecad_probe() error path. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Many of the IBM Terminal keyboards from the 1980s and early 1990s communicate using a protocol similar, but not identical to the AT keyboard protocol. (Models known to be like this include 6110344, 6110668, 1390876, 1386887, and possibly others.) When the connector is rewired or adapter to an AT-DIN or PS/2 connector, they can be connected to a standard PC, with three caveats: a) They can only use scancode set 3; requests to use anything else are quietly ignored. b) The AT Command to request Make, Break and Repeat codes is not properly interpreted. c) The top function keys on a 122 key keyboard, and the arrow/edit keys in the middle of the board send non-standard scancodes. C) is easily taken care of in userspace, by use of setkeycodes B) can be taken care of by a userspace hack (that makes the kernel complain in dmesg) A) is fixable in theory, but on the keyboard i tested on (6110668), it seems to be detected unoverridably as Set 2, causing userspace oddities that make it harder to fix C). Enclosed is a small patch to the kernel that fixes A) and B) in the kernel, making it much easier to fix C) in userspace. It adds a single kernel command line parameter that overrides the detection that sets these boards as set 2, and instead of sending the Make-break-repeat command to the keyboard, it sends the make-break command, which is properly recognized by these keyboards. Software level key repeating seems to make up for the lack of hardware repeat codes perfectly. Without manually setting the command line parameter (tentatively named atkbd.terminal), this code has no effect, and the driver works exactly as before. See also: http://www.seasip.info/VintagePC/ibm_1390876.html http://www.seasip.info/VintagePC/ibm_6110344.html http://geekhack.org/showwiki.php?title=Island:7306 Signed-off-by: Erika Quinn <erikas.aubade@gmail.com> Signed-off-by: Benjamin LaHaise <bcrl@kvack.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
The Sony VPCZ1 doesn't support active multiplexing and trying to enable it causes keyboard to stop working. Since most (all?) VAIOs do not have external PS/2 ports nor they implement active multiplexing properly, and trying to enable MUX usually messes up keyboard/touchpad, let's simply disable MUX probing based on board name (VAIO). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
KGDB, much like the resume process, needs to be able to mark all keys that were pressed at the time we dropped into the debuggers as "released", since it is unlikely that the keys stay pressed for the entire duration of the debug session. Also we need to make sure that input_reset_device() and input_dev_suspend() only attempt to change state of currenlt opened devices since closed devices may not be ready to accept IO requests. Tested-by: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>