dix and Xprint

Adam Jackson ajax at redhat.com
Thu Mar 13 15:16:10 PDT 2008


On Wed, 2008-03-12 at 10:59 +1100, Drew Parsons wrote:
> 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.

Both of these changes seem reasonable, but see below.

> 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).

Probably the right way to do this now is to hook yourself into the
XaceHookDispatch() call chain during XpExtensionInit(), and stash the
current client aside in a field in the XpScreenRec (or in some bit of
global server state really).

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080313/af2abb69/attachment.pgp>


More information about the xorg mailing list