On Thu, Apr 8, 2021 at 3:19 PM Gerecke, Jason <Jason.Gerecke@xxxxxxxxx> wrote: > > 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). No worries. > > 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). Noted, thanks for explaining. > > > 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. Yes, we have just enough free slots within MSC_MAX to keep MSC_SERIAL and set up new MSC_TRANSDUCER_ID0 and MSC_TRANSDUCER_ID1 -- better names welcome. Since MSC_SERIAL has been weird and probably is often logically clamped in strange ways, I'm happy with keeping it entirely separate from the new clean ID events. (Any guess how much pain we are in for if we want to expand MSC_MAX?) > 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). For what it's worth, the variation I'm looking at now involves handling the longer fields in an arbitrary number of 32-bit slices, so it's not 64-bit specific on the hid-core side. Obviously it (currently) needs to fit back through evdev, so that is the bottleneck. - Kenneth - Kenneth
