Porting the rest of the X.Org apps to xcb

[Alan Coopersmith]

Given what I learned on the xwininfo port I took a quick pass across
the rest of the X.Org app/* modules to see what it would take to port
each to xcb.

I am *not* volunteering to do these all, just offering some insight into
which are going to be easier/harder/not possible and hoping that others
will step up to do some of these.

At least at a quick glance, I think these could be fairly straightforward
to port to XCB, though whether it's worth the effort for all of them is
debatable:

    backlight, ico, xcmsdb, xcompmgr, xdriinfo, xhost, xinit, xkill,
    xrandr, xrdb, xrefresh, xrestop, xsetroot, xshowdamage, xstdcmp,
    xvinfo, xwd, xwud

    rendercheck (Xrender extension test suite - would probably want to
    		 leave #ifdef'ed so it can still be used to test the
		 Xlib-based libXrender API)

These require support for extensions not yet ported to XCB:

    XKB: setxkbmap, xkbcomp, xkbevd, xkbprint, xkbutils, xset
    Security: xauth
    DBE: xdbedizzy
    XF86dga: xf86dga
    XF86vm: xgamma
    Xinput: xinput, xsetmode, xsetpointer

and then there's xdpyinfo, which uses all of these not yet in XCB:
    xf86vm, xf86dga, xf86misc, Xinput, dmx

These depend on libXft, and I'm not sure what to do about that in a xcb
port:

    x11perf (plus like rendercheck, we'd still want to be able to use it
    	     to test libX11 for a while)

These depend on XKeysymToString or XStringToKeysym, which last I remember
was waiting for someone to create a libxkeysym to do the mappings:

    fstobdf, xlsfonts, xmodmap

These depend on libXt and/or libXaw, which use Xlib types like Display
in their API, so a pure-xcb-port is not possible without first porting to
another toolkit (which doesn't seem worth the effort for most of these,
since there already are similar programs for other toolkits, or doesn't
make sense since they're specifically for Xt resource management):

    Xt resource tools: appres, editres, listres, viewres

    beforelight, bitmap, oclock, proxymngr, smproxy, twm
    xbiff, xcalc, xclipboard, xclock, xconsole, xditview,
    xdm, xedit, xeyes, xfd, xfindproxy, xfontsel, xgc, xload,
    xlogo, xmag, xman, xmessage, xmh, xmore, xsm, xvidtune

These are non-X client utilities that don't use libX11 at all so have no
calls to convert to xcb:

    font file utilities: bdftopcf, fonttosfnt, mkfontdir, mkfontscale
    font server utilities: fslsfonts, showfont, xfs, xfsinfo
    misc utilities: constype, iceauth, rgb, rstart, sessreg, xfwp

Special cases:

    lbxproxy - calls xtrans directly since it's a X11 proxy, plus, it's
    	     LBX, so it's just special anyway.   (Also, since Xorg no
	     longer supports LBX, not widely used anymore.)

    luit - only uses locale.aliases file from libX11, doesn't even need
    	 to link to libX11.

    mkcomposecache - helper program to build libX11's input method Compose
    	   table caches - a non-libX11 version makes no sense.

    xcursorgen - mostly uses libXcursor, uses libX11 only for
    	   XReadBitmapFileDatabitmap, never calls XOpenDisplay

    xev - mostly very simple, except for the interaction with libX11
       	input methods to display what strings would be input by key events

    xpr - only uses XInitImage from libX11

    xprop - needs better helpers for property encodings (like the discussion
    	  during the xwininfo port), otherwise should be straightforward

    xrx - Mozilla plugin

    xscope - uses xtrans directly to proxy X protocol, printing it on the
    	   way for debugging - though it would be nice if extension decoders
	   could be xcb-generated instead of handcoded

-- 
	-Alan Coopersmith-        alan.coopersmith at oracle.com
	 Oracle Solaris Platform Engineering: X Window System