Re: Filtering USB HID fields

[João Valverde via Wireshark-dev <wireshark-dev () wireshark org>]

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-request () 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-request () wireshark org?subject=unsubscribe