Comment 64 for bug 28052

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

(In reply to comment #49)
> (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)

Ah. now I finally get it. I interpreted the parameters as different accel schemes rather than parameters for the same scheme.

Nevertheless, my proposal still holds. The length field is 16 bit, which should be enough to stack device controls. Something along the line of

typedef struct {
     XID control; /* DEVIC_PTRACCEL */
     int length;
     int type; /* which accel scheme */
     int parameters; /* number of parameters following */
} XDeviceAccelerationControl, XDeviceAccelerationState;

parameters simply states how many of the following.
length encloses the whole control (inc. all parameters) to be compatible with older versions.

typedef struct {
   int param_type;
   int length;
} XAccelParameterControl;

and then you have multiple versions of

typedef struct {
    int param_type; /* DevicePtrAccel_Coeff /*
    int length;
    int integer;
    int rational_num;
    int rational_den;
} XDevicePtrAccelCoeff;

this is a similar approach to what the ListInputDevices reply does with the classes.

advantages:
 we don't mess up the CONTROL range,
 we have _a huge_ range of parameters.
 the type field allows for multiple different accel types
 parameters are re-usable.

and 16 bit for the length should be enough for even multiple parameters.

does that make sense? any comments?