This patch enables a working version of Xprt, the Xprint server, to be built. The Xprt binary was built under this patch using ./autogen.sh --prefix=/opt/xorg-modular/ --enable-xprint=yes --disable-glx --disable-dri --enable-lbx By "working" I mean that firefox can connect to it and print. The quality produced is poor since FreeType is not included with this patch. The aim of this patch is to produce a print-only server, equivalent to the Xprt produced from the Xorg 6.* code. This is controlled by -DPRINT_ONLY_SERVER, used in ./Xprint and also referenced in mi/miinitext.c. Some discussion has gone over the idea of a unified print+video server. This patch does not address that; it would need to be handled by removing -DPRINT_ONLY_SERVER from Xprint/Makefile.am and having it set conditionally in dix-config.h controlled by configure.ac. It (a unified server) would I think have to switch on LOADABLEPRINTDDX, referenced in mi/miinitext.c, as well as XPRINT to be switched on in dix/main.c (causing both InitOutput and PrinterInitOutput to be invoked). Most of this patch affects the Xprint subdirectory, but some changes were also made to cfb/Makefile.am.inc to get to compiler.h (defining ldl_u), needed by the PCL driver. Following the approach in the old imakefile system, and used here in many places, a dummy compiler.h is created in cfb*/ which #includes the actual file. This dummy file is not deleted by "make clean"; I understand this drawback applies to other instances, e.g. cfbglrop8.c, also created in cfb. This compiler.h is #included in cfbmskbits.h and is switched on by defining XFREE86. This doesn't seem so clean, but the alternative is to add #if defined(XPRINT) to cfbmskbits.h, which is a little messy, and the old build did use -DXFREE86 to include it. With regards to the autogen step, is there any way to get lbx automatically included with --enable-xprint?
Created attachment 4261 [details] [review] patch to build working modular Xprt Xprint/pcl-mono also needs to be added. It contains a single Makefile.am: xserver/xorg/Xprint/pcl-mono/Makefile.am: ################################################# noinst_LTLIBRARIES = libpcl.la PCL_DRIVER = -DXP_PCL_MONO include ../pcl/Makefile.am.inc ##################################################### (cf. the new xserver/xorg/Xprint/pcl/Makefile.am)
why does Xprint need LBX? that's totally nonintuitive.
applied, going to chase down the LBX thing though. thanks!
It may well be that Xprint doesn't "need" LBX (I don't know what LBX is myself). While trying to get a working Xprt binary, one of the problems I came up against was that client->devPrivates was NULL but was being dereferenced in xext/xprint.c::XpContextOfClient, leading to a segfault. I learnt that it was set to NULL in dix/main.c because "totalClientSize == sizeof(ClientRec)". The definition of ClientRec is in include/dixstruct.h, #included in dix/dispatch.c and has various optional parts conditional #if LBX, XCSECURITY, XAPPGROUP etc. At the same time I was using the old Xprint build (from xprint.mozdev.org) to check which -Ddefines were missing. The old build of dispatch.c used "-DLBX -DXAPPGROUP -DXCSECURITY", and put it into libdix.a, which was later linked into Xprt. My old Xprt build actually compiled dispatch.c twice (both with -DLBX), once for libdix.a, and later in xc/programs/Xserver/GL/mesa for libGLcore.a. libGLcore.a was also linked into Xprt (I haven't tested Xprint with GL in the modular build yet). So I can't say that Xprint "needs" LBX, I was just keeping the build environment as consistent as possible to what it was in the monolithic build.
*** Bug 4174 has been marked as a duplicate of this bug. ***
Apparently I filed 4174 but I don't remember, so I'm removing myself from CC.
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.