Bug 90573

Summary: Handle timeouts before events after that timeout
Product: Wayland Reporter: Peter Hutterer <peter.hutterer>
Component: libinputAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: medium CC: peter.hutterer
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Peter Hutterer 2015-05-22 04:45:42 UTC 
If a timeout hits and events come in, it depends on whichever fd is read first on what order the events are handled. If the device is handled first, the events may be processed as if the timeout never happened.

This is particularly noticable in the test, if we call litest_timeout_..() without a subsequent litest_dispatch(), the timeout is usually ignored.

We need a mechanism to compare event timestamps to timer triggers and yield if the other one is earlier. This goes both ways, if litest_dispatch() didn't get called for a while we need to process any events with times before the timeout triggered.
Comment 1 Peter Hutterer 2015-05-26 01:43:43 UTC 
Dump of some notes:
the two functions that matter here are evdev_device_dispatch() and libinput_timer_handler().

libinput_dispatch() would need to call into all sources with a get_timestamp(), that can return the next time to process events from that source. Put that into an ordered list, then start processing the sources according to that timestamp.

For timers we only have one event to process, but devices can have more than one event waiting. So ideally pass the timestamp for the _next_ device in the list into dispatch(). That way evdev_device_dispatch() can return the current event timestamp whenever that exceeds the other device's timestamp value, and be re-ordered into the list.

This does require us to store the event though, libevdev doesn't have a peek event function, so we have to copy it into our struct, with the usual "valid" marker flags.

Quick testing shows that this doesn't seem to really be an issue in real-world usage though the tests hit this quite easily.
Comment 2 Peter Hutterer 2016-06-13 00:15:03 UTC 
closing as wontfix, this is a lot of effort just for the benefit of the tests. In real-world usage if the timeouts are hit before the event is processed something is going way too slow and we'll run into a bunch of other issues anyway.
Comment 3 golfing 2019-01-11 09:37:23 UTC 
https://golfingnation.com/

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.