[lkml]   [2017]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH] input: Add disable sysfs entry for every input device

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:
>>> 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, or a Wayland compositor. Even David's
> 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

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.


 \ /
  Last update: 2017-01-04 08:51    [W:0.101 / U:6.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site