Bug 6254

Summary:	Remove XCB dependency on proto/X11
Product:	XCB	Reporter:	Ian Osgood <iano>
Component:	Library	Assignee:	Ian Osgood <iano>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	high	CC:	jamey
Version:	unspecified
Hardware:	All
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	Patch removing proto/X11 dependency from xcb xcb.h/Xmd.h coexistance

Description Ian Osgood 2006-03-14 11:15:04 UTC

Jamey would like to remove XCB's dependency on proto/X11.  Two files are used:
 * Xmd.h for a handful of types (CARD32, etc.)
 * X.h for enumerations used by various core protocols.

Xmd.h can easily be replaced with <stdint.h> based typedefs (patch attached).

The definitions in X.h should be distributed to the various xcb-proto XML definitions.  Some are already 
taken care of:
 * core event names: KeymapNotify --> XCBKeymapNotify
 * core error codes:  Bad* --> XCB*   (is this a bug? shouldn't these be XCBBad*?)
 * create window masks: CW* --> enum XCBCW: XCBCW*

To avoid conflict with Xlib, we should likewise move other definitions to the XCB namespace (the XCB 
prefix in C). There is only one remaining X.h dependency within XCB itself:
 * xcb_auth.c:   FamilyInternet  (patch: just use 0)

There are more dependencies in xcb-util and xcb-demo. Some of the high level definitions could live in 
xcb-util header files.  Question: which constants cross the wire, and so should be in the XML files, and 
which are client-side only abstractions and thus live in header files?

Comment 1 Ian Osgood 2006-03-14 11:18:16 UTC

Created attachment 4927 [details] [review]
Patch removing proto/X11 dependency from xcb

Comment 2 Ian Osgood 2006-03-16 05:19:18 UTC

Dependencies in xcb-util and xcb-demo have been removed. Many definitions were moved to enums in 
xproto.xml to support this. The <bit> expression was added to support bitmask constants.  Will push to 
origin tonight after review.

The final step is to remove X.h from xcb.h, but that might trivially break all projects currently using XCB 
which are not under our control.  (The trivial fix is to include X.h anywhere there is breakage. The long-
term fix is to use the new xproto enums, or add a missing enum to xproto.xml.)

Comment 3 Ian Osgood 2006-03-20 16:58:34 UTC

More dependencies in xcb-util:
* test_xcb_image.c and test_xcb_image_shm.c: <X11/Xlib.h>
    looks like it's just for symbol AllPlanes used for plane_mask in XCBGetImage? moved to xcb_image.h
* keysyms.c:  #include <X11/keysymdef.h>
    is this really a dependency? can the various *keysym*.h headers be installed independently from proto/
X11?

Question: if keysym.h is kosher, then what about other collections of constants, like Xatom.h? It would be 
easier if xcb_atom.h didn't have to define these again (removing the XA_ namespace qualifier, too).

Comment 4 Ian Osgood 2006-04-30 03:01:37 UTC

Moved remainder of X.h constants to xproto.xml.

There is an issue with including both xcb.h and Xmd.h in the same files (i.e. Xlib/XCB), due to conflicting 
definitions of the core protocol types in some configurations.  Proposed patch follows, but there may be 
problems on 64-bit systems which define WORD64/LONG64.  These systems declare both INT32 and 
INT16 as int, using bitfields B32/B16 for packing shorter fields into 64-bit words.  We should identify 
which platforms have this configuration and check whether XCB is currently compatible with them.

Comment 5 Ian Osgood 2006-04-30 03:36:28 UTC

Created attachment 5523 [details] [review]
xcb.h/Xmd.h coexistance


More info: only the CRAY defines WORD64 and the B16/B32 bitfields. We should
note that XCB is not compatible with the CRAY architecture (unless we have one
in the basement for testing :)	LONG64 architectures shouldn't be a problem
(though we may have a lot of code to clean up which assumes long == int).

Comment 6 Bart Massey 2006-09-09 14:10:52 UTC

Ian finally fixed this, long ago.  There's still some twitchiness, but no one
really cares.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.