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

[Peter Hutterer]

On Thu, Sep 11, 2014 at 04:34:48PM +0200, Bastien Nocera wrote:
> 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.

just fyi, this was changed in the most recent patchset, providing 
ENABLED/DISABLED/DISABLED_ON_EXTERNAL_MOUSE at the moment
http://lists.freedesktop.org/archives/wayland-devel/2014-September/017042.html

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

I think this would be something better solved by a udev option that libinput
reads. Broken hardware is a permanent option and doesn't need to be modified
in the session.

> - Partial disabling, disable touchpad when using trackpoint:
>   https://bugzilla.gnome.org/show_bug.cgi?id=658980

I've got some general ideas on how to improve that, I'm not sure yet whether
a separate option here is necessary. That bug wants palm detection, and if
we have a "touchpad disabled" option anyway, a separate option of "disable
while I'm using the trackpoint" shouldn't be needed.

> - Partial disabling, disable trackpoint altogether:
>   https://bugzilla.gnome.org/show_bug.cgi?id=617932

commented on that bug, not sure why this is needed. trackpoints are not
known for their erratic events.

> - Disabling touchpad when in tablet mode. For Lenovo Twists, Yoga, 
>   X201T, etc.:
>   https://bugzilla.gnome.org/show_bug.cgi?id=698226

if the kernel gives us the event, we can make this happen automatically.

Cheers,
   Peter

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