From: Karlos Abel <kabel@voidship.net>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] Input: discard pre-registration events and test state seeding
Date: Sun, 11 Oct 2026 18:30:51 -0400 [thread overview]
Message-ID: <179175785190.2.15570576039664484922.input-plain-reply@voidship.net> (raw)
In-Reply-To: <assT056aFmzMHmON@google.com>
Resending in plain text; the mailing lists rejected my previous reply
because it contained HTML.
Hi Dmitry,
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().
I targeted registration because input_event() documents pre-registration
seeding as updating initial state without delivering those events to
handlers. The patch retains that state while discarding the pending events.
The timestamp reset addresses a separate stale-timestamp case covered by
the tests.
Thanks very much,
Karlos
On Sun, Oct 11, 2026 at 12:45 AM Dmitry Torokhov <dmitry.torokhov@gmail.com>
wrote:
> Hi Karlos,
>
> On Sat, Oct 10, 2026 at 02:00:29PM -0400, Karlos Abel wrote:
> > This series prevents input handlers from receiving buffered
> initialization
> > events after device registration. On a ThinkPad T14 Gen 6, a later LED
> > update flushed a stale SW_RFKILL_ALL event seeded by thinkpad_acpi.
> > The fix drops the pending events and their timestamp before handlers
> > attach, while retaining the seeded switch and absolute-axis state.
>
> Could you explain why these seeded events give you trouble? Is it
> because thinkpad_acpi() forgets to send input_sync() and so the
> timestamp is stale/wrong?
>
> Thanks.
>
> --
> Dmitry
>
prev parent reply other threads:[~2026-10-11 22:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-10 18:00 Karlos Abel
2026-10-10 18:00 ` [PATCH 1/2] Input: discard pre-registration events before attaching handlers Karlos Abel
2026-10-10 18:00 ` [PATCH 2/2] Input: test state seeding across device registration Karlos Abel
2026-10-11 4:45 ` [PATCH 0/2] Input: discard pre-registration events and test state seeding Dmitry Torokhov
2026-10-11 22:30 ` Karlos Abel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=179175785190.2.15570576039664484922.input-plain-reply@voidship.net \
--to=kabel@voidship.net \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®