[PATCH libinput 0/8] Add libinput_device_suspend() to disable devices
peter.hutterer at who-t.net
Mon Oct 6 05:59:53 PDT 2014
On Tue, Sep 30, 2014 at 11:36:30AM -0700, Bill Spitzak wrote:
> On 09/11/2014 07:34 AM, Bastien Nocera wrote:
> >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 seems like there are 3 settings and everybody agrees on what they do,
> just the names are hard to decide. I much prefer this naming:
> FORCE_ENABLED - Bypass anything that makes the device stop reporting events.
why would you want that setting? if it's disabled when it shouldn't be then
this is a bug we need to fix.
> ENABLED - What above is calling "smart" or "own feature disabled". In this
> case it means "the driver and libinput do what they think is best". This
> would include things like the trackpad disabling somewhat while the
> trackpoint is being used. Note that for many devices there is no difference
> between ENABLED and FORCE_ENABLED, in which case using the ENABLED setting
> is preferred.
that doesn't make sense. libinput does what is best anyway. the reason we
need an option like this is to handle the situations that are clearly user
preference and cannot be determined.
anyway, what's on master now is enabled, disabled and
> DISABLED - Device does not deliver any events.
> The reason for this naming is to encourage programs to use the "ENABLED"
> setting by default.
> FORCE_ENABLED is a very unusual setting, imho this is not wanted ever,
> except to bypass bad driver implementations of ENABLED. The user may want to
> adjust how ENABLED works but a binary switch is not sufficient, instead a
> device-specific api will be needed, to set things like timeouts and how the
> palm detection works and so on. I would have only the ENABLED and DISABLED
> settings but there seems to be some insistence that this forced state is
More information about the wayland-devel