[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