doc: delete double-empty lines

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
doc: fix wording on the dpi normalization paragraph

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
README: link to bugzilla and API docs

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
evdev: Add a remove callback to the evdev_dispatch_interface

Some dispatchers may want to do some cleanup at remove time, rather then at
destroy time.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
touchpad: Use remove callback to unlink event listener and stop timers

We use 2 mechanisms to unregister the trackpoint event listener depending on
device removal order.

1) We have a device_removed callback, if the trackpoint gets removed before
the touchpad, this gets called, sees the device being removed is the trackpoint
and unregisters the listener

2) If the touchpad gets removed first, then in tp_destroy we unregister the
listener

2) May be delayed beyond the destruction of the trackpoint itself if the
libinput user has a reference to the libinput_device for the touchpad.
When this happens the trackpoint still has an eventlistener at destroy time
and an assert triggers.

To fix this we must do 2) at the same time as we do 1), so at remove time.

While working on this I noticed that the touchpad code was also cancelling
timers at destroy time rather then remove time, which means that they may
expire between remove and destroy time, and cause events to be emitted from
a removed device, so this commit moves the cancelling of the timers to the
remove callback as well.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
evdev: Ensure the libevdev object receives the new fd on resume

Otherwise, input_events will be attempted to read from the wrong place,
which also leaves the right/current fd with pending data to be read,
making the epoll fd wake up constantly.

Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
test: create a new device during the disable test to change fds

In the current test, disable followed by enable would result in the same fd
number for the new device, not exposing a bug fixed by
"evdev: Ensure the libevdev object receives the new fd on resume"

Create a keyboard device after suspending the first device, then re-enable the
device. This changes the fd to a different number, so we pick up on internal
bugs.

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