On Thu, Mar 25, 2021 at 09:35:33AM +0100, Benjamin Tissoires wrote: [...] > > I'm appending a proof-of-concept which implements this; I describe the > > details below. (This is based on 5.4, but it looks clean for 5.10 as > > well as relatively straightforward to backport.) > > > > I'd appreciate any feedback on this approach. > > > > 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). ABS_MISC is the tool ID, MSC_SERIAL is the 32-bit serial. Quick check suggests the upper bits of the 64-bit serial number are simply dropped. So afaict this situation is still officially unprecedented :) > I am not saying this is what needs to be done, but just what some > userspace tools already expect. > > > > > hid_field.value is expanded to an s64 array from s32, and there are > > a few knock-on effects to code that holds pointers to these fields. > > No other interfaces, in-kernel, or user-space, are modified to support > > HID reports/evdev events > 32 bits. > > I also think both problems are orthogonal (which is why you haven't > tried to change the evdev protocol). > > I don't think we can do much on the evdev side to support 64 bits or > bigger data. > Dmitry and Peter might find a good way to work around that, but I'm OK > with adding MSC_SERIAL_2 from my point of view. As long as the driver behaves well (i.e. it'll send *both* MSC_SERIAL and MSC_SERIAL2 in the same frame) it'll be easy to deal with in userspace. There's some theoretical option to have a special evdev event that works to combine the values of multiple events (similar to utf8) but I think that's something to consider when the problem is more wide-spread than a serial number, it's a bit overkill here. Cheers, Peter
