Re: [RFC PATCH] input: Add disable sysfs entry for every input device

From: Ivaylo Dimitrov
Date: Wed Jan 04 2017 - 02:50:45 EST



On 3.01.2017 13:21, Bastien Nocera wrote:
On Mon, 2017-01-02 at 18:09 +0100, Pali RohÃr wrote:
On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
On Sun, 2016-12-25 at 11:04 +0100, Pali RohÃr wrote:
This patch allows user to disable events from any input device so
events
would not be delivered to userspace.

Currently there is no way to disable particular input device by
kernel.
User for different reasons would need it for integrated PS/2
keyboard or
touchpad in notebook or touchscreen on mobile device to prevent
sending
events. E.g. mobile phone in pocket or broken integrated PS/2
keyboard.

This is just a RFC patch, not tested yet. Original post about
motivation
about this patch is there: https://lkml.org/lkml/2014/11/29/92

Having implemented something of that ilk in user-space (we
automatically disable touch devices when the associated screen is
turned off/suspended), I think this might need more thought.

How to implement such thing in userspace? I think you cannot do that
without rewriting every one userspace application which uses input.

What happens when a device is opened and the device disabled
through
sysfs, are the users revoked?

Applications will not receive events. Same as if input device does
not
generates events.

Does this put the device in suspend in the same way that closing
the
device's last user does?

Current code not (this is just RFC prototype), but it should be
possible
to implement.

Is this not better implemented in user-space at the session level,
where it knows about which output corresponds to which input
device?

How to do that without rewriting existing applications?

Is this useful enough to disable misbehaving devices on hardware,
so
that the device is not effective on boot?

In case integrated device is absolutely unusable and generates
always
random events, it does not solve problem at boot time.

But more real case is laptop with closed LID press buttons and here
it
is useful.

There's usually a display manager in between the application and the
input device. Whether it's X.org, or a Wayland compositor. Even David's
https://github.com/dvdhrm/kmscon could help for console applications.


I think the use cases are not clearly explained, will try to:

1. Imagine you have a mobile phone, with a touchscreen, a slide keyboard, a keyboard-slide sensor, a proximity sensor and a couple of GPIOs, set-up as gpio keys. And you want to carry that phone in your pocket, without being worried that it will pick-up an incoming call by itself while in the pocket, so:

- slide keyboard is closed, you "lock" the phone before put it in your pocket - in that state, touchscreen and most of the gpio-keys should be "disabled", so no touches are registered waking-up the device without need.
- a call comes, proximity gets "enabled", but TS should stay disabled as proximity detects "the phone is in a pocket"
- you get your phone out of your pocket - proximity detects no more obstacles, so now TS has to be enabled giving you a chance to pick up the incoming call.

"disabling" of gpio-keys is clear, but how to make TS and proximity inactive when needed? Sure, touches can be simply ignored (by using xinput "Device Enabled" 0 on x11), same for proximity, but keep in mind this is a battery-operated device, so we don't want CPU wake-ups with no need.

2. The same device, "locked", but this time with slide keyboard opened:

- both keyboard and TS should be "disabled" so no touches neither key presses wake-up the system. Only the power-button (or some other, doesn't matter) should be enabled to activate the device.

There are more use-cases similar to the above as well as use-cases for laptops, but I hope you're getting the idea.

Also, the interface to "disable" an input devices should be independent to whether you use X11, wayland or your application draws directly to the framebuffer.

Ivo