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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list xorg@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/xorg