dix and Xprint

[Drew Parsons]

On Thu, 2008-03-13 at 18:16 -0400, Adam Jackson wrote:
> On Wed, 2008-03-12 at 10:59 +1100, Drew Parsons wrote:
> > 
> > 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])
> > 
> > Then when linking Xprt, it also needs requestingClient.  The default
> > libdix.la no longer has it.  A separate libdix is needed. ...  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]), 
> 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).


Thanks for the reply (and thanks Eamon for checking ajax's ideas :) ).

It'll probably take me a little while to get the appropriate use of
XaceHookDispatch() figured out.  I might propose pushing my patches as
an interim solution to keep things building, with a mind to reverting
them later when the XaceHookDispatch() approach is sorted.  If you or
anyone else who's adept with these techniques wants to whip out a patch
in quick time, let me know so I don't push my patches.

Drew