Draft XI 2 protocol specification

[Keith Packard]

On Tue, 2009-01-13 at 22:37 +1000, Peter Hutterer wrote:

> The idea here was to be able to filter easily. I expect that many clients
> won't care much about reattachment, but they would care about new MDs.
> Having this information may prove useful. As for the deviceids - same idea.

I guess this kinda depends on how we expect to implement things on the
client side. If we want to mirror the server device hierarchy in the
client library, it might be easier to just take the 'something changed'
event and reconstruct the whole client state than attempt to patch
things with incremental data. Dunno.

> Not having this state makes us prone for race conditions. Class changes are
> expected to happen often, and a different XDCE may be generated while the
> request is waiting to be processed. In this case, the client cannot process
> events with the correct axis information.
> At least for XDCE, it is mandatory that the new information is part of the
> event. XDHCE is less frequent, justifying the query.

Less frequent doesn't mean non-racy though; we've had this problem with
X key mapping forever, and worse now that keymap notify events are
happening more often.

> > Send these in floating point so we capture sub-pixel positions
> > trivially?
> 
> ok.

Or perhaps fixed point? That eliminates problems with different
precision in different parts of the screen.

> > Uh. What about absolute devices? Can those send XRelativeMotionEvents?
> > If so, this seems more like an XIDeviceRawEvent.
> > (same comments about last_* apply here)
> 
> Good point. I will revise.

Oh, are these INT32 here (for relative devices)? And, if so, do we use
INT32 in the non-raw event for consistency?

> I don't have an answer for all that yet and it strikes me as one of those
> things that just need testing to see what works best.

Ok, sounds like we need to figure out how grabs work for devices which
are both pointer and keyboard then. I can't, frankly, think of a better
way than having them appear as two logical SDs. Which leaves us with
slightly weird event delivery, but that seems better than complicated
grab semantics?

> The main point of input classes in XI2 would be to specifiy capabilities in
> detail. Some of the input classes aren't particularly great for that so they
> could do with a redesign. Example here is the ValuatorInfo that only allows
> for a single state across all axes.

With the above discussion, it seems like SDs are either 'pointer' or
'keyboard' devices, and beyond that, they've got a collection of keys or
buttons/axes. Making sure the per-axis information isn't constrained by
some global device information seems like a requirement here.

> Current deviceids are CARD8, so CARD32 would still require a reimplementation.
> Now, at least for XI2 this may not be a problem as we could decide the upper
> 24 bit as "reserved for future use" and continue to only use 8 bits in
> requests and replies - until those are reimplemented at a later point in time.

I guess I don't see any huge 're-implementation' here -- you're just
widening a data type. It may cause a flag-day for input devices, but
we've been there before.

> 16 bit ids were chosen mainly because the fit nicely after the event type in
> the GenericEvent. Before we run out of 2^16 deviceids per X server, we run
> into other issues anyway.

Ok, seems fairly reasonable.

> XI valuators are already 32 bits, and we probably shouldn't scale down.
> we accept integer-only format in the valuator

Right, so we use 16.16 fixed point for their screen coordinates then and
get plenty of sub-pixel position.

> Another thing discussed briefly was the use of a separate format internal to
> the server, i.e. the XI events are assembled at delivery time, not carried
> through the server. This is an implementation detail though and shouldn't be
> too hard to support.

Hmm. With the generic event stuff fixing the list-of-events disaster, is
there some other format you'd prefer? Adding a gratuitous data type
doesn't seem like a winning plan here.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20090113/908b731f/attachment.pgp>