[RFC] Device hierarchy for MPX
Daniel Stone
daniel at fooishbar.org
Mon Sep 17 08:09:33 PDT 2007
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>
More information about the xorg
mailing list