[PATCH libinput 0/8] Add libinput_device_suspend() to disable devices

[Peter Hutterer]

On Thu, Aug 21, 2014 at 10:16:49PM +0200, Jonas Ådahl wrote:
> On Thu, Aug 21, 2014 at 04:18:41PM +1000, Peter Hutterer wrote:
> > replying to myself, now that I've had a bit of a think about this all.
> > 
> > On Wed, Aug 20, 2014 at 01:18:48PM +1000, Peter Hutterer wrote:
> > > This patchset adds two new API hooks, libinput_device_suspend() and
> > > libinput_device_resume() which do what it says on the box. No special event
> > > is sent when suspending or resuming, so this is really the hook to ignore a
> > > specific device.
> > > 
> > > The main idea here is two-fold:
> > > some devices simply shouldn't send events, in which case suspending them
> > > means fewer wakeup calls. The other use-case is touchpads. GNOME and other
> > > DE's provide hooks to disable the touchpad altogether - suspending it
> > > achieves that.
> > 
> > > Now, there are some issues that we should discuss:
> > > * the touchpad use-case seems to be mainly caused by bad palm detection in
> > >   the synaptics driver. Presumably having near-perfect palm detection
> > >   would remove the need for that toggle (except on the
> > >   devices that have that magic "disable touchpad button" on the touchpad
> > >   itself). So there's an argument that we don't necessarily need this, but I
> > >   don't know yet how good palm detection can be.
> 
> There is also the case where the user presses the "disable touchpad" key
> on the keyboard which should simply result in the touchpad being
> disabled.

true, so at least the disabled state is needed then. 

> > > * the second problem: I don't think we provide enough information to
> > >   callers to identify which device we don't need. Short of name matching
> > >   there is no way currently to a touchpad before disabling it. Same goes for
> > >   identifying any other device we don't care about.
> > >   To allow that, we'd need some sort of device identification system beyond
> > >   simple capabilities.
> > 
> 
> I think we need this sooner or later. Another example is devices that
> can emit key events but are not real keyboards. For setups with only
> such key emitting devices, for example keyboard layout or key repeat
> need not to be configured.

yeah, I'm mostly delaying the implementation until we have a couple of
definitive use-cases we cover with that approach. Right now, it's all a bit
speculative, but we'll likely end up with something similar to the
capabilities: libinput_device_has_tag(LIBINPUT_DEVICE_TAG_TOUCHPAD) etc.

The trick is getting a sensible set of tags, as the litest.h feature tags
show it's quite tricky, especially if they're just added on-demand.

 
> > [...]
> > 
> > I think the suspend/resume approach is not the right one, at least not in
> > this form. A better option is to make this a config setting on the device,
> > specifically something like:
> > 
> > libinput_device_config_set_disabled_mode(device, <which>)
> > with the parameter being one of:
> > - ...ENABLED
> > - ...DISABLED
> > - ...TOUCHPAD_SMART_DISABLE
> 
> I think using the config API for disabling a device sounds reasonable,
> but I'd prefer a bit better terminology here. Set disabled mode enabled
> could sound like its either enabled the 'disabled' state, or the state
> the device is enabled. Maybe simply make it into a general "mode", i.e.
> 
> libinput_device_config_set_mode(device, <which>)
> with the options identical to those above.

reading your comment now I realised that 'mode' has been used for absolute
vs relative in X, so we probably shouldn't use that here (I've got a patch
somewhere to add that to tablet devices too). 'state' is probably too
generic and 'disabled_state' has the same problems. How about:

libinput_device_config_set_send_events(device, <which>)

> > ENABLED is what it is, DISABLED still leaves the top button enabled, routed
> > through the trackstick where applicable.
> > 
> > SMART_DISABLE solves the above use-case nicely. Identifying which device has
> > that feature becomes relatively simple (is the flag set in
> > libinput_device_config_get_disabled_modes()?) and what exactly is the
> > SMART_DISABLE is left to the implementation. The default would be to disable
> > when an external mouse is connected, otherwise leave enabled.
> 
> Is it really useful with such a mode if the meaning of it that vague?
> How will it be presented to the user, other than that its "smart" and
> depending on what was plugged in it could mean anything.
> 
> A mode like 'disable if mouse connected' could possibly be applicable to
> other devices as well, for example the little nob on some Lenovo
> laptops. Don't know if that is a feature that is ever asked for however,
> so might not be relevant.

I don't think I've ever seen that request, mostly because it's a lot harder
to accidentally trigger. From a quick survey on G+ it looks like the
accidental mouse movement/tap/scroll events are the main reason to disable
the touchpad. I suspect we can get that down with better palm detection but
that's unlikley to ever be perfect. If laptops have touchpad-disable buttons
I guess we're not the only ones to not get it right :)

I'll think about better naming. smart-disable was the catchall so we can
extend what we in the future without having to update clients. Whether
that's really necessary I don't know yet.

Cheers,
   Peter