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

[Jonas Ådahl]

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.

> > 
> > * 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.

> [...]
> 
> 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.

> 
> 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.

> 
> Finally, from a semantic point of view, having this as configuration is more
> logical as we expect this to be pretty much set once and done with it.

Agreed. "suspending" and "resuming" sounds more like something related
to sessions switching than user configuration.


Jonas

> 
> Cheers,
>    Peter