On Mon, Sep 15, 2014 at 09:22:51AM +0200, Hans de Goede wrote: > Hi, > > 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 > > 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. > > 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.
sure, but it still results in: user decides once that HW is broken, disables it permanently. Which is the use-case we need to worry about most, if it's so broken the kernel doesn't expose an evdev device we can ignore that case within libinput anyway. Cheers, Peter > >> - 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. > > 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: > >> 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. > > Ack. > > >> - 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. > > Ack. > > Regards, > > Hans _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel