2019-06-04 10:11:33 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-13 10:46:48 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-13 10:46:48 +01:00
|
|
|
|
2010-07-15 23:10:10 -07:00
|
|
|
|
|
|
|
|
|
2012-06-27 09:53:47 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-26 00:14:19 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2026-06-30 11:24:35 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-04-18 17:28:30 -07:00
|
|
|
|
|
|
|
|
|
2012-09-15 15:23:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-24 22:26:31 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-18 20:51:13 +01:00
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-10 12:05:24 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-09 21:54:22 -07:00
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
2009-12-01 21:54:35 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
|
|
|
|
|
2017-04-18 17:28:30 -07:00
|
|
|
|
|
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-15 15:15:58 +02:00
|
|
|
|
2010-11-29 23:33:04 -08:00
|
|
|
|
2010-08-02 20:18:21 -07:00
|
|
|
|
|
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Input: Add "inhibited" property
Userspace might want to implement a policy to temporarily disregard input
from certain devices, including not treating them as wakeup sources.
An example use case is a laptop, whose keyboard can be folded under the
screen to create tablet-like experience. The user then must hold the laptop
in such a way that it is difficult to avoid pressing the keyboard keys. It
is therefore desirable to temporarily disregard input from the keyboard,
until it is folded back. This obviously is a policy which should be kept
out of the kernel, but the kernel must provide suitable means to implement
such a policy.
This patch adds a sysfs interface for exactly this purpose.
To implement the said interface it adds an "inhibited" property to struct
input_dev, and effectively creates four states a device can be in: closed
uninhibited, closed inhibited, open uninhibited, open inhibited. It also
defers calling driver's ->open() and ->close() to until they are actually
needed, e.g. it makes no sense to prepare the underlying device for
generating events (->open()) if the device is inhibited.
uninhibit
closed <------------ closed
uninhibited ------------> inhibited
| ^ inhibit | ^
1st | | 1st | |
open | | open | |
| | | |
| | last | | last
| | close | | close
v | uninhibit v |
open <------------ open
uninhibited ------------> inhibited
The top inhibit/uninhibit transition happens when users == 0.
The bottom inhibit/uninhibit transition happens when users > 0.
The left open/close transition happens when !inhibited.
The right open/close transition happens when inhibited.
Due to all transitions being serialized with dev->mutex, it is impossible
to have "diagonal" transitions between closed uninhibited and open
inhibited or between open uninhibited and closed inhibited.
No new callbacks are added to drivers, because their open() and close()
serve exactly the purpose to tell the driver to start/stop providing
events to the input core. Consequently, open() and close() - if provided
- are called in both inhibit and uninhibit paths.
Signed-off-by: Patrik Fimml <patrikf@chromium.org>
Co-developed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Link: https://lore.kernel.org/r/20200608112211.12125-8-andrzej.p@collabora.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2020-12-02 14:42:04 -08:00
|
|
|
|
|
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
Input: Add "inhibited" property
Userspace might want to implement a policy to temporarily disregard input
from certain devices, including not treating them as wakeup sources.
An example use case is a laptop, whose keyboard can be folded under the
screen to create tablet-like experience. The user then must hold the laptop
in such a way that it is difficult to avoid pressing the keyboard keys. It
is therefore desirable to temporarily disregard input from the keyboard,
until it is folded back. This obviously is a policy which should be kept
out of the kernel, but the kernel must provide suitable means to implement
such a policy.
This patch adds a sysfs interface for exactly this purpose.
To implement the said interface it adds an "inhibited" property to struct
input_dev, and effectively creates four states a device can be in: closed
uninhibited, closed inhibited, open uninhibited, open inhibited. It also
defers calling driver's ->open() and ->close() to until they are actually
needed, e.g. it makes no sense to prepare the underlying device for
generating events (->open()) if the device is inhibited.
uninhibit
closed <------------ closed
uninhibited ------------> inhibited
| ^ inhibit | ^
1st | | 1st | |
open | | open | |
| | | |
| | last | | last
| | close | | close
v | uninhibit v |
open <------------ open
uninhibited ------------> inhibited
The top inhibit/uninhibit transition happens when users == 0.
The bottom inhibit/uninhibit transition happens when users > 0.
The left open/close transition happens when !inhibited.
The right open/close transition happens when inhibited.
Due to all transitions being serialized with dev->mutex, it is impossible
to have "diagonal" transitions between closed uninhibited and open
inhibited or between open uninhibited and closed inhibited.
No new callbacks are added to drivers, because their open() and close()
serve exactly the purpose to tell the driver to start/stop providing
events to the input core. Consequently, open() and close() - if provided
- are called in both inhibit and uninhibit paths.
Signed-off-by: Patrik Fimml <patrikf@chromium.org>
Co-developed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Link: https://lore.kernel.org/r/20200608112211.12125-8-andrzej.p@collabora.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2020-12-02 14:42:04 -08:00
|
|
|
|
|
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-13 11:11:36 -07:00
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-03 16:48:11 -07:00
|
|
|
|
|
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-10 00:32:36 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-03 12:16:12 -07:00
|
|
|
|
|
|
|
|
|
2019-07-24 22:26:31 +03:00
|
|
|
|
Input: ensure device is ready before delivering events
When a device is opened via input_open_device(), the driver's open()
callback is invoked. Some drivers, like cm109, submit URBs or perform
other hardware initialization in their open() callbacks.
However, the input core does not prevent dev->event() from being called
concurrently during the driver's open() execution. For instance, if a
console beep occurs, the kbd handler might inject an EV_SND event. This
can lead to double list_add BUGs if the driver submits the same URB in
both open() and event() paths without adequate synchronization.
To fix this, introduce a ready flag in the input_dev structure.
For complex devices (where dev->open is defined), this flag is set to true
only after the driver's open() method successfully completes. The core now
checks ready in input_event_dispose() and input_dev_toggle()
to prevent events from reaching the hardware before it is fully prepared.
For simple devices (no open callback), events are delivered immediately.
We also replay the logical state in input_open_device() by calling
input_dev_toggle() right after marking the device ready, ensuring no
events are permanently lost.
In the inhibit path, we ensure that physical feedback (LEDs/sounds) is
turned off before the device is closed, and we synchronize the inhibited
state transition under the event lock to prevent races with incoming events.
Assisted-by: Antigravity:gemini-3.5-flash
Link: https://patch.msgid.link/20260803005210.1251102-1-dmitry.torokhov@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-08-02 17:52:01 -07:00
|
|
|
|
Input: Add "inhibited" property
Userspace might want to implement a policy to temporarily disregard input
from certain devices, including not treating them as wakeup sources.
An example use case is a laptop, whose keyboard can be folded under the
screen to create tablet-like experience. The user then must hold the laptop
in such a way that it is difficult to avoid pressing the keyboard keys. It
is therefore desirable to temporarily disregard input from the keyboard,
until it is folded back. This obviously is a policy which should be kept
out of the kernel, but the kernel must provide suitable means to implement
such a policy.
This patch adds a sysfs interface for exactly this purpose.
To implement the said interface it adds an "inhibited" property to struct
input_dev, and effectively creates four states a device can be in: closed
uninhibited, closed inhibited, open uninhibited, open inhibited. It also
defers calling driver's ->open() and ->close() to until they are actually
needed, e.g. it makes no sense to prepare the underlying device for
generating events (->open()) if the device is inhibited.
uninhibit
closed <------------ closed
uninhibited ------------> inhibited
| ^ inhibit | ^
1st | | 1st | |
open | | open | |
| | | |
| | last | | last
| | close | | close
v | uninhibit v |
open <------------ open
uninhibited ------------> inhibited
The top inhibit/uninhibit transition happens when users == 0.
The bottom inhibit/uninhibit transition happens when users > 0.
The left open/close transition happens when !inhibited.
The right open/close transition happens when inhibited.
Due to all transitions being serialized with dev->mutex, it is impossible
to have "diagonal" transitions between closed uninhibited and open
inhibited or between open uninhibited and closed inhibited.
No new callbacks are added to drivers, because their open() and close()
serve exactly the purpose to tell the driver to start/stop providing
events to the input core. Consequently, open() and close() - if provided
- are called in both inhibit and uninhibit paths.
Signed-off-by: Patrik Fimml <patrikf@chromium.org>
Co-developed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Link: https://lore.kernel.org/r/20200608112211.12125-8-andrzej.p@collabora.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2020-12-02 14:42:04 -08:00
|
|
|
|
Input: ensure device is ready before delivering events
When a device is opened via input_open_device(), the driver's open()
callback is invoked. Some drivers, like cm109, submit URBs or perform
other hardware initialization in their open() callbacks.
However, the input core does not prevent dev->event() from being called
concurrently during the driver's open() execution. For instance, if a
console beep occurs, the kbd handler might inject an EV_SND event. This
can lead to double list_add BUGs if the driver submits the same URB in
both open() and event() paths without adequate synchronization.
To fix this, introduce a ready flag in the input_dev structure.
For complex devices (where dev->open is defined), this flag is set to true
only after the driver's open() method successfully completes. The core now
checks ready in input_event_dispose() and input_dev_toggle()
to prevent events from reaching the hardware before it is fully prepared.
For simple devices (no open callback), events are delivered immediately.
We also replay the logical state in input_open_device() by calling
input_dev_toggle() right after marking the device ready, ensuring no
events are permanently lost.
In the inhibit path, we ensure that physical feedback (LEDs/sounds) is
turned off before the device is closed, and we synchronize the inhibited
state transition under the event lock to prevent races with incoming events.
Assisted-by: Antigravity:gemini-3.5-flash
Link: https://patch.msgid.link/20260803005210.1251102-1-dmitry.torokhov@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-08-02 17:52:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-06-30 00:50:38 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-12-18 20:51:13 +01:00
|
|
|
|
|
|
|
|
|
2007-10-18 23:40:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-06-10 12:05:24 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-09 21:54:22 -07:00
|
|
|
|
2010-03-08 22:37:10 -08:00
|
|
|
|
2011-01-31 21:06:39 -08:00
|
|
|
|
|
|
|
|
|
2010-03-08 22:37:10 -08:00
|
|
|
|
2011-01-31 21:06:39 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-07-19 01:40:22 -04:00
|
|
|
|
|
|
|
|
|
2017-04-18 17:28:30 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-02 20:18:21 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-09-15 15:15:58 +02:00
|
|
|
|
2010-07-15 23:10:10 -07:00
|
|
|
|
2010-08-02 20:18:21 -07:00
|
|
|
|
|
|
|
|
|
2007-10-18 23:40:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-04 15:50:28 +01:00
|
|
|
|
2005-05-29 02:29:25 -05:00
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-05-29 02:29:25 -05:00
|
|
|
|
2009-09-16 01:06:43 -07:00
|
|
|
|
2005-05-29 02:29:25 -05:00
|
|
|
|
2007-06-14 23:32:24 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-15 15:23:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-03 12:16:12 -07:00
|
|
|
|
|
|
|
|
|
2019-07-24 22:26:31 +03:00
|
|
|
|
|
|
|
|
|
Input: Add "inhibited" property
Userspace might want to implement a policy to temporarily disregard input
from certain devices, including not treating them as wakeup sources.
An example use case is a laptop, whose keyboard can be folded under the
screen to create tablet-like experience. The user then must hold the laptop
in such a way that it is difficult to avoid pressing the keyboard keys. It
is therefore desirable to temporarily disregard input from the keyboard,
until it is folded back. This obviously is a policy which should be kept
out of the kernel, but the kernel must provide suitable means to implement
such a policy.
This patch adds a sysfs interface for exactly this purpose.
To implement the said interface it adds an "inhibited" property to struct
input_dev, and effectively creates four states a device can be in: closed
uninhibited, closed inhibited, open uninhibited, open inhibited. It also
defers calling driver's ->open() and ->close() to until they are actually
needed, e.g. it makes no sense to prepare the underlying device for
generating events (->open()) if the device is inhibited.
uninhibit
closed <------------ closed
uninhibited ------------> inhibited
| ^ inhibit | ^
1st | | 1st | |
open | | open | |
| | | |
| | last | | last
| | close | | close
v | uninhibit v |
open <------------ open
uninhibited ------------> inhibited
The top inhibit/uninhibit transition happens when users == 0.
The bottom inhibit/uninhibit transition happens when users > 0.
The left open/close transition happens when !inhibited.
The right open/close transition happens when inhibited.
Due to all transitions being serialized with dev->mutex, it is impossible
to have "diagonal" transitions between closed uninhibited and open
inhibited or between open uninhibited and closed inhibited.
No new callbacks are added to drivers, because their open() and close()
serve exactly the purpose to tell the driver to start/stop providing
events to the input core. Consequently, open() and close() - if provided
- are called in both inhibit and uninhibit paths.
Signed-off-by: Patrik Fimml <patrikf@chromium.org>
Co-developed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Link: https://lore.kernel.org/r/20200608112211.12125-8-andrzej.p@collabora.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2020-12-02 14:42:04 -08:00
|
|
|
|
|
|
|
|
|
Input: ensure device is ready before delivering events
When a device is opened via input_open_device(), the driver's open()
callback is invoked. Some drivers, like cm109, submit URBs or perform
other hardware initialization in their open() callbacks.
However, the input core does not prevent dev->event() from being called
concurrently during the driver's open() execution. For instance, if a
console beep occurs, the kbd handler might inject an EV_SND event. This
can lead to double list_add BUGs if the driver submits the same URB in
both open() and event() paths without adequate synchronization.
To fix this, introduce a ready flag in the input_dev structure.
For complex devices (where dev->open is defined), this flag is set to true
only after the driver's open() method successfully completes. The core now
checks ready in input_event_dispose() and input_dev_toggle()
to prevent events from reaching the hardware before it is fully prepared.
For simple devices (no open callback), events are delivered immediately.
We also replay the logical state in input_open_device() by calling
input_dev_toggle() right after marking the device ready, ensuring no
events are permanently lost.
In the inhibit path, we ensure that physical feedback (LEDs/sounds) is
turned off before the device is closed, and we synchronize the inhibited
state transition under the event lock to prevent races with incoming events.
Assisted-by: Antigravity:gemini-3.5-flash
Link: https://patch.msgid.link/20260803005210.1251102-1-dmitry.torokhov@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-08-02 17:52:01 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-06-14 23:32:24 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-26 00:14:19 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-09 19:59:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-26 00:14:19 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-09 12:01:14 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-26 00:14:19 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-26 00:14:19 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-06 00:21:03 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-15 15:23:35 +02:00
|
|
|
|
|
|
|
|
|
2024-07-03 14:37:50 -07:00
|
|
|
|
|
|
|
|
|
2010-01-29 23:59:12 -08:00
|
|
|
|
|
|
|
|
|
2010-02-02 21:08:26 -08:00
|
|
|
|
|
|
|
|
|
2006-07-06 00:21:03 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-02 17:52:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-23 11:45:24 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-08 09:07:24 -07:00
|
|
|
|
|
|
|
|
|
2006-07-06 00:21:03 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-29 23:59:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
|
|
|
|
|
2006-07-06 00:21:03 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-03 14:37:50 -07:00
|
|
|
|
|
|
|
|
|
2010-01-29 23:59:12 -08:00
|
|
|
|
2010-02-02 21:08:26 -08:00
|
|
|
|
2007-04-12 01:29:46 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-07-06 00:21:03 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-10-23 11:45:24 -07:00
|
|
|
|
2012-10-08 09:07:24 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-09-14 01:31:59 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-09-14 01:31:59 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-27 22:31:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-14 01:31:59 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-27 22:31:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-03 12:16:12 -07:00
|
|
|
|
|
|
|
|
|
2006-06-26 01:48:36 -04:00
|
|
|
|
2005-09-15 02:01:39 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-01 00:22:53 -04:00
|
|
|
|
2005-09-15 02:01:39 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-01 00:22:53 -04:00
|
|
|
|
|
|
|
|
|
2005-09-15 02:01:39 -05:00
|
|
|
|
|
|
|
|
|
2007-04-12 01:33:51 -04:00
|
|
|
|
|
|
|
|
|
2008-04-02 00:41:00 -04:00
|
|
|
|
2007-04-12 01:33:51 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-02 00:41:00 -04:00
|
|
|
|
2007-04-12 01:33:51 -04:00
|
|
|
|
|
|
|
|
|
2007-07-18 01:20:58 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-11-03 11:02:31 -07:00
|
|
|
|
|
|
|
|
|
2017-04-18 17:28:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-02 10:20:19 -07:00
|
|
|
|
2017-04-18 17:28:30 -07:00
|
|
|
|
2007-07-18 01:20:58 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-10-08 09:07:24 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-01 21:54:35 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-12 01:29:46 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-03 11:02:31 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-07-24 22:26:31 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-07-06 00:22:43 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-06 15:19:06 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Input: add detailed multi-touch finger data report protocol
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 <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
2009-04-28 07:47:33 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-25 00:53:18 -04:00
|
|
|
|
|
|
|
|
|
2010-06-10 12:05:24 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-02 20:18:21 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-28 22:58:28 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-08-02 19:33:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-02 20:18:21 -07:00
|
|
|
|
2010-08-02 19:33:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-02 20:18:21 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-02 19:33:51 -07:00
|
|
|
|
|
|
|
|
|
2010-08-02 20:18:21 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-02 19:33:51 -07:00
|
|
|
|
|
|
|
|
|
2010-08-02 20:18:21 -07:00
|
|
|
|
2010-08-02 19:33:51 -07:00
|
|
|
|
2010-09-09 21:54:22 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-23 13:25:55 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-09 21:54:22 -07:00
|
|
|
|
2010-03-08 22:37:10 -08:00
|
|
|
|
2010-09-09 21:54:22 -07:00
|
|
|
|
2007-11-04 00:41:12 -04:00
|
|
|
|
2017-10-09 11:09:33 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-13 23:13:55 -07:00
|
|
|
|
|
|
|
|
|
2020-10-04 21:15:46 -07:00
|
|
|
|
|
|
|
|
|
2024-03-09 21:10:08 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-07-19 01:40:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-06-06 15:04:20 -07:00
|
|
|
|
|
|
|
|
|
2006-07-19 01:40:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-30 00:22:11 -04:00
|
|
|
|
2006-07-19 01:40:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-06 21:39:07 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-19 01:40:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-06-06 15:04:20 -07:00
|
|
|
|
2006-07-19 01:40:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-18 23:40:32 -07:00
|
|
|
|
2006-07-19 01:40:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-13 20:04:12 -07:00
|
|
|
|
2006-07-19 01:40:22 -04:00
|
|
|
|
|
|
|
|
|
2011-10-12 21:05:53 -07:00
|
|
|
|
2006-07-19 01:40:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-01 17:13:43 -07:00
|
|
|
|
2006-07-19 01:40:22 -04:00
|
|
|
|
2006-07-19 01:40:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
