[Preferences/Input] Keyboard gaining severall entries

[nephele]

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.

[nephele]

preferences after 3 disconnects

[diver]

Maybe syslog could give a clue?

[pulkomandy]

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.

[nephele]

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?

[pulkomandy]

Usually I use ​https://eleccelerator.com/usbdescreqparser/ after converting it to text using xxd (there is an option to convert it to a "C array" that works).

[pulkomandy]

​https://review.haiku-os.org/c/haiku/+/2715

[pulkomandy]

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.