[PATCH libinput 0/8] Add libinput_device_suspend() to disable devices
Hans de Goede
hdegoede at redhat.com
Mon Sep 15 00:22:51 PDT 2014
On 09/15/2014 07:39 AM, Peter Hutterer wrote:
> 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
>> 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.
Brokenness is a relative thing here, one user may consider some cheaper touchpads
broken / unusable others may not. If it really really is broken at a fundamental
level, we should actually have the kernel not expose an evdev device for it. If the
kernel does expose an evdev device for it, then I would expect it to work at least
to some extent.
>> - Partial disabling, disable touchpad when using trackpoint:
> 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.
Some users tend to witch between workflows depending on if their coding /
browsing the web / etc. For those "disable while I'm using the trackpoint"
may make sense. I agree that it would be better to just get our palm detection
code good enough though, and that that is where we should focus on.
>> - Partial disabling, disable trackpoint altogether:
> 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.:
> if the kernel gives us the event, we can make this happen automatically.
More information about the wayland-devel