mbox series

[0/2] Support inhibiting input devices

Message ID 20200430161641.24503-1-andrzej.p@collabora.com
Headers show
Series Support inhibiting input devices | expand

Message

Andrzej Pietrasiewicz April 30, 2020, 4:16 p.m. UTC
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.

PATCH 1/2 adds support for inhibiting input devices, while PATCH 2/2
provides an example how to convert a driver to take advantage of this
new feature.

There are 

$ git grep "input_allocate_device(" | grep -v ^Documentation | cut -f1 -d: \
							| sort | uniq | wc
    388     388   13425

many input device drivers, so it is impossible to convert all of them
in one go.

This work is inspired by:

https://chromium.googlesource.com/chromiumos/third_party/kernel/+/45c2d7bb398f74adfae0017e20b224152fde3822

and

https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4ce0e8a3697edb8fd071110b3af65014512061c7

Dmitry Torokhov (1):
  Input: elan_i2c: Support inhibiting

Patrik Fimml (1):
  Input: Add "inhibited" property

 drivers/input/input.c               | 134 ++++++++++++++++++++++++++--
 drivers/input/mouse/elan_i2c_core.c | 108 +++++++++++++++++-----
 include/linux/input.h               |   8 ++
 3 files changed, 218 insertions(+), 32 deletions(-)


base-commit: 79799562bf087b30d9dd0fddf5bed2d3b038be08

Comments

Dmitry Torokhov Dec. 3, 2020, 6:29 a.m. UTC | #1
Hi Andrzej,

On Thu, Apr 30, 2020 at 06:16:41PM +0200, Andrzej Pietrasiewicz wrote:
> From: Dmitry Torokhov <dtor@chromium.org>

> 

> This also implies adjusting suspend/resume.


This was acceptable for Chrome OS, where we know that nobody is going to
poke in sysfs or update firmware at random times, but for upstream we
need to make sure that device is powered up when we try accessing it not
only via open, but through sysfs as well (upload firmware, calibrate,
etc).

Thanks.

-- 
Dmitry