On 29/09/21 07:22, Tomasz Moń wrote:
Hello, USB HID Usage Tables 1.22 specifies plenty of usages. Usages include for example, keyboard keys, LEDs, buttons, VR controls, etc. Usages are grouped into pages. There are plenty of usages, e.g. button page alone is 65536 items (0x0000 means no button pressed, 0x0001 means button 1, ..., 0xFFFF means button 65535). Each usage is uniquely identified by 32-bit value that consists of 16-bit page and 16-bit id. Some usages don't have numeric value associated with it, but are selectors. Example selector is keyboard keys, where the report data specifies indexes from an array that determines what keys are being pressed. For example keyboard that supports up to 6 simultaneous key presses, reports 6 indexes (index 0 usually means no key pressed and other indexes determine pressed key). Every USB HID device provides descriptior that determines what the report data bytes means. Current Wireshark development version annotates all usages from USB HID Usage Tables 1.22 but the usages are not really filterable. Possible solution is to register hf for each usage. This can be achieved by either dynamically allocate required hfs after dissecting report descriptor or preallocating all hfs (either dynamically at runtime, or automatically generate the code). The hf name can be consutructed algorithmically based on the usage page and name. As the number of usages is quite high, I am concerned if getting one hf field for each is the way to go.
That concerns me too. I think we need to come up with better ideas for that use case.
A completely different approach
would be to have generic hf and make the filter value somehow encode usage page, id and value (if any).
How about having an fvalue type FVALUE_USB_HID and a display filter function that also returns FVALUE_USB_HID given some input parameters, like page and id, or whatever else??
I am not sure which of the above proposed options is worth pursuing. Best regards, Tomasz Moń ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
