[PATCH v2] input: deliver raw events unconditionally for XI 2.1 clients.

[Peter Hutterer]

On Wed, May 25, 2011 at 11:50:56AM +0100, Daniel Stone wrote:
> Hi,
> 
> On Wed, May 25, 2011 at 02:44:01PM +1000, Peter Hutterer wrote:
> > On Sat, May 21, 2011 at 01:21:28PM +0100, Daniel Stone wrote:
> > > I'd rather do the filtering in TryClientEvents, where we already do
> > > pretty much all the filtering.
> > 
> > Sure, why not, see below.
> 
> Thanks, this looks better.
> 
> > > Speaking of: TryClientEvents will bin the event
> > > if (grab && !SameClient(grab, client)).  So don't you need to change
> > > that to get this working as well?
> > 
> > This whole thing relies on the right caller order. Which is a bit of a hack
> > but until we have internal events everywhere the best way to integrate it.
> > From the comments in the patch:
> >  * grab is non-NULL when coming from DeliverGrabbedEvent(), otherwise NULL.
> > 
> > So for a raw event during grabs we get called twice. The first time without
> > a grab (where we filter for XI2.0) and the second time with a grab (where
> > we filter for XI 2.1 and XI2.0 if grab && !SameClient())
> > 
> > and yes, this is a bit flimsy, I agree.
> 
> Hm, I have to admit I'm still a little bit lost here.  Does
> ProcessRawEvent get called twice? At the moment I'm still only seeing
> the one test in TryClientEvents, below the if (grab && !SameClient)
> test which will unconditionally discard it.  Hopefully I'm just being
> dense. :)

sorry, my apologies, I was describing an earlier version of this patch.
ProcessRawEvents works like this with this patch:

for all root windows:
   DeliverEventsToWindow(root window[n], NullGrab)
       DeliverEventToClient(NullGrab)
           TryClientEvents(NullGrab)
               grab && !SameClient() is always false
               if not FilterRawEvents()
                   deliver event

And FilterRawEvents() simply checks the device directly for a grab. If the
device is grabbed but not by this client, it only delivers if the client is
2.1.

However, in re-reading this I noticed a different issue in that a
client that has the RawEventMask set in a grab but not in the normal event
mask would not get the events because the wrong event mask is being used.
I'll need to send another version of this patch.

Cheers,
  Peter