The most common trigger for this is the debouncing timer which is a mere
12ms and is effectively unavoidable, virtually every caller will
trigger those messages at some point.
Let's add a grace period of 20ms below which we don't log this message
to avoid logspam. And in the process, bump the equivalent warning
message up to 20ms as well.
Related #711
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We already ratelimit the normal notification about event processing
lagging behind but in the case of timers actually expiring late, we'd
pass those messages on. So lots of clicks on a slow-reponse system
resulted in lots of messages triggered by the debounce timers.
Use the same ratelimiting as the event processing warning, 5 messages
per hour which should be a good balance between warning and not spamming
the log.
Fixes#711
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This looks like a libinput bug (well, it does say "libinput bug" on the
package) but it hasn't been that for a long time. The cause is almost always
insufficient motivation to call libinput_dispatch() by the caller, or at least
not doing it with the celerity libinput demands (and deserves, if I may say
so).
Up-, down- or side-grade it to a client bug, so the outrage can be
directed elsewhere, preferably away from me. And add a section to the
documentation, just in case someone actually reads this stuff.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Avoid processing an event with a time later than the earliest timer expiry. If
libinput_dispatch() isn't called frequently enough, we may have e.g. a tap
timeout happening but read a subsequent input event first. In that case we can
erroneously trigger or miss out on taps, see wrong palm detection, etc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If a timer_func causes the removal or addition of a different timer, our tmp
pointer from the list_for_each_safe may not be valid anymore.
This was triggered by having the debounce code trigger a middle button state
change, which caused that timer to be cancelled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Race conditions may happen where code that cancels a timer is called just
as that timer triggers. If we cancel a timer, we assume that we've put the
code into a state where the timer firing will trigger a bug.
This could be observed with the middle button code if the release event was
held back just long enough. The button release code cancelled the timer, set
the state back to idle and then complained when the timeout handling sent a
'timeout' event while being in idle.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This worked before, but triggered a negative timer bug. When one of the
physical L/R buttons is pressed with middle button emulation enabled, the
flow is:
1) phys left button down
2) middle button state machine discards events, sets timer
3) timer expires or button is released
4) middle button state machine sends button press with time from 1)
5) emulation code sees button press, sets timer for scroll emulation
6) timer logs bug because (original-button-time + timeout) is less than now()
That log_bug_libinput() warning fails the tests but works otherwise.
Allow this situation explicitly, on some devices we only have left and right
buttons and no scroll wheel, so having middle button emulation *and*
button-scroll working is useful.
https://bugs.freedesktop.org/show_bug.cgi?id=99845
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Makes it easier to determine if this is a libinput bug or something triggered
by the caller waiting too long to call libinput_dispatch().
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In order to provide higher precision event time stamps, change the
internal time measuring from milliseconds to microseconds.
Microseconds are chosen because it is the most fine grained time stamp
we can get from evdev.
The API is extended with high precision getters whenever the given
information is available.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Even if it may be caused by extreme stalls, warn if the timer was set to
be triggered even before 'now' when it actually is triggered, as it is
more likely a programming error.
Part of the reason for this commit was not to convert the unsigned int
to a signed int (which abs() does).
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
To quote Bryce Harrington from [1]:
"MIT has released software under several slightly different licenses,
including the old 'X11 License' or 'MIT License'. Some code under this
license was in fact included in X.org's Xserver in the past. However,
X.org now prefers the MIT Expat License as the standard (which,
confusingly, is also referred to as the 'MIT License'). See
http://cgit.freedesktop.org/xorg/xserver/tree/COPYING
When Wayland started, it was Kristian Høgsberg's intent to license it
compatibly with X.org. "I wanted Wayland to be usable (license-wise)
whereever X was usable." But, the text of the older X11 License was
taken for Wayland, rather than X11's current standard. This patch
corrects this by swapping in the intended text."
libinput is a fork of weston and thus inherited the original license intent
and the license boilerplate itself.
See this thread on wayland-devel here for a discussion:
http://lists.freedesktop.org/archives/wayland-devel/2015-May/022301.html
[1] http://lists.freedesktop.org/archives/wayland-devel/2015-June/022552.html
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
"read(int, void *, size_t)" returns the number of bytes read, but it
is ignored.
We don't really care about the number of bytes, but let's complain if we get
anything but EAGAIN.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Resetting a timerfd empties the data on the fd, so if the timer is reset
between triggering and us reading it, we may block trying to read it.
Since we read events off a device in a loop, a device sending a continuous
flow of events may cause the timer to trigger but delay reading it. If one of
the events cause e.g. the tap timer to be set, the timerfd may be empty at the
time of reading.
Suggested-by: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
timer.c: In function ‘libinput_timer_arm_timer_fd’:
timer.c:48: warning: missing initializer
timer.c:48: warning: (near initialization for ‘its.it_value.tv_nsec’)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than a single global logging function, make the logging dependent on
the individual context. This way we won't stomp on each other's feet in the
(admittedly unusual) case of having multiple libinput contexts.
The userdata argument to the log handler was dropped. The caller has a ref to
the libinput context now, any userdata can be attached to that context
instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Currently we are using DIY timers in the touchpad softbutton and tap handling
code, and at least the softbutton code gets its wrong. It uses one timer-fd
per touchpad to set a timeout per touch, which means that if a timeout is
set for 100ms from now for touch 1, and then 50 ms later touch 2 sets a timeout
for 200 ms from now, then the timeout for touch 1 will come 150 ms too late.
This commits adds a proper timer subsystem so that we've one place to deal
with timer handling, and so that we can only get it wrong (well hopefully
we get it right) in one place.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
