linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
To: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Cc: 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: Sat, 7 Nov 2015 15:22:37 -0200	[thread overview]
Message-ID: <20151107152237.12018d2f@recife.lan> (raw)
In-Reply-To: <CAN+gG=EOH==YHscYL6V5PNBNbzH-xZ3pdBLd3S=UqzFnsCykbQ@mail.gmail.com>

Em Fri, 06 Nov 2015 17:37:55 +0100
Benjamin Tissoires <benjamin.tissoires@gmail.com> escreveu:

> HI Mauro,
> 
> On Fri, Nov 6, 2015 at 2:50 PM, Mauro Carvalho Chehab
> <mchehab@osg.samsung.com> wrote:
> > Hi Dmitry,
> >
> > Since I upgraded my desktop to Fedora 23 (with comes with Kernel 4.2.5), I'm
> > noticing a weird bug... from time to time, it starts producing an endless
> > sequence of KEY_5 events.
> >
> > I opened a bug at Fedora:
> >         https://bugzilla.redhat.com/show_bug.cgi?id=1278818
> >
> > But I suspect it could be some Kernel bug. Do you know if some change
> > between 4.1 and 4.2 might have triggered such bug?
> 
> I don't think any changes in 4.2 would trigger that. The only
> hid-logitech-hidpp change in 4.2 is unrelated to this particular
> keyboard and I don't think it could interfere with other devices than
> the M560.
> 
> 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:
> You can parse the output of the raw events by using
> ./tools/parse_hid.py in the hid-replay repository. Recording at the
> Unifying receiver level should give a bunch of HID reports
> encapsulated in the DJ protocol so parse_hid will not be able to parse
> them accurately. If you register the keyboard node, parse_hid.py
> should accurately translate the raw events to a human description of
> the report which should allow you to strip the sensitive data.

Parsed hid for the keyboard for 
	/dev/hidraw2:	Logitech K520
follows:

 68.090688 ReportID: 1 / LeftControl: 0 | LeftShift: 0 | LeftAlt: 0 | Left GUI: 0 | RightControl: 0 | RightShift: 0 | RightAlt: 0 | Right GUI: 0 |Keyboard [Return (ENTER), 00, 00, 00, 00, 00] 
 68.170687 ReportID: 1 / LeftControl: 0 | LeftShift: 0 | LeftAlt: 0 | Left GUI: 0 | RightControl: 0 | RightShift: 0 | RightAlt: 0 | Right GUI: 0 |Keyboard [00, 00, 00, 00, 00, 00] 
177.191904 ReportID: 16 /Vendor Defined Page 1 [02, 81, 07, 07, 00, 00] 
297.115254 ReportID: 16 /Vendor Defined Page 1 [02, 81, 07, 07, 00, 00] 
367.914151 ReportID: 16 /Vendor Defined Page 1 [02, 41, 04, 71, 11, 20] 
367.916051 ReportID: 1 / LeftControl: 0 | LeftShift: 0 | LeftAlt: 0 | Left GUI: 0 | RightControl: 0 | RightShift: 0 | RightAlt: 0 | Right GUI: 0 |Keyboard [00, 00, 00, 00, 00, 00] 
367.916062 ReportID: 3 /Consumer Devices [, ] 
367.916067 ReportID: 4 /Generic Desktop [] | # 
416.840646 ReportID: 16 /Vendor Defined Page 1 [02, 8f, 81, 07, 09, 00] 
476.573316 ReportID: 16 /Vendor Defined Page 1 [02, 41, 04, b1, 11, 20] 
476.577354 ReportID: 1 / LeftControl: 0 | LeftShift: 0 | LeftAlt: 0 | Left GUI: 0 | RightControl: 0 | RightShift: 0 | RightAlt: 0 | Right GUI: 0 |Keyboard [DELETE (Backspace), 00, 00, 00, 00, 00] 
476.671297 ReportID: 1 / LeftControl: 0 | LeftShift: 0 | LeftAlt: 0 | Left GUI: 0 | RightControl: 0 | RightShift: 0 | RightAlt: 0 | Right GUI: 0 |Keyboard [00, 00, 00, 00, 00, 00] 

I used the DEL key to delete the sequence of "5" that appeared there.

Please let me know if the above helps, of if I need to parse also the
mouse events.

Regards,
Mauro

  parent reply	other threads:[~2015-11-07 17:22 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 [this message]
2015-11-09 10:36     ` Benjamin Tissoires
2015-11-09 13:16       ` Mauro Carvalho Chehab
2015-12-16 16:17   ` Clément VUCHENER
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=20151107152237.12018d2f@recife.lan \
    --to=mchehab@osg.samsung.com \
    --cc=benjamin.tissoires@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --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).