RFC: sorting out grabs

[Peter Hutterer]

I'm on the verge of deciding a significant bit of the xserver's 
behaviour so I'd like some input please:

==== Background: ====
Grabs are a way of forcing devices to only report to a specific client 
(the grabbing client). There are two different types of grabs: core 
grabs (GrabPointer and GrabKeyboard) and device grabs (X input 
extension, GrabDevice).

Each time a device emits an event, it creates a device event and (maybe) 
a core event. The device event is put on the event queue and processed 
with a reference to the original device. The core event however is 
processed with the core pointer. After GetPointerEvents, all core events 
appear to have originated from the core pointer and all device events 
from their device.

If we have a core grab, we have it on the core pointer/keyboard, thus 
all core events, no matter which device caused them, belong to us. A 
device grab will only send us the Xi events, while the core events still 
go wherever they are supposed to. As a result, we can have multiple 
device grabs but only ever one* core grab.

[From http://wiki.x.org/wiki/Development/Documentation/GrabProcessing]


==== Pending decisions ====
ATM, there are two decisions pending and they will affect the behaviour 
of the server significantly (It won't affect setups with only one 
keyboard/mouse pair much though)

== Multiple grabs - yes or no ===
MPX removes the notion of the core pointer/keyboard. A device can send 
core events** or not, but all pointers/keyboards are equal.
Should we continue to allow two grabs on the devices or only one?

To be more precise, if a client core-grabs a device, should the device 
be grab-able by an other client for XI events? And the other way round 
of course.

This is what MPX currently does, but a situation can arise where a 
client grabs the pointer (e.g. for a popup menu), while __at the same 
time__ the pointer can interact in some other XI aware application. This 
is potentially dangerous. Tbh, I can't think of any situation where this 
may be useful.

I would like to remove the double-grab feature and go back to one. Comments?

== Behaviour of other-devices during a grab ==
What do we do with other devices during a grab?
If a client grabs one device, we cannot just lock up all other devices 
so they can't interact with the desktop. So we need some sensible rules:

At the moment, the grab behaviour is the following:
When a client C has a grab on pointer X or keyboard Y:
   X/Y _only_ send to C.
   any other device Z can send to all clients but C.
   Z will not send events to C, except
   if Z is a pointer and the event.window == grabWindow, Z sends to C.
(The last made popup menu less painful if you don't have a MPX aware WM)

This works ok, but as I said, it changes the notion of a grab. Right 
now, the notion is along the lines of  "Don't deliver events to anybody 
but me". With those changes the notion is more like "I want to get 
exclusively get events from device X".

Comments?


Cheers,
   Peter

*well, two actually, one for the core pointer, one for the core keyboard.

** MPX  deprecates core events and any new application that uses core 
events is prone to a visit by the fuckup fairy.