Re: [RFC/RFT] HID: primax: Fix wireless keyboards descriptor

[Nicolas Saenz Julienne <nsaenzjulienne@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 3170 bytes --]

On Fri, 2019-03-01 at 10:48 +0100, Benjamin Tissoires wrote:
> On Thu, Feb 28, 2019 at 7:01 PM Nicolas Saenz Julienne
> <nsaenzjulienne@suse.de> wrote:
> > On Thu, 2019-02-28 at 17:02 +0000, Junge, Terry wrote:
> > > This could also be a parser error. In the HID specification section
> > > 6.2.2.8 it
> > > states that the last declared Usage Page is applied to Usages when the
> > > Main
> > > item is encountered.
> > > 
> > > "If the bSize field = 1 or 2 then the Usage is interpreted as an unsigned
> > > value
> > > that selects a Usage ID on the currently defined Usage Page. When the
> > > parser
> > > encounters a main item it concatenates the last declared Usage Page with a
> > > Usage to form a complete usage value. Extended usages can be used to
> > > override the currently defined Usage Page for individual usages."
> > > 
> > 
> > Hi Terry, thanks for the comment.
> > Just for the record the paragraph I cited on my patch is the following:
> > 
> >         6.2.2.7 Global Items
> > 
> >         [...]
> > 
> >         Usage Page: Unsigned integer specifying the current Usage Page.
> > Since a
> >         usage are 32 bit values, Usage Page items can be used to conserve
> > space
> >         in a report descriptor by setting the high order 16 bits of a
> >         subsequent usages. Any usage that follows which is defines* 16 bits
> > or
> >         less is interpreted as a Usage ID and concatenated with the Usage
> > Page
> >         to form a 32 bit Usage.
> > 
> >         * This is a spec errata, I belive it should say "defined"
> > 
> > As you can see they use the word "follows" which in my opinion contradicts
> > the
> > paragraph you pointed out. That said I may be wrong, I'm not too good at
> > reading specs :).
> 
> I think you are both right (that is some decision making skills :-P).
> 
> I never saw a case where the Usage Page was after the Usage. And I
> would lean towards Nicolas interpretation.
> However, Terry's point is valid too, and by re-reading the two
> paragraphs, one could argue that the "follows" of 6.2.2.7 could be
> applied when the Main item is processed as in 6.2.2.8.
> 
> So I am going to base my decision on the "reference" driver. How well
> behaves Windows with this particular keyboard?
> 
> If it behaves properly, then we better use the 6.2.2.8 version where
> the Usage Page is only appended when there is a Main item. This means
> we need to remember what size was the last Usage (and Min/Max), to
> know if we should concatenate the 2.
> 
> Note that for every change that involves the generic parser, I'd like
> a few tests added to `tests/test_keyboard.py in
> https://gitlab.freedesktop.org/libevdev/hid-tools
> Also note that the HID parser implementation in hid-tools follows the
> kernel, so we might need to adjust it there too if we want to add high
> level events. If you directly call `.call_input_event()` with raw
> events, it should be fine.

Thanks for the reply. I might get my hands on one of the faulty keyboards soon
so I'll be able to check windows' behaviour and test the patches.

Regards,
Nicolas


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]