Hi Pavel,
W dniu 08.06.2020 o 07:37, Dmitry Torokhov pisze:
On Sun, Jun 07, 2020 at 10:24:14PM +0200, Pavel Machek wrote:
On Fri 2020-06-05 19:33:28, Andrzej Pietrasiewicz wrote:
Userspace might want to implement a policy to temporarily disregard input
from certain devices.
Wow, you certainly cc a lot of lists.
An example use case is a convertible 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.
Due to interactions with suspend/resume, a helper has been added for drivers
to decide if the device is being used or not (PATCH 1/7) and it has been
applied to relevant drivers (PATCH 2,4,5,6/7).
But is that a right way to implement it?
We want this for cellphones, too -- touchscreen should be disabled
while the device is locked in the pocket -- but we really want the
touchscreen hardware to be powered down in that case (because it keeps
SoC busy and eats a _lot_ of electricity).
But simplistic "receive an event and then drop it if device is
inhibited" does not allow that...
I do not think you read the entirety of this patch series...
Yeah, kindly read the whole thread. Long story short: Inhibiting _is_ about
ignoring events from inhibited devices. Obviously we can do better than
just that. Indeed, the open() and close() callbacks (which are called at
uninhibiting/inhibiting) mean "start providing events" and "stop providing
events", respectively. How that translates into driver operation is highly
driver-specific and cannot be handled at the input subsystem level, but it
is the place where power savings can be realized: whenever the driver knows
that nobody wants events from it it can do whatever it considers appropriate,
including transitioning the device into low power mode, for example using
PM runtime.
Regards,
Andrzej
