Skip to content

L
linux
Switch branch/tag
  1. 11 Jan, 2021 4 commits
  3. 18 Dec, 2020 2 commits
  5. 16 Dec, 2020 2 commits
  7. 14 Dec, 2020 2 commits
  9. 12 Dec, 2020 4 commits
  11. 11 Dec, 2020 16 commits
  13. 10 Dec, 2020 7 commits
  15. 04 Dec, 2020 1 commit
  17. 03 Dec, 2020 2 commits
    • Andrzej Pietrasiewicz's avatar
      Input: document inhibiting · 6d59224f
      Andrzej Pietrasiewicz authored 
      Document inhibiting input devices and its relation to being
a wakeup source.
Signed-off-by: default avatarAndrzej Pietrasiewicz <andrzej.p@collabora.com>
Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
Reviewed-by: default avatarRandy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20200617101822.8558-1-andrzej.p@collabora.comSigned-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      6d59224f
    • Patrik Fimml's avatar
      Input: Add "inhibited" property · a1816164
      Patrik Fimml authored 
      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: default avatarPatrik Fimml <patrikf@chromium.org>
Co-developed-by: default avatarAndrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: default avatarAndrzej Pietrasiewicz <andrzej.p@collabora.com>
Link: https://lore.kernel.org/r/20200608112211.12125-8-andrzej.p@collabora.comSigned-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      a1816164
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7