dix and Xprint

[Drew Parsons]

In commit 7c0709a736c0f3aa011de67dd2c2962585ab146e, ajax hid away the
Xprint variable requestingClient in the dix code so that it's only found
in an XPRINT environment.

Now requestingClient is only used in two files, hw/xprint/ps/PsArea.c
and PsFonts.c. In each case it's used as the argument for
XpGetPrintContext(requestingClient). 

With ajax's dix change, ps now needs XPRINT set when compiling. I
figured the simplest way to manage this is to set -DXPRINT in
XPRINT_CFLAGS (at configure.ac).  I've placed a patch patch for this in
Debian (commit 28a6719fd486d9a9cecad0b057d9ea7c59c66055 [1]), I'll
attach it for your convenience (XPRINT_CFLAGS.patch).  It gets
requestingClient defined where needed (by xprint/ps). If noone minds it,
and pending my question below about XpGetPrintContext( ), I'll push it
upstream. 

Then when linking Xprt, it also needs requestingClient.  The default
libdix.la no longer has it.  A separate libdix is needed.  It doesn't
seem fair to set -DXPRINT globally when building libdix - the other
xservers (Xorg, Xdmx etc) don't need it and it would contradict ajax's
change in the first place.  One solution could be to create symlinks
hw/xprint/dix -> dix and build a local xprint version of dix, but I
think those lists of symlinks would be messy to maintain.  The simplest
path I believe is to simply build a libXpdix.la in dix alongside
libdix.la (when XPRINT is enabled).  

I've made a patch for this in Debian
(4e2c6dbabdbbaaca213fd08edd422de15d0900cc [2]), attached for convenience
(libXpdix.patch).  I think it's minimally invasive, it won't affect
normal builds without Xprint switched on.  Because it does slightly
alter dix/Makefile.am, my Debian colleagues suggested I raise it here
for discussion before pushing upstream.

Finally, about requestingClient itself, it's only used to obtain a print
context via XpGetPrintContext(requestingClient).  Is there any other API
to get the identity of the client making a request, other than
requestingClient?  If there were, we could potentially clear out these
xprintisms from dix completely with just a handful of changes in
xprint/ps (well, there'd still be the usage in dixfont.c to think
about).

Thanks,
Drew



[1]
http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=28a6719fd486d9a9cecad0b057d9ea7c59c66055

[2]
http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=4e2c6dbabdbbaaca213fd08edd422de15d0900cc


-------------- next part --------------
An embedded message was scrubbed...
From: Drew Parsons <dparsons at debian.org>
Subject: Define XPRINT in XPRINT_CFLAGS (configure.ac)
Date: Mon, 10 Mar 2008 02:48:05 +0000 (+1100)
Size: 1860
URL: <http://lists.x.org/archives/xorg/attachments/20080312/4319fe59/attachment.mht>
-------------- next part --------------
An embedded message was scrubbed...
From: Drew Parsons <dparsons at debian.org>
Subject: Create dix/libXpdix.la for Xprint-specific build of libdix.la
Date: Mon, 10 Mar 2008 11:54:49 +0000 (+1100)
Size: 1972
URL: <http://lists.x.org/archives/xorg/attachments/20080312/4319fe59/attachment-0001.mht>