Re: dix and Xprint

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [X Forum]     [Intel Graphics]     [AMD Graphics]     [Nouveau Driver]     [XFree86]     [XFree86 Newbie]     [IETF Annouce]     [Security]     [Fontconfig]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Video for Linux]     [Linux RAID]

  Powered by Linux