Tasks requiring documentation as a product should have that documentation placed in the wiki so that other contributors can learn from it.

/!\ Now that XCB is official, we should transition the to-do list to the freedesktop gitlab issues database.

Please don't hesitate to add new items or add detail to items in Bugzilla. You would be wise to notify the mailing list if the item is significant, too.

Don't forget to ask for help on the mailing list if you get stuck.

Getting started

If you're not sure where to start in learning about XCB, you might try these steps. Documenting your progress for others coming this way would be a great contribution too.

• Check out and build the Xlib source.
• Check out and build the XCB sources.
• Understand and document the DPMS extension implementation. Re-implementing it straight from the original extension documentation would be a good way to accomplish this. The XmlXcb documentation should be sufficient to do this.

With that experience, the easiest thing you can do to help our efforts is to implement some extension that's currently unsupported by XCB.

If you are familiar with Xlib or the X protocol, you might try porting some existing Xlib applications to XCB, or writing new applications. See the page XcbPorting for pointers.

Tasks

Tasks are ranked by priority:

• {1} High priority
• {2} Medium priority
• {3} Low priority
• {3} {3} Very low priority

Tests and Demos

{1} Now that XCB has released version 1.0 and promised API compatibility, merge all XCB ports of standard X utilities back into their upstream repositories (perhaps on a branch at first). Make sure to remove the use of xcb-util first, though.

These specific features have been proposed as targets for simple test apps.

• {2} shape extension (port oclock?)
• {3} selections: clipboard server?
• {3} ICCCM (see xcb-wm below])

{3} Porting the standard xapps to XCB would give us some nice, simple demos. There's a nearly feature-complete clone of xdpyinfo among the XCB test apps already; more would be cool.

{3} Porting xcompmgr would provide an excellent test of the ?XFIXES, ?Composite, and ?DAMAGE protocol descriptions. It could also be a useful demo for the xcb-wm bits.

{3} {3} Make DPMS demo have full xset dpms functionality.

{3} {3} For Xlib with counting mutexes, test the relative performance of UNIX98 recursive mutexes versus POSIX fast mutexes. The impact is expected to be nil, but it would be nice to be able to say so with certainty.

XCB

This list might be roughly in order of importance.

• XCB is missing some of the convenience functionality that Xlib layers atop the protocol. (Provide separate libraries that simplify the interface while providing missing functionality? )
  • {2} Atom cache (?JameySharp)
• Error detection and handling in XCB is not significantly worse than in Xlib, but it has a different set of problems. These need to be better addressed.
  • {2} Connection setup errors should be handled better.
• {2} Document XCB internal APIs.
• {2} Implement an XML metalanguage mechanism for requests and replies to declare enumerated and bitfield types, with hidden naming convention. X.h should be refactored into xcb.m4 using this mechanism. Existing XCBENUMs probably need to be refactored with it too.
• {2} Figure out and implement a protocol versioning scheme.
• {3} Port libGL to XCB. (Jeremy Kolb)
• {3} Some existing toolkit should be ported to XCB. Qt and Gtk+ are the obvious targets. The FLTK people might be more receptive, though, given their concentration on lightweight performance.
• {3} More cases where padding can be automatically generated should be identified and implemented.

Xlib on XCB

• {1} Test Xlib/XCB on as many platforms and with as many applications as we can find.

Other projects

xcb-wm: Window manager toolkit

Encapsulate ICCCM, window reparenting and event capture, and anything else that seems appropriate, in one or more libraries. It should be able to cooperate with other libraries; Cairo comes to mind. Perhaps COMPOSITE extension helpers would be useful too, so it can support compositing managers as well.

A prototype implementation is available in the xcb-util module; more discussion is on the Using XCB page.

Alternate targets

The XCB protocol descriptions are largely target-language independent. There are some additional potential uses for the protocol descriptions that an XSLT hacker could try implementing. The process of implementing these will reveal limits in XmlXcb, for which it should be extended.

xcb-server

XCB: not just for clients any more!

Just as xcb handles the details of the protocol on client side, the server side protocol implementation could be auto-generated from the same protocol descriptions, with many of the same benefits: extension implementers can focus on making real contributions to X rather than writing protocol implementations, and the server can be made smaller and more reliable.

A significant chunk of the time spent implementing extensions in the X server currently goes to typing byte-swapping code, which is often poorly tested and rarely exercised. There is sufficient information in the protocol description to infer which bytes should be swapped, and xcb-server would be able to generate that code.

Better yet, smaller code can be generated easily than can be reliably produced by hand. ?KeithPackard suggested a printf-style description of the bytes that should be swapped, and said that when he has tried this in the past the overall code size was smaller, but that the format strings were too difficult to maintain by hand.

xcb-doc

Most of the protocol descriptions presently in XCB were generated by reading protocol documentation and hand-translating it to our description language. Now it would be nice to be able to go the other way, instantly generating complete documentation for the core protocol and all extensions implemented for XCB, and perhaps targeting more convenient documentation formats like !LaTeX.

?AndyHowe has a "pre-alpha" implementation. If you ask him a second time, he'll tell you it's "pre-pre-alpha".

Macros like ?COMMENT were intended to be read by this, but largely fail to be useful. We need a better set of macros that cover the natural sorts of human-readable documentation, and those macros need to clearly associate with the protocol elements that they describe.

Computing the number of bytes each field occupies in the binary protocol requires some data that doesn't currently appear in any of our protocol descriptions. Recording the size of CARD*, INT*, BOOL, BYTE, etc. should enable this, since all the other types are composed from those.

With the merge of XmlXcb, this could now be accomplished by integrating part or all of some existing XML documentation format into the XML-XCB data format.

xcb-pretty

Sometimes applications want to print various parts of the X protocol in human-readable form. Error handlers and applications like the X Event Viewer (xev) and xscope come to mind. For these applications, it would be nice to auto-generate the protocol pretty-printer code.

?JoshTriplett is currently working on an X protocol dissector (Xamine) based on the XmlXcb protocol descriptions.

XCB for other languages

Enabling clients written in languages other than C to take advantage of XCB's features would be great. That might mean generating simple bindings to the C code, or perhaps generating native code.

Note that while the protocol layer could be native, the transport layer should probably be that of the XCB C library, so that languages with the ability to link with C code can call XCB on the same connection from both C and the other language.

Obvious languages to target include:

• Haskell: lazy evaluation works well to hide latency, and it is convenient to garbage-collect replies
• nickle
• Java
• perl
• python
• Ruby

Completed Tasks