mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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
>

      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®