Comment 63 for bug 28052

(In reply to comment #48)
> typedef struct {
> XID control; /* DEVIC_PTRACCEL */
> int length;
> int type;
> } XDeviceAccelerationControl, XDeviceAccelerationState;
>
> for the default, and then depending on the type you have a struct for each
> accel scheme that needs it. type determines which struct, and since length is
> in bytes anyway, nothing breaks by adding new schemes.
Looks good, absolutely on option. Let's call it option (1).
What it doesn't do is provide a simple way to add a parameter. You'll have to modify libXi, inputproto and modify marshalling (client and server). The current approach provides simple end-to-end transport - and by reserving a range incl. surplus we could be ABI safe too. (2)

OTOH, I'm not sure if it is desirable to have this ability at all.

> I'll have a look at the server patch but the inputproto stuff in its current
> state is a dealbreaker.
Would that still hold if the set of parameters was considerably smaller and with fixed codes assigned (and of course not resorting to range checks in switch() default: paths) ?
This would however mean not every knob is tweakable, a thing I'm fine with. (3)

Since libXi is yours, I'll leave the choice to you. My vote is for (2).