Re: Supporting 64-bit Digitizer Serial Numbers?

On Thu, Mar 25, 2021 at 09:35:33AM +0100, Benjamin Tissoires wrote:
[...]

quoted

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.

quoted

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