linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Clément VUCHENER" <clement.vuchener@gmail.com>
To: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	linux-input <linux-input@vger.kernel.org>,
	Nestor Lopez Casado <nlopezcasad@logitech.com>
Subject: Re: Fake KEY_5 continuous keydown events with Logitech wireless keyboard on Kernel 4.2
Date: Wed, 16 Dec 2015 17:17:57 +0100	[thread overview]
Message-ID: <CAM4jgCqJ0A3xpg2OGa-3Yd_APnHW9kObfO_dvS_ZO_Nb0gOdpA@mail.gmail.com> (raw)
In-Reply-To: <CAN+gG=EOH==YHscYL6V5PNBNbzH-xZ3pdBLd3S=UqzFnsCykbQ@mail.gmail.com>

2015-11-06 17:37 GMT+01:00 Benjamin Tissoires <benjamin.tissoires@gmail.com>:
> I also experienced such problems from time to time and always thought
> it was either a firmware problem or a low battery issue. When
> recharging my keyboard, the issue disappeared. Unfortunately, I was
> never able to figure out which HID raw event triggered this kernel key
> repeat (as you said, it's random).
>
> Now that I think of it, I might have a reproducer here. When playing
> with libratbag to configure the MX Master, I receive from time to time
> some key events while no keys should be sent by the mouse. I suspect
> that the HID parsing convert some internal protocol events into HID
> keys and generate spurious keys. I'll check on this.
>
> If you can manage to reproduce your issue more often (for me, this
> happens once in a month or so), I'd be curious to check the HID raw
> events coming out from the keyboard just before the bug, and what
> triggers the bug.
> I'd be glad if you could do a recording with hid-record (from
> hid-replay[1]). Make sure that the logs do not contain sensitive
> information:

Hi Benjamin,

I think I got this bug while testing writing profiles to my Logitech
G500 (with Fedora 23, kernel 4.2.6, it uses hid-generic driver not the
hidpp or dj ones) except I got only one press/release pair for each
page I wrote. I was able to reproduce that several times in a row but
there was only the expected HID++ reports and hid-replay did not
reproduce the bug.

I am not sure what caused the events exactly, it happened around the
time I write the 0xa1 register for resetting the sequence number.
Then, I tried only writing the 0xa1 register, I got a lot of KEY_5
events. I was not able to reproduce anything after that.

An extract of the output of both evtest and hid-recorder running at
the same time:
E: 0.357976 7 10 00 82 a0 00 00 00
E: 0.359965 7 10 00 80 a1 00 00 00
Event: time 1450279569.586206, type 4 (EV_MSC), code 4 (MSC_SCAN),
value ffff8802
Event: time 1450279569.586206, type 1 (EV_KEY), code 6 (KEY_5), value 1
Event: time 1450279569.586206, -------------- SYN_REPORT ------------
Event: time 1450279569.588202, E: 0.361963 7 10 00 50 01 00 00 00
type 4 (EV_MSC), code 4 (MSC_SCAN), value ffff8802
Event: time 1450279569.588202, type 1 (EV_KEY), code 6 (KEY_5), value 0
Event: time 1450279569.588202, -------------- SYN_REPORT ------------
E: 0.364983 7 10 00 50 01 01 00 00
E: 0.367920 7 10 00 50 01 02 00 00
E: 0.370938 7 10 00 50 01 03 00 00
E: 0.374948 7 10 00 50 01 04 00 00
Note that there is a HID++ answer (the acknowledgment notification
from the first packet) in the middle of an evtest line.

Debug output from my program (unlike libratbag, I write pages directly
to flash 512 bytes at once):
...
[Debug] Setting long register 0xa0
[Debug] Parameters: 02 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00
[Debug] Setting short register 0xa1
[Debug] Parameters: 01 00 00
[Debug] Sending data packet 0
[Debug] (Data packet 01 04 00 00 00 02 00 00 00 ff 00 00 80 00 11 00
[Debug] Data packet 0 acknowledged
[Debug] Sending data packet 1
[Debug] Data packet 11 22 11 00 22 00 22 22 12 00 55 00 55 22 22 00
[Debug] Data packet 1 acknowledged
...
[Debug] Setting long register 0xa0
[Debug] Parameters: 02 00 00 00 00 00 05 00 00 00 00 00 00 00 00 00
[Debug] Setting short register 0xa1
[Debug] Parameters: 01 00 00
[Debug] Sending data packet 0
[Debug] Data packet 01 05 00 00 00 02 00 00 00 22 04 20 2b 21 2b 61
([Debug] Data packet 0 acknowledged
[Debug] Sending data packet 1
[Debug] Data packet 01 90 05 0a 00 20 2b 21 2b c0 45 05 06 23 04 ff
...
The parentheses in "(Data" or "([Debug]" are KEY_5 on my french AZERTY keyboard.

I hope this can help.

  parent reply	other threads:[~2015-12-16 16:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-06 13:50 Fake KEY_5 continuous keydown events with Logitech wireless keyboard on Kernel 4.2 Mauro Carvalho Chehab
2015-11-06 16:37 ` Benjamin Tissoires
2015-11-06 18:08   ` Mauro Carvalho Chehab
2015-11-07 17:22   ` Mauro Carvalho Chehab
2015-11-09 10:36     ` Benjamin Tissoires
2015-11-09 13:16       ` Mauro Carvalho Chehab
2015-12-16 16:17   ` Clément VUCHENER [this message]
2016-02-26 10:50     ` Stefan Löwen

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=CAM4jgCqJ0A3xpg2OGa-3Yd_APnHW9kObfO_dvS_ZO_Nb0gOdpA@mail.gmail.com \
    --to=clement.vuchener@gmail.com \
    --cc=benjamin.tissoires@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=mchehab@osg.samsung.com \
    --cc=nlopezcasad@logitech.com \
    /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;
as well as URLs for NNTP newsgroup(s).