On Wed, Apr 16, 2014 at 4:53 PM, Jiri Kosina <jkosina@xxxxxxx> wrote: > On Tue, 15 Apr 2014, Nestor Lopez Casado wrote: > >> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
