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

On Tue, 2018-01-02 at 22:48 +0100, Pali Rohár wrote:

On Tuesday 03 January 2017 12:21:21 Bastien Nocera wrote:

quoted

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

quoted

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/9
2

 
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.

But that is not always truth. In some cases there are applications
which
opens input device directly.

Which is why I said "usually", and not "always".

quoted

Whether it's X.org, or a Wayland compositor. Even David's
 https://github.com/dvdhrm/kmscon could help for console
applications.

That kmscon needs KMS, right? So it would not work on hardware which
do
not have KMS drivers.

Except that the use cases are getting smaller and smaller. At one
point, it might become easier to carry that patch in your tree, for
your use case.

It's not useful on desktop Linux, it's not useful for Android or Chrome
OS. It seems it's only really useful for the console when there's no
way to use a display manager between the console subsystem and the
"UI".

At this point I'd ask whether whatever is consuming those buttons can't
be modified instead of the kernel. You'd even get the benefit of being
able to close devices and save some power.