[RFC] Patch series: switching to internal events

Peter Hutterer peter.hutterer at who-t.net
Mon Feb 2 22:10:24 PST 2009


On Tue, Feb 03, 2009 at 03:15:51AM -0200, Tiago Vignatti wrote:
> Peter Hutterer escreveu:
>> git://people.freedesktop.org/~whot/xserver.git internal-events
>>
>> The current X server implementation uses the protocol wire format for input
>> event processing. This goes from event generation in GetPointerEvents() and
>> friends through to the actual event delivery.
>>
>> Thus, the server is bound internally to a 32-byte wire format + the two
>> GenericEvents we have atm, with random if/then/else/other sprinkled to deal
>> with core, XI and GenericEvents. Adding new events for XI2 is painful, as we
>> have to extrapolate new information from structs that don't have them. And
>> sprinkle more if/else/misc across the code.
>>
>> This patch series introduces a new InternalEvent, visible only to the server.
>> Event generation and most of the event processing now only uses this
>> InternalEvent.
>> Towards the end of event delivery, we switch back into core/XI events.
>> Arguably, this could be pushed even further but requires a rework of the mess
>> that constitutes event masks.
>>
>> I've been running versions of it during development, and put some effort in to
>> make all commits run-able (for future bisecting). They're rebased onto today's
>> master.
>>
>> Casualties: custom event handlers, DGA, event callbacks are broken for now.
>> No reason they can't be fixed, I just didn't bother yet.
>>
>> Comments and testing much appreciated.
>
> I don't what would be the overhead of this approach but maybe we can win  
> some performance doing all 'switch' in eventconvert.c as a vector of  
> pointers. Something like tables.c.

Depends. Right now, only a few events are actually used as internal events.
Anything that calls DeliverEventToAllWindows() for example bypasses the whole
thing anyway.

The table would make sense once we start dealing purely in internal events,
but for now I think code is easier to maintain without it.

Cheers,
  Peter



More information about the xorg mailing list