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@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe