Changes to XInput Proto Number of Events Cause Xlib WireToEvent Vector Mismatch

[Nathan Kidd]

Julien Cristau wrote:
> On Wed, Nov 25, 2009 at 16:42:59 -0500, Nathan Kidd wrote:
>>   xlib sets event_vec[85 .. 85 + 17] xinput WireToEvent function, i.e.
>> OVERWRITES xkeyboard's WireToEvent proc because xserver only allowed for
>> 15 events between the event bases, since that's all it knew about when
>> it was built.
>> 4. the wrong WireToEvent function get's used on subsequent XKEYBOARD events
>>
>> On standard x.org the results aren't actually that terrible: XKEYBOARD
>> and LBX have their event bases right after XInputExtension so they're
>> the ones that get clobbered.  Since nobody uses LBX there's no effect,
>> and XKEYBOARD seems to a) either not be very noticable when it fails b)
>> not be used so often in conjunction with XInputExtension, or c) my
>> googling just can't turn up any complaints.  If you juggle around the
>> extensions (e.g. disable in xorg.conf) you can end up clobbering more
>> important/sensitive extension events with far worse results (here XFIXES
>> was after XInputExtension, triggering a segv in most gtk2 applications).
>
> This sounds like it could be the cause of http://bugs.debian.org/515946
> and/or http://bugs.debian.org/515734 which were reported by people
> using Xserver 1.4 with libXi 1.2, but were never diagnosed properly.

Yes, this is the exact same issue.  GDK gets an XFIXESSelectionNotify 
event that's been "decoded" by the wrong WireToEvent function, and ends 
up using a null window id causing a subsequent segv.  GDK should check 
its null pointer, but the root cause is as I described.

-Nathan