Issue description Distinct input events can incorrectly share the same timestamp, even though they were actually generated a few milliseconds (or even seconds) apart and a "SYN_REPORT" event occurred between them. See example output below. ... Event: time 1616757853.303892, -------------- SYN_REPORT ------------ Event: time 1616757853.337911, type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 2 Event: time 1616757853.337911, -------------- SYN_REPORT ------------ Event: time 1616757853.372886, type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 2 Event: time 1616757853.372886, -------------- SYN_REPORT ------------ Event: time 1616757853.406914, type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 2 Event: time 1616757853.406914, -------------- SYN_REPORT ------------ Event: time 1616757853.440892, type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 2 Event: time 1616757853.440892, -------------- SYN_REPORT ------------ Event: time 1616757853.474907, type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 2 Event: time 1616757853.474907, -------------- SYN_REPORT ------------ Event: time 1616757853.508886, type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 2 Event: time 1616757853.508886, -------------- SYN_REPORT ------------ Event: time 1616757853.508886, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e4 Event: time 1616757853.508886, type 1 (EV_KEY), code 97 (KEY_RIGHTCTRL), value 0 Event: time 1616757853.508886, -------------- SYN_REPORT ------------ Reproduction steps To reproduce the above: 1. Run evtest and select a device that supports emulated repeat events. (such as a keyboard) 2. Press and hold a key for a few seconds and then release. 3. Notice that the "release" event (value 2) incorrectly shares the same timestamp as the last repeat event "value 0". Prior work * A similar issue was fixed in 6c7e54bd5fda ("Input: reset device timestamp on sync") by making sure the timestamp is reset after a "SYN_REPORT" event is generated, forcing a new timestamp to be created for following events. However, it only handled the case of events that were sent to the input_handle_event() function, and didn't cover "SYN_REPORT" events that were generated internally in the input core, such as emulated repeat events. * Another similar issue was fixed by cb5a89cdbaec ("Input: fix stale timestamp on key autorepeat events") which made sure that each repeat event got an updated timestamp. However, it didn't prevent those timestamps from becoming stale and used by following events. Proposed fix The attached patch resets the timestamp similarly to 6c7e54bd5fda ("Input: reset device timestamp on sync"), but does so in every case a "SYN_REPORT" event is generated by the input core. The idea being that the next event sequence would then be forced to get a new timestamp. Related issues * https://bugzilla.kernel.org/show_bug.cgi?id=206929 - The original bug report where this issue was reported, which was only partially fixed by cb5a89cdbaec ("Input: fix stale timestamp on key autorepeat events"). While "repeat" events had their timestamps update correctly, the "release" event did not. * https://gitlab.freedesktop.org/libinput/libinput/-/issues/571#note_855553 - An issue about errors constantly being printed by libinput about delay in handling of events. The investigation of this issue revealed the reported bug.
Created attachment 296099 [details] 0001-Input-reset-timestamp-after-SYN_REPORT-events.patch
I suspect you need to just submit the patch by e-mail according to the kernel development process. Running scripts/get_maintainer.pl 0001-Input-reset-timestamp-after-SYN_REPORT-events.patch in a kernel tree prints the maintainers and lists where the patch should be sent to.
Was this patch sent to the maintainers? If so, was it applied?