linux/drivers/input/input.c, branch v2.6.30

Input: multitouch - add tracking ID to the protocol

2009-05-23T16:53:18Z

There are a few multi-touch devices that support finger tracking well in hardware, Stantum being the prime example. By exposing the tracking ID in the MT protocol, evdev bandwidth and cpu usage in user space can be reduced. This patch adds the ABS_MT_TRACKING_ID to the MT protocol. Signed-off-by: Henrik Rydberg Tested-by: Stéphane Chatty Signed-off-by: Dmitry Torokhov

Input: add detailed multi-touch finger data report protocol

2009-04-28T16:36:24Z

In order to utilize the full power of the new multi-touch devices, a way to report detailed finger data to user space is needed. This patch adds a multi-touch (MT) protocol which allows drivers to report details for an arbitrary number of fingers. The driver sends a SYN_MT_REPORT event via the input_mt_sync() function when a complete finger has been reported. In order to stay compatible with existing applications, the data reported in a finger packet must not be recognized as single-touch events. In addition, all finger data must bypass input filtering, since subsequent events of the same type refer to different fingers. A set of ABS_MT events with the desired properties are defined. The events are divided into categories, to allow for partial implementation. The minimum set consists of ABS_MT_TOUCH_MAJOR, ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which allows for multiple fingers to be tracked. If the device supports it, the ABS_MT_WIDTH_MAJOR may be used to provide the size of the approaching finger. Anisotropy and direction may be specified with ABS_MT_TOUCH_MINOR, ABS_MT_WIDTH_MINOR and ABS_MT_ORIENTATION. Devices with more granular information may specify general shapes as blobs, i.e., as a sequence of rectangular shapes grouped together by a ABS_MT_BLOB_ID. Finally, the ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a finger or a pen. Signed-off-by: Henrik Rydberg Signed-off-by: Dmitry Torokhov

Input: allow certain EV_ABS events to bypass all filtering

2009-04-28T16:36:16Z

With the upcoming multi-touch interface as an example, there is a need to make certain that all reported events actually get passed to the event handler. This patch equips the input core with the ability to bypass all filtering for certain EV_ABS events. Signed-off-by: Henrik Rydberg Signed-off-by: Dmitry Torokhov

Merge branch 'next' into for-linus

2009-04-16T15:51:52Z

Input: remove unnecessary synchronize_rcu() call

2009-04-12T00:09:14Z

There is no need to issue serialize_rcu() after adding a new handle to the list of handles associated with the device because new events will "see" the new handle in the list immediately. Remove it so we can boot a little bit faster. Signed-off-by: Dmitry Torokhov

Merge branch 'next' into for-linus

2009-04-08T07:00:33Z

proc 2/2: remove struct proc_dir_entry::owner

2009-03-30T21:14:44Z

Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy as correctly noted at bug #12454. Someone can lookup entry with NULL ->owner, thus not pinning enything, and release it later resulting in module refcount underflow. We can keep ->owner and supply it at registration time like ->proc_fops and ->data. But this leaves ->owner as easy-manipulative field (just one C assignment) and somebody will forget to unpin previous/pin current module when switching ->owner. ->proc_fops is declared as "const" which should give some thoughts. ->read_proc/->write_proc were just fixed to not require ->owner for protection. rmmod'ed directories will be empty and return "." and ".." -- no harm. And directories with tricky enough readdir and lookup shouldn't be modular. We definitely don't want such modular code. Removing ->owner will also make PDE smaller. So, let's nuke it. Kudos to Jeff Layton for reminding about this, let's say, oversight. http://bugzilla.kernel.org/show_bug.cgi?id=12454 Signed-off-by: Alexey Dobriyan

Input: fix polling of /proc/bus/input/devices

2009-03-08T23:34:55Z

Tested-by: Alessio Sangalli Signed-off-by: Dmitry Torokhov

Input: stop autorepeat timer on key release

2009-01-30T07:43:21Z

Whenever you press and then release a key, the CPU wakes up three times: * press * release * autorepeat timer exactly 250ms after press The autorepeat timer has nothing to do, obviously, since you already have released the key, so stop it on key release. [dtor@mail.ru: This changes autorepeat behavior a bit since we now stop autorepeat even if key that is being released is not the one that is being auto-repeated, but I believe the new behavior is better.] Signed-off-by: Johannes Berg Signed-off-by: Dmitry Torokhov

Input: struct device - replace bus_id with dev_name(), dev_set_name()

2008-10-30T13:29:05Z

Acked-by: Greg Kroah-Hartman Signed-off-by: Kay Sievers Signed-off-by: Dmitry Torokhov