user/sven/linux.git/drivers/input/evdev.c, branch v3.2.78

Input: evdev - do not report errors form flush()

2015-10-13T02:46:08Z

commit eb38f3a4f6e86f8bb10a3217ebd85ecc5d763aae upstream. We've got bug reports showing the old systemd-logind (at least system-210) aborting unexpectedly, and this turned out to be because of an invalid error code from close() call to evdev devices. close() is supposed to return only either EINTR or EBADFD, while the device returned ENODEV. logind was overreacting to it and decided to kill itself when an unexpected error code was received. What a tragedy. The bad error code comes from flush fops, and actually evdev_flush() returns ENODEV when device is disconnected or client's access to it is revoked. But in these cases the fact that flush did not actually happen is not an error, but rather normal behavior. For non-disconnected devices result of flush is also not that interesting as there is no potential of data loss and even if it fails application has no way of handling the error. Because of that we are better off always returning success from evdev_flush(). Also returning EINTR from flush()/close() is discouraged (as it is not clear how application should handle this error), so let's stop taking evdev->mutex interruptibly. Bugzilla: http://bugzilla.suse.com/show_bug.cgi?id=939834 Signed-off-by: Takashi Iwai Signed-off-by: Dmitry Torokhov [bwh: Backported to 3.2: there's no revoked flag to test] Signed-off-by: Ben Hutchings

Input: evdev - try to wake up readers only if we have full packet

2011-06-18T09:54:02Z

We should only wake waiters on the event device when we actually post an EV_SYN/SYN_REPORT to the queue. Otherwise we end up making waiting threads runnable only to go right back to sleep because the device still isn't readable. Reported-by: Jeffrey Brown Signed-off-by: Dmitry Torokhov

Input: remove useless synchronize_rcu() calls

2011-05-12T15:28:57Z

There is no need to call synchronize_rcu() after a list insertion, or a NULL->ptr assignment. However, the reverse operations do need this call. Signed-off-by: Eric Dumazet Signed-off-by: Dmitry Torokhov

Input: evdev - only signal polls on full packets

2011-04-27T05:16:38Z

This patch modifies evdev so that it only becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. On SMP systems, it is possible for an evdev client blocked on poll() to wake up and read events from the evdev ring buffer at the same rate as they are enqueued. This can result in high CPU usage, particularly for MT devices, because the client ends up reading events one at a time instead of reading complete packets. We eliminate this problem by making the device readable only when the buffer contains at least one complete packet. This causes clients to block until the entire packet is available. Signed-off-by: Jeff Brown Signed-off-by: Dmitry Torokhov

Input: evdev - indicate buffer overrun with SYN_DROPPED

2011-04-13T06:35:24Z

Add a new EV_SYN code, SYN_DROPPED, to inform the client when input events have been dropped from the evdev input buffer due to a buffer overrun. The client should use this event as a hint to reset its state or ignore all following events until the next packet begins. Signed-off-by: Jeff Brown [dtor@mail.ru: Implement Henrik's suggestion and drop old events in case of overflow.] Signed-off-by: Dmitry Torokhov

Input: evdev - fix evdev_write return value on partial writes

2011-02-27T09:52:53Z

As was recently brought up on the busybox list (http://lists.busybox.net/pipermail/busybox/2011-January/074565.html), evdev_write doesn't properly check the count argument, which will lead to a return value > count on partial writes if the remaining bytes are accessible - causing userspace confusion. Fix it by only handling each full input_event structure and return -EINVAL if less than 1 struct was written, similar to how it is done in evdev_read. Reported-by: Baruch Siach Signed-off-by: Peter Korsgaard Acked-by: Henrik Rydberg Signed-off-by: Dmitry Torokhov

Merge branch 'next' into for-linus

2011-01-07T06:34:59Z

Conflicts: include/linux/input.h

Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rydberg/input-mt into next

2010-12-28T01:33:20Z

Input: introduce device properties

2010-12-20T08:37:33Z

Today, userspace sets up an input device based on the data it emits. This is not always enough; a tablet and a touchscreen may emit exactly the same data, for instance, but the former should be set up with a pointer whereas the latter does not need to. Recently, a new type of touchpad has emerged where the buttons are under the pad, which changes logic without changing the emitted data. This patch introduces a new ioctl, EVIOCGPROP, which enables user access to a set of device properties useful during setup. The properties are given as a bitmap in the same fashion as the event types, and are also made available via sysfs, uevent and /proc/bus/input/devices. Acked-by: Ping Cheng Acked-by: Chase Douglas Acked-by: Dmitry Torokhov Signed-off-by: Henrik Rydberg

Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2

2010-12-15T07:55:21Z

The desire to keep old names for the EVIOCGKEYCODE/EVIOCSKEYCODE while extending them to support large scancodes was a mistake. While we tried to keep ABI intact (and we succeeded in doing that, programs compiled on older kernels will work on newer ones) there is still a problem with recompiling existing software with newer kernel headers. New kernel headers will supply updated ioctl numbers and kernel will expect that userspace will use struct input_keymap_entry to set and retrieve keymap data. But since the names of ioctls are still the same userspace will happily compile even if not adjusted to make use of the new structure and will start miraculously fail in the field. To avoid this issue let's revert EVIOCGKEYCODE/EVIOCSKEYCODE definitions and add EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2 so that userspace can explicitly select the style of ioctls it wants to employ. Reviewed-by: Henrik Rydberg Acked-by: Jarod Wilson Acked-by: Mauro Carvalho Chehab Signed-off-by: Dmitry Torokhov