[RFC] MPX XInput Protocol extensions - detailed nits

[Peter Hutterer]

Jim Gettys wrote:
> One of the problems with Xi has been that devices are CARD8's; someday
> this may come back to haunt us. The scenario where it might is in a big
> shared space, with many devices/person using this shared space.  This
> has always bugged me... I don't know if it is worth worrying about now,
> however, as the base Xi will need serious work anyway.  There isn't any
> problem at the library interface level, at least, as the C type used is
> int, as I remember, for device ID's.

yeah. I think a good idea might be to sneak MPX in with the current 
version, wait for feedback and then when we know what works and what 
doesn't, do a real API break to XI2.

With a bit of effort, we might be able to sort out touchscreen support 
by then and add it as a standard to XI2.

> I think there needs to be some glossary and/or architectural description
> work: definitions new to X appearing in this document 
> 	o HAL daemon
> 	o "floating" device
> 	o "master" vs. "slave" devices, and "floating" versions of them.
> 	o "attachment" of devices
> 	o device hierarchy

ACK.

> 	o device names

device names are already part of XI somewhere. I'll try to cross-reference.

> Section 1:
> 	It isn't clear if the extension is an extension of the Input Extension,
> and if so, that it ups the version of the Xi extension.

I'll add this to the document.
Short answer, it ups XI but is an extension to XI, the remainder of the 
XI remains the same.

> Section 1.1:
> 
> "floating slave device" never defined.

will be added.


> QueryDevicePointer Reply
> 	Should it contain the device id to for convenience of streaming
> 	applications where correlating the device ID in the reply with
> 	the request may be painful?

done. will find its way upstream when I push next.

> Section 1.5
> 	pointer names and keyboard names get appended with " pointer" and "
> keyboard".  The space is hardly visible and may be regarded as a typo.
> I also wonder strongly if space as a separator is wise: I suspect it
> will cause trouble in some scripting languages where space is used as a
> separator.  I'd recommend using an "_" as the separator instead.

Since 1.4, our two core devices are "Virtual core pointer" and "Virtual 
core keyboard". So scripting languages would already break anyway.


Thanks for the review!


Cheers,
   Peter