Draft XI 2 protocol specification

[Peter Hutterer]

On Tue, Jan 13, 2009 at 08:44:04AM -0800, Keith Packard wrote:
> 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.

I think most clients will care about the existence of MDs, but not as much
about the actual hierarchy. That's my guess anyway, but tacking the data onto
the event isn't hard from a coding perspective if we decide to do so.

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

16.16 would be the best choice since we're limited to 16 bits anway?

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

for all events, screen coordinates are 16 (or 16.16 fixed point), all device
coordinates are in a INT32 device coordinate system. We could opt for floats
here too, but since scaling is required for device coordinates anyway,
integers should suffice.

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

widening a datatype from 8 to 32 still requires all protocol requests and
replies to be widened, and therefore "reimplemented". Or am I missing
something here?

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

There's a bit of information that could be tacked on to the events that is
quite important during event processing. Example is the SD change that causes
the DeviceChangedEvent. This just needs to be a flag but because we're
processing the on-wire event internally we don't have any room for it. So we
need special-casing for the DCE all over the place.
If we have an event struct that contains the data we'll need during event
processing we can
- pass additional data along throughout the process as we need it (daniel gave
  the example of latched/locked modifier information, and it'd be handy for
  frozen event processing too)
- change processing without having to worry about the wire format
- further clean up processing, as we don't have to typecast to the right
  events all over the place.

The downside is that this would affect all extensions and is even more typing
than the current proposal.

Cheers,
  Peter