[RFC] Device hierarchy for MPX

[Daniel Stone]

On Tue, Sep 18, 2007 at 12:14:08AM +0930, Peter Hutterer wrote:
> 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.

Yeah, I was just explaining for the benefit of the list. :)

> >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.

Yeah, I was thinking further, and realised that nowhere did we actually
smash core pointer state.

> 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!"

True.  As I said, you just need to pick which semantics you want, and go
with them.  For core, I think the correct semantics involve not
aggregating state (no particular reason, just a gut feeling, mainly
motivated by the Ctrl-Q thing I mentioned above).  For focus groups,
this may be different.

> >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.

Makes sense.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20070917/f87da54c/attachment.pgp>