X Hotplug Proposal
Table of Contents
Overview
This is a proposal for converting the entire X server over to a hotplug-capable configuration mechanism. This effort expects to occur on similiar time scales as the modular code effort and the X on GL effort. The proposal is designed around a non-root X server not being possible in the near future.
Phases
Phase 1: Design
EgbertEich suggested using a different IPC method than the X protocol. This immediately solves the security problems. Possibilities include dbus or another named socket (/tmp/.X11-unix/X0.conf ?).
The currently evolving plan is to have an external device daemon that informs the server of available devices. This external daemon can help with system level access control and negotiation among multiple servers. This daemon would handle all direct communications to the OS-dependent hotplug system.
The list of input devices on the server is not simply be a list of all local devices. It should be possible to keep devices 'installed' in the X device list, even if that device gets unplugged. Newly discovered local devices should generally not be automatically installed into the X Device List. One approach is to have a Device Manager, somewhat like the Window Manager, which handles every addition or removal to the X device list.
Questions
- Would the named socket cause problems with cygwin? (or other archs?)
- Is dbus an acceptable dependency?
- The configuration client would probably expose itself on dbus if we want DEs to be able to fiddle with policy. (This would be instead of the DEs writing their own configuration client, since with a root X server that's a security problem), so a dbus dependancy wouldn't be necessary in Xorg even if we want to control Xorg from across dbus.
Phase 2: XINPUT
The protocol will expose only the device_presence_notify event. The AddDevice and RemoveDevice commands will be exposed on the new configuration IPC mechanism (chosen above).
Backwards compatibility with newly broken code can be solved by exposing a single mouse and single keyboard to any client that doesn't request a new enough version of the XINPUT extension. These devices should be horrendously generic and barely reflect the hardware.
Essentially, if we go the "virtual device" route, only these devices would be exposed to old clients (since they are never added or removed).
Questions
- Compatibility will be lost for clients that want to use special features of input devices. (Are there any common cases other than drawing pads under the gimp? What else specifically uses extension devices?) I don't see an alternative: either we break code or we break features. I prefer to broken features to crashing code. (Are the problems with gtk crashing bugs?)
- XInputHotplug suggests remote input devices may be a problem. Is there any reason to natively support these rather than implement them as a driver?
- Should the core pointer and keyboard continue to exist? Should they be converted into "dummy" devices instead and have all new input devices SendCoreEvents by default? (XOrgInputDriverSpec suggest the dummy pointer (or virtual pointer) method)
- Should multiple cursor support be native, or should things like the MERL projector table expose numerous devices and have the client monitor each one individually? Perhaps clients could request that multiple, specific devices become pointers (locked into that client's window, so as not to confuse other clients)?
Further work
There are a number of issues raised on the XInputHotplug page under the "XInput Protocol" and "Other Stuff" sections about driver ugliness and protocol problems. Also XOrgInputDriverSpec and XInputSpec. These changes to the protocol would probably go in along with the device event, so phase 2 depends on this work as well.
Phase 3: General
Move all configuration into the configuration client. The parser for /etc/X11/XOrgConfig would be moved into its own client and out of the X server. The client can now control everything about the X server, including displays.
Questions
- Presumably, opening sockets for regular clients to connect would be a command issued by the configuration client. Should we just error if the command is issued before the X server has a full configuration, or should we begin supporting a partial configuration?
- Are all the event notifications we need in order to support display-hotplug present? Would adding another head be any different than a "mode change" from 800x600 to 1600x600 to the client? Would any client even care if we suddenly start rendering to a projector as well as an lcd? (other than the configuration client)
Phase 4: Completion
Presumably at the same time XOrg begins using OpenGL, mode changing will be freed up. This responsibility could be moved out of the X server and into the configuration client, and only framebuffer configuration would be sent to the X server. See questions belows.
At this point, XOrgConfig is just another configuration client. Any internal assumptions about configuration format can be changed without external compatibility problems (just change the client to send information in the new format). (except for binary drivers? If X on GL happens, would nvidia or ati even have a binary driver for xorg anymore?)
After this phase, external configuration clients could be encouraged. Prior to this, maintaining backwards compatibility for external clients would mean we wouldn't gain anything by making the client do something because the server would still have to be able to do it, just in case. Therefore, we don't care about compatibility until this point.
Questions
- The mode selection part is debatable. I think it would be better for it to seem to the configuration client that the X server still does mode selection, even if that is moved into a shared library outside of the X server (mesa?). -- ?TedKaminski - 22 Jan 2005