Work available for review at http://code.caurea.org/xorg/xserver/log/?h=server-side-xcb (move to a git repo at fdo?)
Current state
- Templates which generate the bindings (limited to simple requests/replies)
- Integration into configure.ac / makefiles
- DPMS extension fully ported
TODO
- Generate validations of requests (and replies?)
- Clean up error handing, helper functions (proto/common.[ch]). Look at how client-side xcb works.
- Figure out how to properly install header files which are part of the SDK.
- Support events, complex requests in the templates / xcb-gen
- Use a different prefix for the server side bindings (to avoid namespace clashes with client-side XCB). I propose XSB (X Server Bindings). This will be important in case a ddx (xnest?) decides to use libxcb.
Open Questions
01: Conditionally enable / use the XCB code
This is fairly easy to do on the configure.ac/makefile side, but would lead to many ifdef/endif in the source code. My suggestion is to always generate the source/headers and always use the defines/types from the generated headers but switch between the old, handwritten dispatch code and new, generated dispatch code. Downside of this would be that parts of the dispatch code are duplicated and would have to be kept in sync.
02: Module/driver API migration strategies
This question is related to question 01. As the headers change all the modules/drivers need to be updated. Either we require that all modules/drivers need to use the new headers by a certain version of the xserver, or we provide compat headers.
Drivers can keep using defines and type definitions from the external proto headers. Since types are the same (except the names), they are interchangeable. The drivers can also use the same xorg API functions, but need to make sure to see the correct prototype. This can be done with #ifdef/else/endif. However, that would mean maintaining two sets of prototypes, one with the old types and one with the xcb types. And as long as we keep exposing the API with the old types, we will depend on the protocol headers.
03: Ship generated files as part of the dist tarball?
It would be nice if the tarballs don't depend on xcb-proto or python. For that we'd need to generate and ship the xcb headers/source files as part of the tarball. I have no idea how to do that in the makefiles or configure.ac (or if that even is possible). Anyone?