Re: [PATCH 1/2] input: evdev: Always terminate SYN_DROPPED with SYN_REPORT

[Dmitry Torokhov]

Hi Kornel,

On Thu, Oct 22, 2026 at 01:39:12PM +0000, Kornel Dulęba wrote:
> Per Documentation/input/event-codes.rst, on SYN_DROPPED:
> "Client should ignore all events up to and including next SYN_REPORT
> event and query the device (using EVIOCG* ioctls) to obtain its
> current state."
> 
> Currently, __evdev_queue_syn_dropped() queues a standalone SYN_DROPPED
> event without a terminating SYN_REPORT. This causes two issues:
> 
> 1. The queued SYN_DROPPED event remains unreadable until the next
>    hardware event frame arrives and finishes with SYN_REPORT.
> 2. When the next hardware event frame arrives, SYN_DROPPED is prepended
>    to it in the same packet. Compliant userspace clients then discard
>    the entire hardware event frame up to its SYN_REPORT.
> 
> This was discovered on an Android system with a gpio-keys backed device:
> 1. gpio_keys_open() reports the initial state on open().
> 2. Android follows open() with EVIOCSCLOCKID.
> 3. This creates an unterminated SYN_DROPPED, causing the subsequent
>    event to be discarded by userspace.
> 
> Fix this by appending SYN_REPORT after SYN_DROPPED in
> __evdev_queue_syn_dropped() and updating client->packet_head
> accordingly.

I do not think that injecting synthetic SYN_REPORT is a good idea: we do
not know at what point the clock change will arrive, it may arrive in a
middle of transmitting a packet, and if we discard only half of such
packet it will result in incomplete state being presented as complete
one.

Compliant userspace should not only discard events until the next
SYN_REPORT, but also query state via EVIOCG* to reconstruct full
picture. Is it not happening?

Thanks.

-- 
Dmitry