Opened 12 months ago

Last modified 11 months ago

#15857 new bug

[Preferences/Input] Keyboard gaining severall entries

Reported by: nephele Owned by: PreetpalKaur
Priority: normal Milestone: Unscheduled
Component: Preferences/Input Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All


I have tested one USB keyboard which gains 5! entries each time i connect it to the laptop, now on disconnect one of those entries dissapears, but the other 4 stay, I am not sure what went over the wire to prompt it to create 5 entries, that may be worth investigating (to get only one), but it should definetely take all categories away on disconnect.

Attachments (3)

screenshot1.png (33.4 KB ) - added by nephele 12 months ago.
preferences after 3 disconnects
usb_hid_report_descriptor_0c45_7603_0.bin (65 bytes ) - added by nephele 11 months ago.
usb_hid_report_descriptor_0c45_7603_1.bin (169 bytes ) - added by nephele 11 months ago.

Download all attachments as: .zip

Change History (9)

by nephele, 12 months ago

Attachment: screenshot1.png added

preferences after 3 disconnects

comment:1 by diver, 12 months ago

Maybe syslog could give a clue?

comment:2 by pulkomandy, 12 months ago

Creating multiple entries is not necessarily a problem (HID devices can be composite, for example keyboard+mouse in a single device), but we probably need some filtering there, because our current logic is something along the lines of:

  • Is this a mouse?
  • Is this a gamepad/joystick?
  • Is this a wacom tablet?
  • Ok, must be a keyboard then!

And a lot of useless "devices" get promoted to keyboards. This was not visible when there was no way to list input devices, but now it is.

The HID report for that keyboard (automatically written to /tmp when you connect it) may confirm this.

As for the devices not being removed, I don't remember seeing that. My mouse currently creates I think 3 devices, but they all are removed when I unplug it.

comment:3 by nephele, 12 months ago

Creating multiple entries is not necessarily a problem

I did not mean to imply that it is neccesarily it was moreso about them not beeing removed, i should have named the ticket diffeently, but if we can infer a causal relationship we could atleast group them nicely together, to make it clear that those three components are from one device, but can be configured seperately That might give a bit cleaner UI

for the HID report, how would i view it's content?

comment:4 by pulkomandy, 12 months ago

Usually I use after converting it to text using xxd (there is an option to convert it to a "C array" that works).

comment:6 by pulkomandy, 11 months ago

Interesting, so your keyboard indeed has split the keys into multiple separate "input reports", I guess to allow reporting the status of more keys without increasing the latency too much by sending the status for all keys everytime one of them changes.

Our driver will indeed create one KeyboardProtocolHandler for each of these reports (KeyboardProtocolHandler::AddHandlers). It looks like we should refactor this to create a single KeyboardProtocolHandler which would process multiple HID reports coming from the same device instead.

Note: See TracTickets for help on using tickets.