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

[Peter Hutterer]

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

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.

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.

Cheers,
   Peter