Xprt does not play well with D-BUS
daniel at fooishbar.org
Mon May 5 02:52:23 PDT 2008
On Mon, May 05, 2008 at 01:04:33PM +1000, Drew Parsons wrote:
> 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
> 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.
Since we're already this far diverged, and everything we do to the DIX
these days seems to just break Xprint rather than generate any benefit
whatsoever, have you thought about forking the codebase, deleting all
the unnecessary input/etc code, getting rid of the workarounds, and
actually having something usable?
Seriously, this is getting a bit out of hand.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the xorg