MUX error handling has a workaround for KBCs that get confused which
port data came from and signal MUXERR while data is actually good.
Unfortunately this workaround hurts with KBCs that signal timeouts
as 0xfc (spec says that only 0xfd, 0xfe and 0xff are alowed with
MUXERR) since it causes endless attempts to rescan i8042 serio
ports. The solution is to treat 0xfc as timeout (0xfe).
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
In mousedev the BTN_LEFT and BTN_FORWARD were mapped to mouse button 0,
causing that the user space program cannot distinguish between them through
/dev/input/mice. All mice have BTN_LEFT, but not all have BTN_MIDDLE (e.g.
Clevo D410J laptop). Mapping BTN_FORWARD to mouse button 2 makes the
BTN_FORWARD button useful on this laptop.
Signed-off-by: Marton Nemeth <nm127@freemail.hu>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Mouse button emulation for the one-button mouse Apple machines isn't
restricted to older ADB based machines. There are PPC Powerbooks where
the keyboard and the mouse are no longer on the ADB bus but regular USB,
and users still like (and need) to be able to emulate the middle mouse
button with F11 and the right mouse button with F12.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Small readability improvement for appletouch: use canonical names
instead of raw USB IDs for some of the devices.
Signed-off-by: Julien BLACHE <jb@jblache.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
The new Core2 Duo MacBook Pro has a new keyboard+trackpad named
"Geyser IV".
According to the Info.plist in the OS X kext, it looks like the Geyser
IV trackpad is identical to the Geyser III trackpad: same IOClass
(AppleUSBGrIIITrackpad), same acceleration tables.
Signed-off-by: Julien BLACHE <jb@jblache.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Change a bit the finger detection method used by the appletouch
driver to reduce touchpad "jumpiness":
- Adjust the method for detecting multiple fingers. Previously, it
recognized a new finger when a low sensor reading is followed by
a high sensor reading. The new method checks for 'humps' in the
sensor readings, so there doesn't necessarily have to be a low
sensor between two high sensors for two fingers to be triggered.
This allows detecting presence of two fingers on the touchpad
even when they touch each other.
- Change absolute coordinate calculation to us to get rid of "jumps".
Instead of using full value from a sensor once it passes the
threshold subtract theshold value from the reading.
- Allow adjusting threshold value via module parameter.
The patch doesn't seem to affect the Powerbooks but does greatly improve
the touchpad behaviour on the MacBooks.
Signed-off-by: Jason Parekh <jasonparekh@gmail.com>
Signed-off-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
psmouse_show_int_attr() and psmouse_set_int_attr() were accessing
unsigned int fields as unsigned long, which gave garbage on x86_64.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Logitech USB Receiver (046d:c101) has two interfaces. The first one
contains fields from HID_UP_KEYBOARD and HID_UP_LED, and the other one
contains fields from HID_UP_CONSUMER and HID_UP_LOGIVENDOR. This device
is used with multiple wireless Logitech products, including UltraX Media
Remote.
All fields on both interfaces are either keys or leds. All fields in the
first interface are marked as Absolute, while the fields in the second
interface are marked as Relative. Marking the keys as relative causes
hidinput_hid_event() to send release events right after key press
events.
The device has EV_REP set, so the userspace expects the device to send
repeat events if a key is held down. However, as hidinput_hid_event()
sends release events immediately, repeat events are not sent at all. In
fact, the userspace has no way of knowing if a key is being held down.
Fix this by adding a quirk for 046d:c101 which changes relative keys to
absolute ones.
Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
To save a char pointer in the final assembly change to alternate string
form.
Signed-off-by: Brandon Philips <brandon@ifup.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
The previous commit (45c18b0bb5, aka "Fix
unlikely (but possible) race condition on task->user access") fixed a
potential oops due to __sigqueue_alloc() getting its "user" pointer out
of sync with switch_user(), and accessing a user pointer that had been
de-allocated on another CPU.
It still left another (much less serious) problem, where a concurrent
__sigqueue_alloc and swich_user could cause sigqueue_alloc to do signal
pending reference counting for a _different_ user than the one it then
actually ended up using. No oops, but we'd end up with the wrong signal
accounting.
Another case of Oleg's eagle-eyes picking up the problem.
This is trivially fixed by just making sure we load whichever "user"
structure we decide to use (it doesn't matter _which_ one we pick, we
just need to pick one) just once.
Acked-by: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
There's a possible race condition when doing a "switch_uid()" from one
user to another, which could race with another thread doing a signal
allocation and looking at the old thread ->user pointer as it is freed.
This explains an oops reported by Lukasz Trabinski:
http://permalink.gmane.org/gmane.linux.kernel/462241
We fix this by delaying the (reference-counted) freeing of the user
structure until the thread signal handler lock has been released, so
that we know that the signal allocation has either seen the new value or
has properly incremented the reference count of the old one.
Race identified by Oleg Nesterov.
Cc: Lukasz Trabinski <lukasz@wsisiz.edu.pl>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Commit 5a06a363ef ("[PATCH] ipc/msg.c:
clean up coding style") breaks fakeroot on Alpha (variously hangs or
oopses), according to a report by Falk Hueffner.
The fact that the code seems to rely on compiler access ordering through
the use of "volatile" is a pretty certain sign that the code has locking
problems, and we should fix those properly and then remove the whole
"volatile" entirely.
But in the meantime, the movement of "volatile" was unintentional, and
should be reverted.
Cc: Falk Hueffner <falk@debian.org>
Cc: Andrew Morton <akpm@osdl.org>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
After the inode slimming patch that unionised i_pipe/i_bdev/i_cdev, it's
no longer enough to check for existance of ->i_pipe to verify that this
is a pipe.
Original patch from Eric Dumazet <dada1@cosmosbay.com>
Final solution suggested by Linus.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6:
USB: use MII hooks only if CONFIG_MII is enabled
USB Storage: unusual_devs.h entry for Sony Ericsson P990i
USB: xpad: additional USB id's added
USB: fix compiler issues with newer gcc versions
USB: HID: add blacklist AIRcable USB, little beautification
USB: usblp: fix system suspend for some systems
USB: failure in usblp's error path
usbtouchscreen: use endpoint address from endpoint descriptor
USB: sierra: Fix id for Sierra Wireless MC8755 in new table
USB: new VID/PID-combos for cp2101
hid-core: big-endian fix fix
USB: usb-storage: Unusual_dev update
USB: add another sierra wireless device id
The user.* extended attributes are only allowed on regular files and
directories. Sticky directories further restrict write access to the owner
and privileged users. (See the attr(5) man page for an explanation.)
The original check in ext2/ext3 when user.* xattrs were merged was more
restrictive than intended, and when the xattr permission checks were moved
into the VFS, read access to user.* attributes on sticky directores ended
up being denied in addition.
Originally-from: Gerard Neil <xyzzy@devferret.org>
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Cc: Dave Kleikamp <shaggy@austin.ibm.com>
Cc: Jan Engelhardt <jengelh@linux01.gwdg.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
sys_move_pages() uses vmalloc() to allocate an array of structures that is
fills with information passed from user mode and then passes to
do_stat_pages() (in the case the node list is NULL). do_stat_pages()
depends on a marker in the node field of the structure to decide how large
the array is and this marker is correctly inserted into the last element of
the array. However, vmalloc() doesn't zero the memory it allocates and if
the user passes NULL for the node list, then the node fields are not filled
in (except for the end marker). If the memory the vmalloc() returned
happend to have a word with the marker value in it in just the right place,
do_pages_stat will fail to fill the status field of part of the array and
we will return (random) kernel data to user mode.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Christoph Lameter <clameter@engr.sgi.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>