summaryrefslogtreecommitdiff
path: root/Documentation/input
diff options
context:
space:
mode:
authorPatrik Fimml <patrikf@chromium.org>2020-12-03 01:42:04 +0300
committerDmitry Torokhov <dmitry.torokhov@gmail.com>2020-12-03 09:10:35 +0300
commita181616487dbdbc953e476d1da15365f887859ed (patch)
tree221caf2e6a9d5b2ca3ee4ce0a8189a7dbb921198 /Documentation/input
parentd69f0a43c677e8afc67a222e1e7b51b9acc69cd3 (diff)
downloadlinux-a181616487dbdbc953e476d1da15365f887859ed.tar.xz
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>
Diffstat (limited to 'Documentation/input')
0 files changed, 0 insertions, 0 deletions