kernel.git/drivers/input/keyboard/atkbd.c, branch linux-3.2.y

Input: atkbd - make dmi callback functions return 1

2011-07-13T07:08:10Z

We only care about if there is a successful match from the table (or no match at all), so let's make dmi_check_system return immediately instead of iterating thorough the whole table. Make the dmi callback function return 1 then dmi_check_system will return immediately if we have a successful match. Signed-off-by: Axel Lin Signed-off-by: Dmitry Torokhov

Input: atkbd - add 'terminal' parameter for IBM Terminal keyboards

2010-11-04T17:30:48Z

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 Signed-off-by: Benjamin LaHaise Signed-off-by: Dmitry Torokhov

Input: atkbd - release previously reserved keycodes 248 - 254

2010-02-26T08:23:59Z

Keycodes in 248 - 254 range were reserved for special needs (scrolling) of atkbd driver. Now that the driver has been switched to use unsigned short keycodes instead of unsigned char we can release this range back into pull. We keep code 255 (ATKBD_KEY_NULL) reserved since users may have been using it to silence keys they do not care about since atkbd silently drops scancodes mapped to this keycode. Signed-off-by: Dmitry Torokhov

Merge commit 'v2.6.33-rc5' into next

2010-01-22T07:55:25Z

Input: atkbd - switch to dev_err() and friends

2010-01-07T07:54:32Z

dev_err(), dev_warn() and dev_dbg() ensure consistency in driver messages. Also switch to using bool where appropriate and fix some formatting issues. Signed-off-by: Dmitry Torokhov

Input: atkbd - fix canceling event_work in disconnect

2010-01-06T08:16:14Z

We need to first unregister input device and only then cancel event work since events can arrive (and cause event work to get scheduled again) until input_unregister_device() returns. Signed-off-by: Dmitry Torokhov

Input: serio - fix potential deadlock when unbinding drivers

2010-01-06T08:14:32Z

sysfs_remove_group() waits for sysfs attributes to be removed, therefore we do not need to worry about driver-specific attributes being accessed after driver has been detached from the device. In fact, attempts to take serio->drv_mutex in attribute methods may lead to the following deadlock: sysfs_read_file() fill_read_buffer() sysfs_get_active_two() psmouse_attr_show_helper() serio_pin_driver() serio_disconnect_driver() mutex_lock(&serio->drv_mutex); <--------> mutex_lock(&serio_drv_mutex); psmouse_disconnect() sysfs_remove_group(... psmouse_attr_group); .... sysfs_deactivate(); wait_for_completion(); Fix this by removing calls to serio_[un]pin_driver() and functions themselves and using driver-private mutexes to serialize access to attribute's set() methods that may change device state. Signed-off-by: Eric W. Biederman Signed-off-by: Dmitry Torokhov

Input: speed up suspend/shutdown for PS/2 mice and keyboards

2009-12-25T05:42:57Z

Instead of doing full-blown reset while suspending or shutting down the box use lighter form of reset that should take less time. Tested-by: Alan Stern Tested-by: Rafael J. Wysocki Signed-off-by: Dmitry Torokhov

Input: atkbd - remove identification strings from DMI table

2009-12-05T06:11:37Z

The driver does not reference identification strings in DMI table and since these strings are no longer required by DMI core we can safely remove them and save some memory. Signed-off-by: Dmitry Torokhov

Input: atkbd - restore LED state at reconnect

2009-11-13T07:21:04Z

Even though input core tells us to restore LED state and repeat rate at resume keyboard may be reconnected either by request from userspace (via sysfs) or just by pulling it from the box and plugging it back in. In these cases we still need to restore state ourselves. Signed-off-by: Dmitry Torokhov