[PATCH 2/6] Input: Don't freeze unrelated devices in DeliverGrabbedEvent

Peter Hutterer peter.hutterer at who-t.net
Wed Feb 16 15:13:07 PST 2011


On Tue, Feb 15, 2011 at 08:11:25PM +0100, Simon Thum wrote:
> On 02/15/2011 12:27 PM, Daniel Stone wrote:
> > When delivering an event to a device grabbed with SyncBoth,
> > DeliverGrabbedEvent walks the device tree looking for associated devices
> > to freeze them.  Unfortunately, it froze all devices instead of just the
> > paired device, and the previous fix in 4fbadc8b17237f3c would still break
> > if the same client had a non-SyncBoth grab on another unrelated master
> > device.
> > 
> > Fix this by completely ignoring devices that aren't our paired device.
> > 
> > Signed-off-by: Daniel Stone <daniel at fooishbar.org>
> > ---
> >  dix/events.c |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/dix/events.c b/dix/events.c
> > index 5e8166d..80792ee 100644
> > --- a/dix/events.c
> > +++ b/dix/events.c
> > @@ -3884,14 +3884,14 @@ DeliverGrabbedEvent(InternalEvent *event, DeviceIntPtr thisDev,
> >  	case FREEZE_BOTH_NEXT_EVENT:
> >  	    for (dev = inputInfo.devices; dev; dev = dev->next)
> >  	    {
> > -		if (dev == thisDev)
> > +		if (dev == thisDev || dev != GetPairedDevice(thisDev))
> >  		    continue;
> I wonder if it's worth traversing the list since you know both devices.
> Moving that into a function called twice instead of in a loop might help
> readability. It also avoids repeated GetPairedDevice calls.

I agree with Simon, having a loop that only triggers on one device seems a
bit excessive.

Cheers,
  Peter

> 
> >  		FreezeThaw(dev, TRUE);
> >  		if ((dev->deviceGrab.sync.state == FREEZE_BOTH_NEXT_EVENT) &&
> >  		    (CLIENT_BITS(grab->resource) ==
> >  		     CLIENT_BITS(dev->deviceGrab.grab->resource)))
> >  		    dev->deviceGrab.sync.state = FROZEN_NO_EVENT;
> > -		else if (GetPairedDevice(thisDev) == dev)
> > +		else
> >                      dev->deviceGrab.sync.other = grab;
> >  	    }
> >  	    /* fall through */
> 
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
> 


More information about the xorg-devel mailing list