On Sun, Dec 11, 2011 at 09:50:33PM -0800, Chase Douglas wrote: > On 12/08/2011 07:36 PM, Peter Hutterer wrote: > > No functional changes. > > > > Signed-off-by: Peter Hutterer <[email protected]> > > --- > > dix/events.c | 81 > > +++++++++++++++++++++++++++++++++++++++++++--------------- > > 1 files changed, 60 insertions(+), 21 deletions(-) > > > > diff --git a/dix/events.c b/dix/events.c > > index 4d80358..9fcd447 100644 > > --- a/dix/events.c > > +++ b/dix/events.c > > @@ -3751,6 +3751,62 @@ CoreGrabInterferes(DeviceIntPtr device, GrabPtr grab) > > return interfering; > > } > > > > +enum MatchFlags { > > + NO_MATCH = 0x0, > > + CORE_MATCH = 0x1, > > + XI_MATCH = 0x2, > > + XI2_MATCH = 0x4, > > +}; > > + > > +/** > > + * Match the grab against the temporary grab on the given input level. > > + * Modifies the temporary grab pointer. > > + * > > + * @param grab The grab to match against > > + * @param tmp The temporary grab to use for matching > > + * @param level The input level we want to match on > > + * @param event_type Wire protocol event type > > + * > > + * @return The respective matched flag or 0 for no match > > + */ > > +static enum MatchFlags > > +MatchForType(const GrabPtr grab, GrabPtr tmp, enum InputLevel level, int > > event_type) > > +{ > > + enum MatchFlags match; > > + BOOL ignore_device = FALSE; > > + int grabtype; > > + int evtype; > > + > > + switch(level) > > + { > > + case XI2: > > + grabtype = GRABTYPE_XI2; > > + evtype = GetXI2Type(event_type); > > + BUG_WARN(!evtype); > > + match = XI2_MATCH; > > + break; > > + case XI: > > + grabtype = GRABTYPE_XI; > > + evtype = GetXIType(event_type); > > + match = XI_MATCH; > > + break; > > + case CORE: > > + grabtype = GRABTYPE_CORE; > > + evtype = GetCoreType(event_type); > > + match = CORE_MATCH; > > + ignore_device = TRUE; > > + break; > > + } > > + > > + tmp->grabtype = grabtype; > > + tmp->type = evtype; > > Why use two variables on the stack when you could just set tmp->grabtype > and tmp->type directly in the switch statement?
I think this may be a leftover from a previous patch or preparation for a future patch, can't remember, tbh. either way, the functionality is the same as you said, so I'd rather leave it as-is. > There aren't any functional issues with the code. As such, it's good > enough for me: > > Reviewed-by: Chase Douglas <[email protected]> thanks. Cheers, Peter _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
