[RFC] Patch series: switching to internal events

Simon Thum simon.thum at gmx.de
Wed Feb 4 03:06:45 PST 2009


Hi Peter,

looks pretty good to me.

One tiny nit however: E.g. in eventconvert.c there are switch statements
which go like

switch(EventType){
...big list of labels for one thing...: do it; break;
}

So essentially, I guess, you're checking for some commonality, or
property. Centralizing such checks is one of the benefits enabled by
your approach (less if/else/misc). IMO it would be a good thing to show
that "you're right" by reducing such examples. Maybe by introducing a
'event class' or similar, to be stored with the event.

Peter Hutterer wrote:
> 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'm not sure how to continue from there. The options are
> - merge into master, keep working on master
> - keep rebasing as non-fast-forward on external branch on my people repo
> - push into a public branch and merge into master when complete.
> 
> Cheers,
>   Peter
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 




More information about the xorg mailing list