Add a config interface for enabling/disabling event generation from a device

Rather than adding a config interface to disable a device merely allow a
caller to toggle the "send events" mode on the device. If off, the device
won't send events (though further events may be received depending on the
current state of the device).
Default is enabled, i.e. the device sends events.

A special mode is added to the obvious enable/disable: disable the device when
an external mouse is connected. Once set, the device will be enabled when no
mouse is present and stop sending events otherwise. This isn't hooked up to
anything yet though.

Built into the config API is the default option of "enabled". Any device
supports this, for the obvious reason. Disabling or conditionally disabling is
left to the implementation.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
evdev: add helper function evdev_need_mtdev

Prep work for upcoming patches

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
evdev: hook up a generic enable/disable interface for devices

The evdev fallback dispatch supports enabling and disabling devices. That's
fairly easy to support since we don't (yet) have extra event generation within
the fallback backend. Thus, we can simply close the fd and re-open it again
later.

Touchpads are currently excluded here, they generate extra events on tapping,
scrolling, and software buttons and need a more complex implementation.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
evdev: don't resume a removed device

A device may disappear and a new device may re-appear with the same device
node while the original device is suspended. Prevent a device resume to open
the wrong device.

In a path context, a changing syspath is the only indicator we get of the
device changing.
In a udev context, if the device was removed and libinput_dispatch() was
called, we can short-cut the syspath comparison by setting it to NULL.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
test: add test for device suspend/resume

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
evdev: drop the button count when releasing keys on remove

We previously called this function only before device removal, so failing to
update the button state didn't matter. To make this function generic for the
device suspend/resume, we need to keep track of the button/key count properly.

If we have a key down multiple times on suspend though, log a bug.
The dispatch should release the keys before we even get here (functionality
added in a subsequent patch).

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
touchpad: split handling the state into a separate function

No functional changes

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
touchpad: hook up sendevents configuration

We may be in the middle of a software button click or a tap, so make sure we
go back to the device-neutral state by unwinding.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
test: test for release events on device suspend

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
evdev: add a internal device notification mechanism

When a device is added or removed, notify all internal devices about the
device change. This allows all devices to configure themselves depending on
other devices in the system. Prime use-case here is an internal touchpad that
wants to know if an external mouse is connected.

On device added, notification goes both ways: existing devices are notified
about the new device, and the new device is notified about existing devices.
On device removed, notification only goes one way.

In both cases, the internal notification is complete before the event is sent
to the caller.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
evdev: add internal tagging system

For conditional touchpad disabling we need two pieces of knowledge: is the
device an internal touchpad and is another device an external mouse-like
device. For that use-case it's enough to tag any device that's on USB and
Bluetooth with pointer capabilities as external mouse. A more complex can be
done when needed.

The tag function is part of the dispatch interface (to save on udev code) and
called before the caller is notified about the new device, i.e. the device is
fully configured by the time it needs to be tagged, and other devices can rely
on the tags being assigned by the time they get notified about the new device.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
touchpad: implement conditional disabling

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
touchpad: move softbutton initialization to separate function

No functional changes

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
touchpad: when disabling a TOPBUTTONPAD, leave the buttons enabled

On a TOPBUTTONPAD, we can't disable the touchpad altogether - the trackstick
relies on the touchpad's top software buttons. On those devices, stretch the
top buttons down to INT_MAX on suspend and then route any button click events
through the trackstick device.

On resume, restore the original configuration.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>