(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.
(In reply to comment #49) tionControl, XDeviceAccelera tionState;
> (In reply to comment #48)
> > typedef struct {
> > XID control; /* DEVIC_PTRACCEL */
> > int length;
> > int type;
> > } XDeviceAccelera
> >
> > 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 { tionControl, XDeviceAccelera tionState;
XID control; /* DEVIC_PTRACCEL */
int length;
int type; /* which accel scheme */
int parameters; /* number of parameters following */
} XDeviceAccelera
parameters simply states how many of the following.
length encloses the whole control (inc. all parameters) to be compatible with older versions.
typedef struct { Control;
int param_type;
int length;
} XAccelParameter
and then you have multiple versions of
typedef struct { Coeff /* Coeff;
int param_type; /* DevicePtrAccel_
int length;
int integer;
int rational_num;
int rational_den;
} XDevicePtrAccel
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?