X12

Contents

We are, some day, going to need to fix the protocol. This day is probably not soon, but it's also not never. So this page exists to document the limitations of the current protocol, so we can be sure to address them when X12 finally does happen.

Object model

Window borders are lame

Self-explanatory really.

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.

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.

Events are too small

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 General Events extension adds a mechanism for larger events.

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

X Generic Events 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.

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

Why X Is Not Our Ideal Window System etc.

Development/X12

X12