[PATCH 2/2] DIX/Xi: Don't grab device buttons if no grab is registered

[Egbert Eich]

On Fri, Aug 30, 2013 at 02:00:55PM +1000, Peter Hutterer wrote:
> On Fri, Aug 16, 2013 at 01:56:07PM +0200, Egbert Eich wrote:
> > On Fri, Aug 16, 2013 at 03:37:42PM +1000, Peter Hutterer wrote:
> > > On Thu, Aug 15, 2013 at 03:49:21PM +0200, Egbert Eich wrote:

> > > 
> > > it is specified, see XIproto.txt:
> > >   For DeviceButtonPress events, the client may specify whether or
> > >   not an implicit passive grab should be done when the button is
> > >   pressed. If the client wants to guarantee that it will receive
> > >   a DeviceButtonRelease event for each DeviceButtonPress event it
> > >   receives, it should specify the DeviceButtonPressGrab event
> > >   class as well as the DeviceButtonPress event class. This
> > >   restricts the client in that only one client at a time may
> > >   request DeviceButtonPress events from the same device and
> > >   window if any client specifies this class.
> > > 
> > > I read this as default: no implicit grab, DeviceButtonPressGrab: always
> > > implicit grab.
> > 
> > Exactly. The current behavior is to do an implicit grab, though.
> > 
> > > 
> > 
> > A customer had the issue that he wanted to receive Xi events on the same
> > window with two clients simultaniously. He claimed that this was working
> > with Xserver 1.5.2 which we shipped with SLE-11 originally but 'broke' 
> > with the first SP when he got Xserver 1.6.5.
> 
> when was this problem being reported? wikipedia tells me SP1 was released in
> June 2010. either way, if that broke in 1.6 it means we've now shipped 8
> versions of X with the broken behaviour and restoring it could well break
> some other application. rock, hard place, frying pan, etc.
> 

This problem has been reported in 2011. We subsequently changed the behavior
back to the old one in the Xserver we ship at SUSE for SLE11 as the Xserver
upgrade changed the behavior within an existing product.
>From our side we did not see any reports that something else broke after
restoring the old behavior.
Technically we could carry this patch for the existing product but drop
it for a new one as we can much more easily break existing behavior
then.
The customer used the Xi extension so that two separate clients would 
receive both button events - press and release. In his controlled 
environment the customer was able to ensure that noone ever did a
DeviceButtonPressGrab on those.

I do see your point regarding 'the broken behavior has been around for
so long'. However we still have specs and the current behavior don't
match the specs. How good are the specs if we deviate (even slightly)
from them?
We don't seem to have a good procedure how to deal with cases where
the implementation doesn't meet the specs.
In the past we seemed to have had cases where the specs have been 
written long _after_ the implemenation (maybe not as written specs 
but in from of vsw5 test cases) and have contradicted what had long 
been implemented. Of course in this case there is little question 
that we should rather stick to the implemenation.
However here we have broken the spec-ed behavior at some point along 
the way and not discovered it for some time - should we really keep 
the spec-violating behavior? 
Currently we don't even seem to document such.

ATM I see two issues with this:

a. There may be application developers who design their software 
   according to what is allowed by the specs. They may rightfully 
   argue that _we_ are violating the expected behavior - not them.
b. The X Window System is a protocol specification together with 
   the SI.  This means that alternative implementations of the 
   X protocol that may behave according to the specs and thus differ 
   from us.


Cheers,
	Egbert.