linux/drivers/input/evdev.c, branch v3.19

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input

2014-12-31T00:59:59Z

Pull input layer fixes from Dmitry Torokhov: "Fixes for v7 protocol for ALPS devices and few other driver fixes. Also users can request input events to be stamped with boot time timestamps, in addition to real and monotonic timestamps" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: hil_kbd - fix incorrect use of init_completion Input: alps - v7: document the v7 touchpad packet protocol Input: alps - v7: fix finger counting for > 2 fingers on clickpads Input: alps - v7: sometimes a single touch is reported in mt[1] Input: alps - v7: ignore new packets Input: evdev - add CLOCK_BOOTTIME support Input: psmouse - expose drift duration for IBM trackpoints Input: stmpe - bias keypad columns properly Input: stmpe - enforce device tree only mode mfd: stmpe: add pull up/down register offsets for STMPE Input: optimize events_per_packet count calculation Input: edt-ft5x06 - fixed a macro coding style issue Input: gpio_keys - replace timer and workqueue with delayed workqueue Input: gpio_keys - allow separating gpio and irq in device tree

Input: evdev - add CLOCK_BOOTTIME support

2014-12-17T23:46:59Z

This patch adds support for CLOCK_BOOTTIME for input event timestamp. CLOCK_BOOTTIME includes suspend time, so it would allow aplications to get correct time difference between two events even when system resumes from suspend state. Signed-off-by: Aniroop Mathur Signed-off-by: Dmitry Torokhov

drivers/input/evdev.c: don't kfree() a vmalloc address

2014-12-03T17:35:38Z

If kzalloc() failed and then evdev_open_device() fails, evdev_open() will pass a vmalloc'ed pointer to kfree. This might fix https://bugzilla.kernel.org/show_bug.cgi?id=88401, where there was a crash in kfree(). Reported-by: Christian Casteyde Belatedly-Acked-by: Dmitry Torokhov Cc: Henrik Rydberg Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Input: evdev - fix EVIOCG{type} ioctl

2014-10-07T16:55:01Z

The 'max' size passed into the function is measured in number of bits (KEY_MAX, LED_MAX, etc) so we need to convert it accordingly before trying to copy the data out, otherwise we will try copying too much and end up with up with a page fault. Reported-by: Pavel Machek Reviewed-by: Pavel Machek Reviewed-by: David Herrmann Signed-off-by: Dmitry Torokhov

input: evdev: Use ktime_mono_to_real()

2014-07-23T17:18:02Z

Convert the monotonic timestamp with ktime_mono_to_real() in evdev_events(). In evdev_queue_syn_dropped() we can call either ktime_get() or ktime_get_real() depending on the clkid. No point in having two calls for CLOCK_REALTIME. Signed-off-by: Thomas Gleixner Signed-off-by: John Stultz

Merge tag 'v3.15-rc5' into next

2014-05-14T23:49:19Z

Merge with Linux 3.15-rc5 to sync up Wacom and other changes.

Input: evdev - get rid of old workaround for EVIOCGBIT

2014-05-14T23:39:46Z

We put this workaround in 2008 and the offending userspace has been fixed up long time ago; the link in the message is no longer valid either, so it is time to retire it. Reviewed-by: Peter Hutterer Signed-off-by: Dmitry Torokhov

Input: don't modify the id of ioctl-provided ff effect on upload failure

2014-03-29T19:13:09Z

If a new (id == -1) ff effect was uploaded from userspace, ff-core.c::input_ff_upload() will have assigned a positive number to the new effect id. Currently, evdev.c::evdev_do_ioctl() will save this new id to userspace, regardless of whether the upload succeeded or not. On upload failure, this can be confusing because the dev->ff->effects[] array will not contain an element at the index of that new effect id. This patch fixes this by leaving the id unchanged after upload fails. Note: Unfortunately applications should still expect changed effect id for quite some time. This has been discussed on: http://www.mail-archive.com/linux-input@vger.kernel.org/msg08513.html ("ff-core effect id handling in case of a failed effect upload") Suggested-by: Dmitry Torokhov Signed-off-by: Elias Vanderstuyft Signed-off-by: Dmitry Torokhov

Input: evdev - fall back to vmalloc for client event buffer

2013-10-31T15:45:42Z

evdev always tries to allocate the event buffer for clients using kzalloc rather than vmalloc, presumably to avoid mapping overhead where possible. However, drivers like bcm5974, which claims support for reporting 16 fingers simultaneously, can have an extraordinarily large buffer. The resultant contiguous order-4 allocation attempt fails due to fragmentation, and the device is thus unusable until reboot. Try kzalloc if we can to avoid the mapping overhead, but if that fails, fall back to vzalloc. Signed-off-by: Daniel Stone Signed-off-by: Dmitry Torokhov

Input: evdev - add EVIOCREVOKE ioctl

2013-09-07T19:53:20Z

If we have multiple sessions on a system, we normally don't want background sessions to read input events. Otherwise, it could capture passwords and more entered by the user on the foreground session. This is a real world problem as the recent XMir development showed: http://mjg59.dreamwidth.org/27327.html We currently rely on sessions to release input devices when being deactivated. This relies on trust across sessions. But that's not given on usual systems. We therefore need a way to control which processes have access to input devices. With VTs the kernel simply routed them through the active /dev/ttyX. This is not possible with evdev devices, though. Moreover, we want to avoid routing input-devices through some dispatcher-daemon in userspace (which would add some latency). This patch introduces EVIOCREVOKE. If called on an evdev fd, this revokes device-access irrecoverably for that *single* open-file. Hence, once you call EVIOCREVOKE on any dup()ed fd, all fds for that open-file will be rather useless now (but still valid compared to close()!). This allows us to pass fds directly to session-processes from a trusted source. The source keeps a dup()ed fd and revokes access once the session-process is no longer active. Compared to the EVIOCMUTE proposal, we can avoid the CAP_SYS_ADMIN restriction now as there is no way to revive the fd again. Hence, a user is free to call EVIOCREVOKE themself to kill the fd. Additionally, this ioctl allows multi-layer access-control (again compared to EVIOCMUTE which was limited to one layer via CAP_SYS_ADMIN). A middle layer can simply request a new open-file from the layer above and pass it to the layer below. Now each layer can call EVIOCREVOKE on the fds to revoke access for all layers below, at the expense of one fd per layer. There's already ongoing experimental user-space work which demonstrates how it can be used: http://lists.freedesktop.org/archives/systemd-devel/2013-August/012897.html Signed-off-by: David Herrmann Signed-off-by: Dmitry Torokhov