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

[Pali RohÃr]

On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> On Wed, 2017-01-04 at 09:43 +0200, Ivaylo Dimitrov wrote:
> > 
> > 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/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.
> > > > 
> > > > > 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.
> 
> I'm pretty certain that the libinput or evdev Xorg drivers would close
> the underlying deviceÂso that it can go into power save.

When they close evdev device? At least I need to explicitly call xinput.

And Xorg and libinput are not only applications/libraries which uses
linux evdev. There are more...

E.g. in case of N900 there is mce which is not doing it.

> FWIW, your example is incomplete, as you'd probably want the
> touchscreen to be usable even if the keyboard is folded in by pressing
> the power button, and using the touchscreen only.

Maybe with combination of ambient light sensor for detection if phone is
in pocket or not...

> > 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.
> 
> Which is what disabling the device in Xorg should do.

You are expecting here that only Xorg is used... which does not have to
be truth (and in more cases really is not).

> > 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.
> 
> I implemented behaviour similar to those at the session level, using D-
> Bus to gather data from the various sensors and peripherals. In
> addition, it also knows about the state of the display, which you
> wouldn't have available at another level. This also means that it works
> as expected for multi-user setups (which I understand isn't your
> concern).
> 
> I don't doubt that the use cases should be catered for, I essentially
> did that same work without kernel changes for GNOME. What I doubt is
> the fuzzy semantics, the fact that the device is kept opened but no
> data is sent (that's not power saving), that whether users are revoked
> or should be revoked isn't clear, and that the goal is basically to
> work around stupid input handling when at the console. When running a
> display manager, this is all avoided.
> 
> If this were to go through, then the semantics and behaviour needs to
> be better explained, power saving actually made possible, and make sure
> that libinput can proxy that state to the users on the console. Or an
> ioctl added to the evdev device to disable them.

-- 
Pali RohÃr
pali.rohar@xxxxxxxxx