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).
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... 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? 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). 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. 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. 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. 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. 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). I'm not sure I like any of these options, to be honest. But I think we should talk them through. - Jim -- Jim Gettys <j...@freedesktop.org> _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg