From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: "Junge, Terry" <Terry.Junge@plantronics.com>,
Jiri Kosina <jikos@kernel.org>,
"oneukum@suse.de" <oneukum@suse.de>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC/RFT] HID: primax: Fix wireless keyboards descriptor
Date: Thu, 07 Mar 2019 17:20:35 +0100 [thread overview]
Message-ID: <d473feac52a9411a7ffb585aa61e2614df890972.camel@suse.de> (raw)
In-Reply-To: <CAO-hwJ+9ft070W-shhEwxfTq9B5XyVB2v6Qx0b4nC4LdTiTEDg@mail.gmail.com>
[-- 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 --]
prev parent reply other threads:[~2019-03-07 16:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-28 13:55 [RFC/RFT] HID: primax: Fix wireless keyboards descriptor Nicolas Saenz Julienne
2019-02-28 17:02 ` Junge, Terry
2019-02-28 18:01 ` Nicolas Saenz Julienne
2019-03-01 9:48 ` Benjamin Tissoires
2019-03-07 16:20 ` Nicolas Saenz Julienne [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d473feac52a9411a7ffb585aa61e2614df890972.camel@suse.de \
--to=nsaenzjulienne@suse.de \
--cc=Terry.Junge@plantronics.com \
--cc=benjamin.tissoires@redhat.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oneukum@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).