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

[Bastien Nocera]

On Thu, 2014-08-21 at 16:18 +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.
> >
> > * 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.

SMART_DISABLE. As a potential consumer of the API, I find it too vague.
I wouldn't know what's smart about it, and what use cases it would
enable. See below.

As for the possible use cases for disabling the touchpad:
- The hardware's broken (yeah, that happens) or so awful that you don't
want to ever see it. I just disable it and use an external mouse.
- Partial disabling, disable touchpad when using trackpoint:
  https://bugzilla.gnome.org/show_bug.cgi?id=658980
- Partial disabling, disable trackpoint altogether:
  https://bugzilla.gnome.org/show_bug.cgi?id=617932
- Disabling touchpad when in tablet mode. For Lenovo Twists, Yoga, 
  X201T, etc.:
  https://bugzilla.gnome.org/show_bug.cgi?id=698226

I don't like the "Smart disable" as a name because the consumer of the
API might only see one device for both the trackpoint and the touchpad
in which case you want to disable one-half of it. Or the trackpoint and
touchpad are independent but the trackpoint's buttons are routed through
the touchpad, which the compositor/UI/user doesn't care about. They want
to be able to use the trackpoint and its buttons. The way the buttons
are routed internally to the machine are irrelevant.

So I'd have:
- ENABLED
- HW_DISABLED (the actual piece of hardware and everything routed
through it is disabled, possibly including auxiliary functions it
offered to other devices, eg. buttons for the Trackpoint)
- OWN_FEATURE_DISABLED, or TOUCHPAD_DISABLED/TRACKPOINT_DISABLED/etc.
Which would disable all the parts of the device that are relevant to
disabling that particular functionality. This could tell the touchpad to
only disable its own buttons, not the trackpoint's buttons, it could
tell the keyboard to disable the "keyboard" itself, but not the Windows
button on the screen bezel, etc.

(It's all IBM's fault)

Cheers