Re: HID vendor access from user space

On Wed, Apr 16, 2014 at 4:53 PM, Jiri Kosina [off-list ref] wrote:

On Tue, 15 Apr 2014, Nestor Lopez Casado wrote:

quoted

quoted

Frankly, I'd really like to avoid any parsing (deciding about collections)
whatsoever around hidraw, as that was the whole point of creating it in
parallel to hiddev was simply 'no parsing, raw access'.

We should avoid naming the new nodes "hidrawX" they could be
"hidvendorX" for instance, or it could also be "hidcolX" where col
stands for collection. We will be moving the "raw" one level down.

I am still having trouble seeing how this would work together with current
hidraw.

In your proposal, there will be both hidrawX and hidcolX existing in
parallel, right?

Yes.

Who will be deciding what goes to hidcolX instead of
hidrawX?

The additional code that we will put in place.
Having said that, hidrawX will still get the same reports as before,
nothing will change for those nodes.

One of the pain points would be -- /dev/hidrawX will have to stay
anyway for compatibility reasons, so we can't just divide it to multiple
/dev/hidcolX all of a sudden and never look back.

That's true.

A device with one mouse collection and one vendor collection would
give something like this:
/dev/input/eventX  (no change) this comes via hid-input
/dev/mouse           (no change)
/dev/hidrawX         (no change) (all reports still show up here)
/dev/hidcolX          (reports from corresponding colX will show up here)

So only top level vendor collections which are not parsed (claimed) by
any hid-xx module today would appear under hidcolX.

Unless you have a major blocker, as David said, I think the best would
be to come up with some code and post a proposal patch for
consideration.

--
Jiri Kosina
SUSE Labs

Cheers,
-nestor