[PATCH inputproto 1/3] Unbreak protocol ABI for XIAllowEvents.

[Peter Hutterer]

On Tue, Jan 31, 2012 at 08:49:58PM +0100, Chase Douglas wrote:
> On 01/27/2012 06:50 AM, Peter Hutterer wrote:
> > XIAllowEvents was extended with touchid and grab_window in
> > 2ea2f99f4fe1dcd3b8e539ca41c482fc40a0533d. This extended the size of the
> > request from 12 to 20 but also broke the ABI. Older server match the request
> > size exactly, so compiling libXi 1.5 against inputproto 2.2 and then running
> > it against a pre-XI 2.2 server causes a BadLength for any XIAllowEvent
> > request.
> > 
> > Change the new fields from actual fields to simple comments and let the
> > library/server deal with the extra data.
> > 
> > Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> > ---
> >  XI2proto.h |    6 +++---
> >  1 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/XI2proto.h b/XI2proto.h
> > index 93d7e32..9039fe7 100644
> > --- a/XI2proto.h
> > +++ b/XI2proto.h
> > @@ -647,10 +647,10 @@ typedef struct {
> >      uint16_t    deviceid;
> >      uint8_t     mode;
> >      uint8_t     pad;
> > -    uint32_t    touchid;                /**< Since XI 2.2 */
> > -    Window      grab_window;            /**< Since XI 2.2 */
> > +    /* uint32_t    touchid;            Since XI 2.2 */
> > +    /* Window      grab_window;        Since XI 2.2 */
> >  } xXIAllowEventsReq;
> > -#define sz_xXIAllowEventsReq                   20 /**< Was 12 before XI 2.2 */
> > +#define sz_xXIAllowEventsReq                   12 /**< 20 in XI 2.2 */
> >  
> >  
> >  /**
> 
> If we're going to break the abi between all three of inputproto, libxi,
> and xserver, I'd like to ask if we should just skip all this
> hoop-jumping and create new protocol requests for the XI 2.2 (and
> hopefully XI 2.3) versions of AllowEvents. This is all getting very
> hairy and error-prone. What are we really gaining by reusing a request
> number?

The requests are extendable and IMO caution should be used not unncessarily
using up the request range (which is 256 per extension). yes, we're quite
far from it anyways and will likely never exceed it but really, the amount
of work to add another 4 byte field is rather trivial.

Cheers,
  Peter