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

On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:

On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:

quoted

On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:

quoted

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.

quoted

What happens when a device is opened and the device disabled

through

quoted

sysfs, are the users revoked?

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

quoted

Does this put the device in suspend in the same way that closing

the

quoted

device's last user does?

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

quoted

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?

quoted

Is this useful enough to disable misbehaving devices on hardware,

so

quoted

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.