From: "Guillermo Rodríguez" <guille.rodriguez@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: "Guillermo Rodríguez" <guille.rodriguez@gmail.com>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
linux-input@vger.kernel.org
Subject: [PATCH 0/1] Input: evdev - fix wrong timestamp after SYN_DROPPED
Date: Mon, 2 Dec 2024 13:33:50 +0100 [thread overview]
Message-ID: <20241202123351.86957-1-guille.rodriguez@gmail.com> (raw)
Hi all,
We are seeing an issue with gpio_keys where the first event after
a SYN_DROPPED has the same timestamp as the SYN_DROPPED event itself.
After some investigation it looks like this is an issue with evdev
and not specific to gpio_keys.
The issue was originally introduced in commit 3b51c44 ("Input: allow
drivers specify timestamp for input events").
This commit introduced input_set_timestamp and input_get_timestamp.
The latter (despite the name) actually generates and stores a timestamp
in dev->timestamp if the driver did not set one itself. This timestamp
needs to be reset when events are flushed; otherwise the next event
will use a stale timestamp. A partial fix was implemented in 4370b23
("Input: reset device timestamp on sync"), but this does not cover the
case of SYN_DROPPED.
If a SYN_DROPPED is generated (currently only done by evdev), the
following happens:
- evdev calls input_get_timestamp to generate a timestamp for the
SYN_DROPPED event.
- input_get_timestamp generates a timestamp and stores it in
dev->timestamp
- When the next real event is reported (in evdev_events), evdev
calls input_get_timestamp, which uses the timestamp already
stored in dev->timestamp, which corresponds to the SYN_DROPPED event
How to fix:
- When a SYN_DROPPED is generated, after calling input_get_timestamp,
the timestamp stored in dev->timestamp should be reset (same as is
currently done in input_handle_event). The attached patch does that.
(Perhaps the underlying problem is that it is not expected that a
function called input_get_timestamp will have side effects. The
commit history of input.c shows that this has actually caused a
few issues since 3b51c44.)
Guillermo Rodríguez (1):
Input: evdev - fix wrong timestamp after SYN_DROPPED event
drivers/input/evdev.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
base-commit: e70140ba0d2b1a30467d4af6bcfe761327b9ec95
2.25.1
next reply other threads:[~2024-12-02 12:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-02 12:33 Guillermo Rodríguez [this message]
2024-12-02 12:42 ` [PATCH 1/1] Input: evdev - fix wrong timestamp after SYN_DROPPED event Guillermo Rodríguez
2025-02-24 16:19 ` [PATCH 0/1] Input: evdev - fix wrong timestamp after SYN_DROPPED Guillermo Rodriguez Garcia
2025-02-25 0:52 ` Dmitry Torokhov
2025-03-03 9:56 ` Guillermo Rodriguez Garcia
2025-04-12 10:01 ` Guillermo Rodriguez Garcia
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=20241202123351.86957-1-guille.rodriguez@gmail.com \
--to=guille.rodriguez@gmail.com \
--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®