Xprt does not play well with D-BUS

[Drew Parsons]

Currently Xprt spins at 95% cpu usage (code from master or xserver 1.4).
Xprt from xserver 1.3 was still behaving OK.

Xprt seems to be spinning in the dispatch() loop in dix/dispatch.c.  As
far as I can tell, WaitForSomething() is returning too quickly, not
waiting in the expected manner.

The problem disappears when dbus is disabled (--disable-dbus).   I
presume dbus events must be triggering off WaitForSomething().

That means the bug came in with the input-hotplug developments, which
landed in xserver 1.4.  I've traced the problem at least as far back as
commit cf7ca9d09cba14d107152a5179de38e5ef7bd784 (24 Jan 2007), but had
trouble testing further back due to other build problems.

As far as I'm aware Xprint has no actual need for dbus. At least, it's
not doing anything with it at the moment. NewInputDeviceRequest( ) and
other functions in xprint/ddxInit.c are just dummy functions (perhaps
dbus could be leveraged to instruct Xprint to update its list of
printers, but that's not being done at the moment).

I can see two alternate workarounds, both simple and both emulating the
disabling of dbus within Xprint.

1) add dummy functions config_init() and config_fini() to
xprint/ddxInit.c and remove CONFIG_LIB  from XPRINT_LIBS in
configure.ac. Then I think the Xprt build will ignore dbus (so long as
it never accesses XORG_CORE_LIBS).

This is consistent with other Input changes to xprint/ddxInit.c (other
dummy functions are already placed there).

2)  Use
#ifndef XPRINT
	config_init()
#endif
at l.298 of dix/main.c, and similarly for config_fini() at l.452.

Since a separate libdix (libXpdix.a) is already built for Xprt thanks
to commit 966ae1781f3ca563e15a9a1b8cab6fab94e07fe9, this will have the
effect of disabling dbus for Xprint only.



Please give me feedback on which alternative patch you would prefer, or let
me know if there is a better approach still.  I'm cc:ing Daniel as the
chief author of the input-hotplug changes, in case he knows of a better
way of fixing the Xprt 95% cpu usage.

Drew


p.s. dmx seems to have been having similar build problems as xprint
over the last year or so. I'm not sure if similar code adjustments need
to be made for dmx as well, as I don't use Xdmx.