X12
X11 was defined in the middle of the 1980's. Since then, computers have changed almost beyond recognition; the simple framebuffer model used by computers at the time has been replaced programmable graphics hardware that is both complex and powerful. Not only has graphics hardware changed, but the basic processing model has and continues to change; parallelism in core system design is becoming the norm, rather than a special case for 'large' systems.
And that's just talking about desktop systems; now there are smart phones, netbooks, tablets, and probably will shortly be other device types that this author can't imagine (else I'd be working on them...).
In short, X11 was designed for a different era of computing.
This is not to say that there's an X12 project. There isn't. But if one day there is...
Requirements for the Successor to the X11 Protocol - “X12”
This section is a discussion of the broad requirements for X12; discussion of the specific failings of X11 are addressed in later sections.
To call this subject controversial would be an understatement; there have been and continue to be many attempts to either freeze 'X11' in time or discard it completely. Clearly, this author believes this to be wrong.
What is Good about X11
Network transparency. Network transparency rocks! Run a program on a remote system and interact with it on your local terminal; write a program and not need to care whether it's going to be run on a full workstation or a dumb terminal. Some may say this is unimportant, but when one looks at the development of Windows and the evolution of RDP, it starts to look a lot more like X in terms of its features.
A Rough List of Requirements
Security designed-in from the start
Systems need to be secure. X12 needs to be designed with security in mind.
Multiple Platform Support
X12 should be designed with mobile phones, tablets, dumb terminals, netbooks and desktop workstations in mind; if it is to succeed, it must work well on all these systems.
Maintain Network Transparency
The future will be more interconnected and network-oriented, not less. Network transparency makes things easier for users and can't be considered an 'optional extra'.
Support Modern Graphics Hardware and Rendering
Programmable hardware, composition; all that good stuff. X12 needs to naturally support modern hardware in a way that allows developers to gain access to the hardware without having to completely bypass X (as happens currently).
The Framebuffer is dead, Long Live the Framebuffer
For all the talk of modern hardware, let's not forget that the framebuffer concept is still extremely useful in certain situations; killing it off completely is likely to be serious mistake.
Be as Efficient as Possible
X has always been a low-level protocol; inefficiencies here will hurt applications.
Think Parallel
This is perhaps the hardest part of the design of X12; the approach to computation and rendering is changing with a greater emphasis parallelism. X12 should be sympathetic to being implemented on massively-parallel systems, if not actively support such systems.
On the other-hand, trying too hard in this regard is likely to be serious cause of difficulties in finalising the design of the protocol; if in doubt, the designers should work to the standards of the day, rather than attempting to predict the future.
Errors, Oversights and Omissions
This section attempts to document the failings of the X protocol and rendering model. Learn from history, or be doomed to repeat it.
Object model
Windows can not be zero-sized
Color maps are non-obvious
Grabs can block too much
Popping up a menu and walking away can leave your screenlock unable to lock the screen since it won't be able to grab the pointer.
Server grabs are even worse when they lock out all other clients including those necessary for user interaction like compositing managers and accessibility helpers.
Current theory: Multiple clients can grab; when any grabs are active, only clients with grabs receive events.
Windows and Pixmaps aren't split correctly
You can't resize a pixmap in the X11 protocol, because you can't get events on things that aren't windows. Lame. Really a Window should only be an IPC name, with one or more associated pixmaps and etc.
Fine grained events
PropertyNotify is a disaster. And we probably want to be able to get events on things other than Windows.
Infeasible to change color depth with clients running
Possibly not worth fixing. However, composited by default might make it reasonable.
Rendering model
Composited by default
Probably. Note that we can more or less accomplish this within X11, but there are probably simplifications to be had by making this explicit in the protocol.
No override-redirect
Core rendering is largely useless
Wide lines bite
BackgroundNone makes security geeks cry
See ?EamonWalsh's talk from XDevConf 2008.
Borders are stupid
Which is really a special case of...
Implicit rendering is stupid
Borders and window backgrounds and the bg=None trick and backing store and saveunders and all that.
There's a speed/complexity tradeoff here, of course. Any time that implicit server rendering works, it saves you exposures and round trips. But the implicit mechanisms we have are poor fits for a composited model. Think very carefully about adding implicit rendering to the server process; it's probably a mistake.
Encoding bugs
Extension space is too small
The first 128 requests are core protocol; the remaining 128 are single-entry multiplex functions for extensions. It's sort of ridiculous to have XPolyFillArc on the same footing as GLX.
The minor opcode "convention" should be formalized and made part of the standard. The core protocol should be assigned major number zero and use minor numbers.
XIDs are too small
XIDs are 29 bits for some inexplicable lisp-related reason. Client-side allocation seems like a reasonable idea for avoiding round-trips, but the need to slice the 29-bit space into client and resource parts means we have an unpleasant tradeoff. Right now most X servers have a 256 client limit, which is uncomfortably close.
Should probably just bump this to uint32 for client ID and uint32 for resource ID.
Sequence numbers are too small
It's pretty easy to hit 16-bit sequence number wrap without getting any responses from the server, which can make interpreting later events or errors impossible. Although perhaps it would be better to introduce a SequenceWrap event sent every 64k requests than to grow the sequence numbers.
15 bit coordinate limit
Ouch. 32768 pixels at 100dpi is 8.3 meters.
64 bit, nanosecond-precision timestamps
585 years ftw. The server time should be included in every event, reply, and error. It should also be present in every request (but with the "CurrentTime" option available).
Cursor image encoding
Cursors are encoded as rectangular bitmaps, so a full-screen crosshairs would be a bitmap 4 times the size of the screen. Allowing a more flexible format, such as SVG, would be good, as well as allowing smoother scaling for screen magnifiers.
ListFontsWithInfo-style requests with multiple replies
Kill them or standardize them, preferably the former. Note that XCB-style asynchronous requests with replies make some uses of these less important.
The KeymapNotify event special-case should go away
All events provide a sequence number, except for the KeymapNotify event which wants the space for more data.
XGE by default
Events and errors are a fixed packet size to make parsing easy, but they aren't big enough to convey all the information you want. Some extensions like Xinput literally use every byte, and then some. The X Generic Events (XGE) extension adds a mechanism for larger events.
XGE should become the default, rather than fixed-size events.
CHAR2B
Kill this off. It's only used for core text, which should die.
Responses should assume less client state
Replies, and probably errors, should include the major and minor opcode of the request that triggered them, to ease debugging.
Latin-1 (ISO 8859-1)
Strings for Atom names and the like are required to be in Latin-1 encoding - should be replaced with UTF-8.
Length fields require constant conversion
All requests and replies in X11 have a length field. This is cleverly encoded as number of 32-bit words, since all packets are padded to 32-bit alignment. This annoyingly results in tons of << 2 and >> 2 conversions everywhere to get into useful byte counts for reading & writing across the sockets.
Input
Core input is useless
Xi and (at least some elements of) XKB need to be folded in to the core protocol and made mandatory.
Resource limits
We need more than 255 keycodes, and more than 4 groups. We also need a better mechanism for expressing state than the current field, which limits us to 5 buttons and 4 modifiers, or so.
Redirection should be integrated
The current deep binding of input delivery to window coordinates is garbage. The redirection mesh idea is nice but it should be the only way.
Keysym names are a mess
Come up with a vastly more coherent set of keysym names than the current scattergun approach.
Design issues
Circulation APIs in core protocol are emacs disease
These are wildly unhelpful. CirculateWindow and RotateProperties can taste the curb.
Screens are not helpful
(Screens is used in the protocol sense, with displays used in the physical output device sense.)
This is part intractably large implementation problem (of not allowing resource sharing among screens, nor screen hotplugging), and part protocol problem (screens as defined are static, and there's no expressed relationships). Pushing most of RandR down will help this, as well as rewriting core code.
Events should always go to a window
Events should have a fixed destination window field, to support the idea of events delivered to windows, not to clients directly.
Move stuff from the "random fixes" extensions into core
Decide what from XC-Misc, MIT-SUNDRY, XFree86-Misc, and XFixes needs to go in core.
Don't split or duplicate a class of requests across core and extensions
For instance, the core ForceScreenSaver and the MIT-SCREEN-SAVER extension.
Predefined atoms
ICCCM gets special pre-defined atoms, but newer standards like EWMH don't. One approach would be to identify a set of predefined atoms by the hash of the names of the atoms, allowing extensibility in which atoms to predefine in the future. The connection setup response could include a list of the atom-sets this server provides, eliminating a round-trip at startup in the common case that all the atoms a client wants are already known.
Extension initialization
With XCB we can, in principle, initialize all the extensions a client needs in two round-trips. But there aren't so many extensions in a server that we couldn't just provide the list in the connection setup reply. If that list included all the data that QueryExtension returns, that would eliminate one round-trip. If we standardize that every extension has a major and minor version number, and include those in the setup data as well, we can eliminate the other round-trip.
Race Conditions
Need a basic sync request
Need a dedicated request that just sends back an empty reply.
Implement the ICCCM suggestions
An appendix to the ICCCM lists mostly trivial improvements that would simplify the procedures set forth in that document.
Reference material
etc.