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

[Bill Spitzak]

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.

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.

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