First of all, my apologies for the likely-wonky email formatting. For some reason I'm missing messages from linux-input in my Gmail so I'm forced to reply from Outlook (which doesn't exactly make inline plain-text replies easy).
> > > My thought is to perform minimal modifications to allow hid-core to
> > > transfer reports up to 64-bits in size to hid-input, so that it can
> > > process this field and emit it to the power_supply integration, as well
> > > as through classic MSC_SERIAL (for the low 32 bits) and a new
> > > MSC_SERIAL2 (the upper bits) for applications which want it inline with
> > > stylus event data.
> >
> > The wacom driver already has this problem and handles it in a creative
> > way (as usual ;-P)
> > If I am not mistaken, it splits the 64 bits serial on 2 events as
> > well: MSC_SERIAL and ABS_MISC (Jason might correct me here).
> >
> > I am not saying this is what needs to be done, but just what some
> userspace tools already expect.
>
> As Peter mentions, this seems separate, ABS_MISC being a sort of tool
> type identifier, quite different from the serial number. (They apparently
> get extracted from the same data report in the wacom formats, but the
> intention seems distinct.)
>
> As far as I can see, the Wacom S/N (stuffed into MSC_SERIAL) is indeed
> always truncated to 32 bits; introducing MSC_SERIAL2 should be suitable
> for the wacom driver as well if they want to publish the high bits.
ABS_MISC and MSC_SERIAL are nominally the tool type and serial number fields. A given serial number may be re-used across tool types, however, and so the two fields must be combined to get a globally unique ID. It's not *quite* that simple though:
* The ABS_MISC field is sometimes intentionally mangled for compatibility with an ancient wacom.ko bug
* A 32-bit MSC_SERIAL is sometimes not quite large enough to store the nominal serial number
* The way the values are assembled varies between devices (i.e. on some devices ABS_MISC is the high "n"-bits, on others it is the low "n"-bits, and "n" may vary).
I'd love to have a way for our driver to report an unmangled 64-bit unique ID which matches what you'd get on Windows and OSX, but I don't think MSC_SERIAL2 quite solves that problem for us. We could use it with devices which have MSC_SERIAL as the low 32 bits of the unique ID, but not those that have ABS_MISC as the low "n"-bits).
> > If changing MSC_SERIAL is deemed too risky for compatibility, then it's
> > easy to just leave MSC_SERIAL as-is, and put in a separate MSC_SERIAL1
> > (MSC_SERIAL0?) that has the pristine low bits -- just at a cost of yet
> > one more MSC_ field per report, and using up the last MSC_ bit before
> > we need to bump MSC_MAX.
> >
> > This approach doesn't affect Wacom evdev events at all, all of that
> > logic is separate from hid-input.
>
> There is a whole ecosystem for wacom, but we are pretty much in
> control of all the pieces. So I would prefer involving wacom from the
> beginning, and have a common representation to the user space.
Providing a separate MSC_SERIAL1 (or zero) in addition to MSC_SERIAL2 could be the solution to the problems above. Our driver can be taught how to assemble the 64-bit IDs and then split them into events for the high- and low-order bytes. We might want to consider using a different prefix than MSC_SERIAL if we go this route, however. It could be very confusing to understand how all three events do (and don't) relate to each other if their names are too similar.
Of course, it'd also be great if the input structs could fit 64-bit integers, but that's probably not possible (and also doesn't help with devices that want to report e.g. 128-bit numbers).
