On resume from suspend there is a possibility for multi-byte scancodes
to be handled incorrectly. atkbd_reconnect disables the processing of
scancodes in software by calling atkbd_disable, but the keyboard may
still be active because no disconnect command was sent. Later, software
handling is re-enabled. If a multi-byte scancode sent from the keyboard
straddles the re-enable, only the latter byte(s) will be handled.
In practice, this leads to cases where multi-byte break codes (ex. "e0
4d" - break code for right-arrow) are misread as make codes ("4d" - make
code for numeric 6), leading to one or more unwanted, untyped characters
being interpreted.
The solution implemented here involves sending command f5 (reset
disable) to the keyboard prior to disabling software handling of codes.
Later, the command to re-enable the keyboard is sent only after we are
prepared to handle scancodes.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
I believe that "trying to access hardware" is more correct English
than "trying access hardware".
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
With commit 67d0a07544 we mark strict_strtox
as obsolete. Convert all remaining such uses in drivers/input/.
Also change long to appropriate types, and return error conditions
from kstrtox separately, as Dmitry sugguests.
Signed-off-by: JJ Ding <dgdunix@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
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 <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.htmlhttp://www.seasip.info/VintagePC/ibm_6110344.htmlhttp://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>
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 <dtor@mail.ru>
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 <dtor@mail.ru>
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 <dtor@mail.ru>
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 <ebiederm@xmission.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
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 <stern@rowland.harvard.edu>
Tested-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
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 <dtor@mail.ru>
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 <dtor@mail.ru>
OQO 01+ multimedia keys produce 6x on press, e0 6x upon release.
As a result, Linux thinks that another key has been pressed (or is
repeating), when it is actually a release of the same key. Mangle the
release scancode when running on OQO so that driver recognizes it as
such.
Since the device does not have external PS/2 ports mangling is safe
since there is no chance that an external keyboard is connected.
Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Some machines share same key list for volume up/down release key quirks,
use only one key list.
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
We need to postpone restoring LED state and typematic settings until
keyboard is finished reconnecting upon resume. Normally driver core
and PM infrastructure takes care of proper ordering and dependencies,
but or case actual reconnect is done asynchronously from kseriod.
So while driver core thinks that keyboard was resumed and it is time
to let input core run it's resume handlers in reality keyboard is not
ready yet. The solution is to keep rescheduling work that adjusts LED
and rate settings until keyboard is fully enabled.
Reported-by: Carlos R. Mafra <crmafra2@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Fix breakage caused by commit 9605fb48e1
While the input core indeed takes care of restoring led state and
typematic settings upon resume the driver still need to initialize
them properly when registering a new device
Reported-and-tested-by: Marin Mitov <mitov@issp.bas.bg>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Now that input core takes care of restoring state of input devices
upon resume we don't need to do anything special here.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Compaq Presario R4000-series laptops are not sending a "volume up button
release" and "volume down button release" signal in the PS/2 protocol for
atkbd. The URL below has some of confirmed reports:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/385477
Signed-off-by: Dave Andrews <jetdog330@hotmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
There are more and more laptop requiring use of force_release quirk
for their multimedia and other specialized keys. Adding their DMI data
to the kernel is not sustainable; instead we will rely on help from
userspace (HAL) to do that for us.
This patch creates a new 'force_release' sysfs attribute (that belongs
to serio device to which keyboard is attached) which can be used to set
up force_release keymap. For example, Dell laptop owners might do:
echo 133-139,143,147 > /sys/devices/platform/i8042/serio0/force_release
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Netbooks based on the Soltech TA12 do not send a key release
for volume keys causing Linux to think the key is constantly
being pressed forever.
Added quirk data for forced release keys.
BugLink: https://bugs.launchpad.net//bugs/397499
Signed-off-by: Jerone Young <jerone.young@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
This patch enables forced releasing of the Fn+Volume hotkeys
on the Fujitsu Siemens Amilo Pi 3525 notebook.
Signed-off-by: Simon Davie <nexx@nexxdesign.co.uk>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
The volume up and down keys on the Fujitsu Siemens Amilo PA 1510 laptop
won't generate release events, so we have to do that. Use the same
way that is already used with other models.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: elantech - touchpad driver miss-recognising logitech mice
Input: synaptics - ensure we reset the device on resume
Input: usbtouchscreen - fix eGalax HID ignoring
Input: ambakmi - fix timeout handling in amba_kmi_write()
Input: pxa930_trkball - fix write timeout handling
Input: struct device - replace bus_id with dev_name(), dev_set_name()
Input: bf54x-keys - fix debounce time validation
Input: spitzkbd - mark probe function as __devinit
Input: omap-keypad - mark probe function as __devinit
Input: corgi_ts - mark probe function as __devinit
Input: corgikbd - mark probe function as __devinit
Input: uvc - the button on the camera is KEY_CAMERA
Input: psmouse - make MOUSE_PS2_LIFEBOOK depend on X86
Input: atkbd - make forced_release_keys[] static
Input: usbtouchscreen - allow reporting calibrated data
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (24 commits)
trivial: chack -> check typo fix in main Makefile
trivial: Add a space (and a comma) to a printk in 8250 driver
trivial: Fix misspelling of "firmware" in docs for ncr53c8xx/sym53c8xx
trivial: Fix misspelling of "firmware" in powerpc Makefile
trivial: Fix misspelling of "firmware" in usb.c
trivial: Fix misspelling of "firmware" in qla1280.c
trivial: Fix misspelling of "firmware" in a100u2w.c
trivial: Fix misspelling of "firmware" in megaraid.c
trivial: Fix misspelling of "firmware" in ql4_mbx.c
trivial: Fix misspelling of "firmware" in acpi_memhotplug.c
trivial: Fix misspelling of "firmware" in ipw2100.c
trivial: Fix misspelling of "firmware" in atmel.c
trivial: Fix misspelled firmware in Kconfig
trivial: fix an -> a typos in documentation and comments
trivial: fix then -> than typos in comments and documentation
trivial: update Jesper Juhl CREDITS entry with new email
trivial: fix singal -> signal typo
trivial: Fix incorrect use of "loose" in event.c
trivial: printk: fix indentation of new_text_line declaration
trivial: rtc-stk17ta8: fix sparse warning
...
It is always "an" if there is a vowel _spoken_ (not written).
So it is:
"an hour" (spoken vowel)
but
"a uniform" (spoken 'j')
Signed-off-by: Frederik Schwarzer <schwarzerf@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Some Dells need the dell input quirk applied but have a different vendor
string in their DMI tables. Add an extra entry to cover these machines as
well.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
This patch fixes the key repeat issue with the Fn+F? keys on the new
Samsung NC10 Netbook, so that the keys can be defined and used within
ACPID correctly, otherwise the keys repeat indefinately.
This solves part of http://bugzilla.kernel.org/show_bug.cgi?id=12021
Signed-off-by: Stuart Hopkins <stuart@dodgy-geeza.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Add quirk for misbehaving volume buttons on HP Pavilion ZV6100 laptop which
are not sending keyrelease events, as reported by Aaron Pickett.
Signed-off-by: Rikard Ljungstrand <lrikard@student.chalmers.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Pointed out by Oleg Nesterov. Since delayed work is used here, use of
flush_scheduled_work() is not sufficient in atkbd_disconnect(). It does
not wait for scheduled delayed work to finish. This patch prevents
delayed work to be processed after freeing atkbd structure (used struct
delayed_work is part of atkbd) by cancelling this delayed work.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
The Zepto 6615WD laptop (rebranded Inventec Symphony system) needs a
key release quirk for its volume keys to work. The attached patch adds
the quirk to the atkbd driver.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=460237
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Dell laptops fail to send key up events for several of their special
keys. There's an existing quirk in the kernel to handle this, but it's
limited to the Latitude range. This patch extends it to cover all
portable Dells.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
strict_strtoul() allows newline character at the end of the the input
string and therefore is more user-friendly.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Video switch key on HP 2133 doesn't send release event, so we
have to create workaround similar to what we do for Dell Latitude,
i.e. perform DMI match for the system and generate 'false' release
event ourselves, so that userspace doesn't think that the key is
stuck forever.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Since some of the keycodes defined in input.h have values greater
than 255 we should use unsigned shorts in keymaps.
Tested-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Drop #include <linux/moduleparam.h> in files that also include
linux/module.h, since module.h includes moduleparam.h already.
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Most of Fn+F? special keys on (at least) the Dell Latitude laptops don't
generate a hardware key release event so the driver has to generate one.
Signed-off-by: Giel de Nijs <giel@caffeinetrip.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
