[PATCH 0/2] input: evdev: Fix how SYN_DROPPED is generated
From: Kornel Dulęba
Date: Thu Oct 22 2026 - 09:44:38 EST
This series fixes two issues discovered while working with a gpio-keys
backed device on Android. In short:
1. When a gpio-keys backed device is opened, its initial state is
immediately reported.
2. Android issues EVIOCSCLOCKID right after, before reading any data.
3. evdev flushes the queue, enqueues SYN_DROPPED, and caches the current
time as the device timestamp. Notably, it does not enqueue a
SYN_REPORT.
4. When the next real event is reported by hardware, it is enqueued with
the stale cached timestamp and a prepended SYN_DROPPED.
5. The whole packet, up to the first legitimate SYN_REPORT, is then
ignored by userspace.
SYN_DROPPED needs to be issued after EVIOCSCLOCKID to ensure that any
partially read packet is dropped. At the same time, evdev only defines
the batched events() callback, not the single-event event() one. All
events in a packet up to SYN_REPORT are written to a client's queue at
once while holding client->buffer_lock. The EVIOCSCLOCKID handler takes
the same lock when flushing the queue. Therefore, EVIOCSCLOCKID cannot
inject SYN_DROPPED in the middle of a packet while it is being written
to the queue.
Based on the above, I believe that the best fix here is to emit
SYN_REPORT right after SYN_DROPPED.
Patch 1: Always follow SYN_DROPPED with a SYN_REPORT.
Patch 2: Stamp the SYN_DROPPED+SYN_REPORT events with a timestamp read
directly from the clock, bypassing the cache.
Signed-off-by: Kornel Dulęba <korneld@xxxxxxxxxx>
---
Kornel Dulęba (2):
input: evdev: Always terminate SYN_DROPPED with SYN_REPORT
input: evdev: Read clock directly in __evdev_queue_syn_dropped()
drivers/input/evdev.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
---
base-commit: 7be4bc52fd9e0e55dc9a2e0232b89427d2c4b614
change-id: 20261022-evdev_syndropped_fix-76352587616b
Best regards,
--
Kornel Dulęba <korneld@xxxxxxxxxx>