[RFC] Device hierarchy for MPX

[Peter Hutterer]

Daniel Stone wrote:
> FWIW, this bears a reasonably close relation to what we have already
> with the virtual core devices.  Any operation on a control group (grab,
> set keymap, whatever) explodes and acts on all those devices.

Yep, I know. That means I might have to revert a few changes and I can 
look at master as a cheatsheet to look how the states get sorted out.

> This should be fine for keyboards, with the slightly odd semantics that
> holding down Ctrl on one keyboard and pressing Q on another will quit
> your app.  As I explained, sending both the individual and merged state
> in the event will 'solve' this, but it's a question if these are the
> semantics we want or not.

I tried this with my server here, this behaviour is true for the mouse 
as well. Pressing button on M1 and moving M2 will drag things around.

I guess we have to draw a line somewhere and say "If you're trying to 
use two keyboards/mice for the same focus/sprite then things are weird. 
Stop doing that!"

> Again, we can just send the valuator params in the events, to let them
> adjust without sending still more events.

The reasoning behind the DeviceStateChangeNotifies was
a) we need them anyway to tell clients when the SD attachment changes. 
(although the info could also be added to the DevicePresenceNotify)
b) it makes client-side programming easier, as the state only has to be 
swapped for the DSCN, rather than checking each event for the current 
device configuration. In practice, users probably won't switch SDs 
inside a MD group that often.


Cheers,
   Peter