Porting the rest of the X.Org apps to xcb
Alan Coopersmith
alan.coopersmith at oracle.com
Fri Jul 16 07:19:53 PDT 2010
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
More information about the xorg-devel
mailing list