[RFC] XI2 draft protocol specification (v 0.1)

[Peter Hutterer]

On Sun, Feb 22, 2009 at 12:28:23PM -0500, Jim Gettys wrote:
> Here are some substantive issues:
> 
> 1) I wonder how we can extend XI2 to deal with multiuser displays (with
> some sort of security between users), when we have enough experience to
> work out the details.  Do we distinguish via the deviceid?  If so, is 16
> bits of deviceid enough?  (allowing for 256 users of 256 devices, as a
> possibility...).  Or is a separate user field for each device better? A
> device might someday be as simple minded as a playing piece on a
> chessboard (with sensors, for example).

I don't think we should have the notion of a "user" in the protocol. X is (or
should be) an abstraction layer for input devices, the notion of a user (in
regards to input devices) is too context-sensitive to build into the protocol.

Get the DE to label the devices through properties, and then apps to listen to
these properties correctly, similar to EMWH. The big advantage of this is that
a property-based protocol is easier to test and easier to modify than the wire
protocol.

> 2) if there are a lot of devices, coming and going possibly/probably
> even in the same session, it isn't clear that notifying clients of their
> (temporary) absence is desirable.  I think the spec should be written
> allow a device to be absent and reappear without notification (within a
> session); but a new device appearing in a session notify interested
> clients.  With wireless devices, absence will occur with regularity...

In many cases we don't know if a device that comes back is the same as the one
before, so we simply have to assume that a device that disappears is gone for
good.
OTOH, if the kernel can keep a device alive until it comes back from sleep
then we don't see the device disappear anyway, so this is a nonissue.
Ideally, this is done with DeviceEnabled/Disabled to notify the client that a
device is still present but does not send events. This is an implementation
detail though.

> The spec says: "Device IDs may get re-used when a device 
>         is removed."; maybe better that the server somehow guarantee 
> that clients be notified if the device ID is being reclaimed?

Well, we send a notification that the device <N> has disappeared and all
associations in the client with this device must be removed.  Likewise, any
new device must be treated as a new device, regardless of its ID. I'm not sure
if an extra notification of a reclaimed ID would add any information to that.
 
> 3) XIQueryDevices has limitations.
> 
> I worry in particular of N client toolkits getting notified of a new
> device.  How do we limit notification traffic?  Should you be able to
> limit XQueryDevices to list devices of a given user ID? (see above).

XIQueryDevices allows to query for one device, all master devices and all
devices. The reason behind this is simply that I think these are the most
common use-cases.
The events/requests themselves are fairly small (a few hundred bytes, give or
take). Devices aren't added and removed that often, so this cost is
IMO negligible. 

> 4) Extensibility of events.
> 
> I'm very concerned about how we can add new device types without having
> to update the X server and client; the network effects of deployment get
> to be a huge PITA.  We got stuck on fonts for > 15 years due to this
> problem.

Please define "device types", it's ambiguous and I'm really not sure what it
means.
 
> We have a number of ways forward I can see:
>    o do what we're doing now.  But even with named AxesClasses,
> ButtonClasses and DeviceClasses I'm worried.  Here's why: Interning
> atoms require a round trip, and won't we end up with way too many types?
> And do we really want to be a registry for such names?  Looking at the
> USB specs, there are *tons* of devices and various types.  We thought
> we'd avoid this in the early X11 design by the "predefined atoms" stuff,
> but it didn't work out well in the end; it would have been better to
> just use strings and send them everywhere in the protocol.  The registry
> headache is not to be undertaken lightly.  Similarly, we're mostly out
> of the keysym business by punting most of it to the Unicode consortium.

In regards to the atom worries:
Atoms are only used for axis/button labelling. Axis and button labelling is
probably the most useful thing for real-world applications. Having it in the
protocol guarantees that XI apps are actually consistent since they don't have
to guess what an axis/button stands for.  Whether these are atoms or strings
is a matter of taste, I personally like atoms because they're much easier to
deal with in the server.  Strings and atoms suffer from the same problem in
the end - if a client doesn't know what it means, then you need to update the
client. Having the registry in the server at least guarantees that all devices
have the same labelling.
Otherwise we end up having labels like "Evdev Pressure", "Mouse Z Pressure"
and "Foobar Pr3ssur3" label, all referring to the same thing.

In regards to device types: (my interpretation of types, anyway)
We really care about keys, axes, and buttons (KAB). Adding more classes (for
touch devices, accelerometers, etc.) is trivial. If you want a device to do
something more compliciated than KAB, you need support for it in the server
and in the client.
Otherwise, it all has to boil down to KAB.

The real worry I have about device types is the pointer/keyboard distinction
in master devices. It's stupid, only required because of the core protocol and
I'll work hard to get rid of that.

>    o We can use the USB descriptor stuff and send the devices bytes to
> the clients for arbitrary devices and leave it to the client to parse
> the bytes.  This keeps us out of the registry and data definition
> business; but it is ugly.  The USB stuff is decently documented.

But we still need to know in the server what the device does. So it's down to
KAB and whatever else we've added to the server since then.

>    o we can say "it's not our problem" and adopt the /dev/input protocol
> for transferring data; but as I've discovered looking into multitouch
> devices, that just moves the problem to linux kernel land.  And
> deployment will be limited to the rate of evolution of the Linux USB
> driver and still requiring updating the X driver too. Not sure what
> other platforms might think as well.

If we want to do picking, we have to understand the protocol in the server. At
which point you need to bump the server for each device that uses a new
protocol. So you're  

>    o we could define a mapping between USB descriptors and XML events,
> and send all this as XML.  This isn't entirely crazy. In fact, most
> events end up as XML inside browsers anyway.  It is very extensible.
> There are binary versions of XML if we wanted to go this way; though
> care on design to avoid verbosity (and transmitting a data descriptor
> first (or on device change) and just the data is very possible).

XML is merely a container format. It doesn't solve our actual problem - what
information to send to the client.

In regards to extensibility: all the formats in the spec are defined as
explicitly extensible. So if needed, we can tack on additional information in
a ButtonClass in a later revision and clients are required to pull it off the
wire (but ignore the data). Same with events. There's an important bit
missing? Make the event longer in XI 2.n+1 and tack it on to the event.

This gives us the chance of getting a bit of XI2 working first, without
running the risk of overspecifying everything. I'd rather have something that
is too simple but works well enough for some cases, than something that's
overspecified and fails for all cases or is ignored.

We're in pretty unchartered territory, with much of the UI needing to change
anyway to accommodate for all this. Once the UI changes, the information need
from the server is likely to change too.

Cheers,
  Peter