Proposed libX11 ABI break

[Peter Hutterer]

On Fri, Jun 26, 2009 at 03:46:26PM -0400, Eamon Walsh wrote:
> Peter Hutterer wrote:
> > This week, I ran into a wall trying to get XI2 events sorted out. Resolving
> > this may require a libX11 ABI break. This is NOT XI2 specific, it just
> > happens to be the first extension to run into this issue.
> > This is a rather lengthy email, please take the time and read it.
> >
> > == Problem ==
> > XNextEvent(Display*, XEvent*) requires the event to be 96 (32-bit) or 192
> > (64-bit) bytes. This is a side-effect of the definition  of the XEvent
> > structure itself.
> >
> > XGE's long events may require structs that exceed this space. For XI2, the
> > solution I have used so far are pointers inside the respective XEvent struct
> > that point to other allocated memory. The client is required to call
> > XIFreeEventData() to ensure this extra memory is freed accordingly.
> >
> >   
> 
> Why don't we just not support returning XGE events from those old
> functions ?

This was the alternative towards the end of the previous email. To quote:

>> The only other solution I could come up with so far is to add XGENextEvent()
>> and friends as substitutes for XNextEvent & co. In this approach, XNextEvent
>> _never_ returns generic events, leaving existing clients ABI-safe.
>> XGENextEvent requires an argument of the cookie+data type.
>>
>> This approach obviously has a high cost to clients as they need to adjust
>> for this new API.
>>
>> [Note that some new API is unavoidable. For example, XCheckTypedEvent does
>> not work in light of generic events as they share the same type. Additional
>> XGECheckTypedEvent() APIs are required, but they are required either way.]

basically this means that anyone dealing with the new XI2 API (or future
extensions) needs to also switch the mainloop to the new XGENextEvent and
cohorts.
 
Cheers,
  Peter