Re: [PATCH 0/2] Input: discard pre-registration events and test state seeding

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

Hi Karlos,

On Sun, Oct 11, 2026 at 06:30:51PM -0400, Karlos Abel wrote:
> The observed problem is the initial switch event being delivered later and
> undoing a subsequent Bluetooth soft-block. It does not depend on the event
> timestamp.
>
> hotkey_init() seeds SW_RFKILL_ALL=1 before registering the input device,
> without calling input_sync(). That updates the switch state, but also
> leaves the event queued across registration.
>
> In the unpatched hardware trace:
>
> At 74.486 seconds, Bluetooth is explicitly soft-blocked.
> At 80.300 seconds, Xorg injects LED updates followed by SYN_REPORT. There
> is already one event queued.
> That flush delivers the old SW_RFKILL_ALL=1 to rfkill_event(), which
> schedules a global unblock and turns Bluetooth back on.
>
> rfkill_start() already reads the initial switch state when the handler
> attaches; this later delivery produces an additional action after userspace
> has changed the soft-block state.
>
> Regarding the missing input_sync(): from reading the initialization path,
> simply adding it alongside the seed would be ignored because EV_SYN is not
> enabled on this device until input_register_device().

Thank you for the trace - that makes the whole picture clear.

If input core handles EV_SYN properly from the start without requiring it
to be set in dev->evbit, calling input_sync() while seeding initial device
state will flush dev->vals right away. Then those seeded events will not
stay stuck in the queue and handlers attached later will never see them,
so there is no need to explicitly reset the queue in
input_register_device().

I will apply a patch to input core to always accept EV_SYN events. Could
you please send a patch for thinkpad_acpi adding the missing
input_sync(tpacpi_inputdev) after reporting the initial switch states in
hotkey_init()?

Thanks.

-- 
Dmitry