From a13b75f056f9f9efcf6ecb8610b40ddbbb2bbb69 Mon Sep 17 00:00:00 2001 From: marha Date: Wed, 19 Jan 2011 17:29:52 +0000 Subject: xserver pixman mesa git update 19 jan 2011 --- xorg-server/hw/xnest/Makefile.am | 26 +-- xorg-server/hw/xnest/Xnest.man.pre | 428 ----------------------------------- xorg-server/hw/xnest/man/Makefile.am | 2 + xorg-server/hw/xnest/man/Xnest.man | 428 +++++++++++++++++++++++++++++++++++ 4 files changed, 433 insertions(+), 451 deletions(-) delete mode 100644 xorg-server/hw/xnest/Xnest.man.pre create mode 100644 xorg-server/hw/xnest/man/Makefile.am create mode 100644 xorg-server/hw/xnest/man/Xnest.man (limited to 'xorg-server/hw/xnest') diff --git a/xorg-server/hw/xnest/Makefile.am b/xorg-server/hw/xnest/Makefile.am index 666a0f0e6..c395b4dae 100644 --- a/xorg-server/hw/xnest/Makefile.am +++ b/xorg-server/hw/xnest/Makefile.am @@ -1,3 +1,5 @@ +SUBDIRS = man + bin_PROGRAMS = Xnest noinst_LIBRARIES = libfbcmap.a @@ -59,34 +61,12 @@ Xnest_LDADD = $(XNEST_LIBS) $(XNEST_SYS_LIBS) $(XSERVER_SYS_LIBS) Xnest_LDFLAGS = $(LD_EXPORT_SYMBOLS_FLAG) EXTRA_DIST = icon \ - screensaver \ - Xnest.man.pre + screensaver # -UDPMSExtension for miinitext? can't put into # OS_DEFINES??? # EXT_DEFINES??? # ICONFIGFILES -- SpecialCObjectRule -# Man page -include $(top_srcdir)/cpprules.in - -appmandir = $(APP_MAN_DIR) - -appman_PRE = Xnest.man -appman_DATA = $(appman_PRE:man=@APP_MAN_SUFFIX@) - -EXTRAMANDEFS = \ - -D__XCONFIGFILE__=$(__XCONFIGFILE__) \ - -D__XSERVERNAME__=$(XSERVERNAME) - -BUILT_SOURCES = $(appman_PRE) -CLEANFILES = $(appman_PRE) $(appman_DATA) - -SUFFIXES += .$(APP_MAN_SUFFIX) .man - -.man.$(APP_MAN_SUFFIX): - -$(AM_V_at)rm -f $@ - $(AM_V_at)$(LN_S) $< $@ - relink: $(AM_V_at)rm -f Xnest$(EXEEXT) && $(MAKE) Xnest$(EXEEXT) diff --git a/xorg-server/hw/xnest/Xnest.man.pre b/xorg-server/hw/xnest/Xnest.man.pre deleted file mode 100644 index 024d88e82..000000000 --- a/xorg-server/hw/xnest/Xnest.man.pre +++ /dev/null @@ -1,428 +0,0 @@ -.\" $Xorg: Xnest.man,v 1.3 2000/08/17 19:53:28 cpqbld Exp $ -.\" Copyright (c) 1993, 1994 X Consortium -.\" -.\" Permission is hereby granted, free of charge, to any person obtaining -.\" a copy of this software and associated documentation files (the -.\" "Software"), to deal in the Software without restriction, including -.\" without limitation the rights to use, copy, modify, merge, publish, -.\" distribute, sublicense, and/or sell copies of the Software, and to -.\" permit persons to whom the Software is furnished to do so, subject to -.\" the following conditions: -.\" -.\" The above copyright notice and this permission notice shall be included -.\" in all copies or substantial portions of the Software. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS -.\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF -.\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -.\" IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR -.\" OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, -.\" ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR -.\" OTHER DEALINGS IN THE SOFTWARE. -.\" -.\" Except as contained in this notice, the name of the X Consortium shall -.\" not be used in advertising or otherwise to promote the sale, use or -.\" other dealings in this Software without prior written authorization -.\" from the X Consortium. -.\" -.\" $XFree86: xc/programs/Xserver/hw/xnest/Xnest.man,v 1.6 2001/01/27 18:21:00 dawes Exp $ -.\" -.TH Xnest __appmansuffix__ __xorgversion__ -.SH NAME -Xnest \- a nested X server -.SH SYNOPSIS -.B Xnest -[ -.I options -] -.SH DESCRIPTION -.B Xnest -is both an X client and an X server. -.B Xnest -is a client of the real server which manages windows and graphics requests on -its behalf. -.B Xnest -is a server to its own clients. -.B Xnest -manages windows and graphics requests on their behalf. -To these clients, -.B Xnest -appears to be a conventional server. -.SH OPTIONS -.B Xnest -supports all standard options of the sample server implementation. -For more details, please see -.BR Xserver (__appmansuffix__). -The following additional arguments are supported as well. -.TP -.BI "\-display " string -This option specifies the display name of the real server that -.B Xnest -should try to connect to. -If it is not provided on the command line, -.B Xnest -will read the -.I DISPLAY -environment variable in order to find out this information. -.TP -.B \-sync -This option tells -.B Xnest -to synchronize its window and graphics operations with the real server. -This is a useful option for debugging, but it will slow down -.BR Xnest 's -performance considerably. -It should not be used unless absolutely necessary. -.TP -.B \-full -This option tells -.B Xnest -to utilize full regeneration of real server objects and reopen a new connection -to the real server each time the nested server regenerates. -The sample server implementation regenerates all objects in the server when the -last client of this server terminates. -When this happens, -.B Xnest -by default maintains the same top-level window and the same real server -connection in each new generation. -If the user selects full regeneration, even the top-level window and the -connection to the real server will be regenerated for each server generation. -.TP -.BI "\-class " string -This option specifies the default visual class of the nested server. -It is similar to the -.B \-cc -option from the set of standard options except that it will accept a string -rather than a number for the visual class specification. -The -.I string -must be one of the following six values: -.BR StaticGray , -.BR GrayScale , -.BR StaticColor , -.BR PseudoColor , -.BR TrueColor , -or -.BR DirectColor . -If both the -.B \-class -and -.B \-cc -options are specified, the last instance of either option takes precedence. -The class of the default visual of the nested server need not be the same as the -class of the default visual of the real server, but it must be supported by the -real server. -Use -.BR xdpyinfo (__appmansuffix__) -to obtain a list of supported visual classes on the real server before starting -.BR Xnest . -If the user chooses a static class, all the colors in the default color map will -be preallocated. -If the user chooses a dynamic class, colors in the default color map will be -available to individual clients for allocation. -.TP -.BI "\-depth " int -This option specifies the default visual depth of the nested server. -The depth of the default visual of the nested server need not be the same as the -depth of the default visual of the real server, but it must be supported by the -real server. -Use -.BR xdpyinfo (__appmansuffix__) -to obtain a list of supported visual depths on the real server before starting -.BR Xnest . -.TP -.B \-sss -This option tells -.B Xnest -to use the software screen saver. -By default, -.B Xnest -will use the screen saver that corresponds to the hardware screen saver in the -real server. -Of course, even this screen saver is software-generated since -.B Xnest -does not control any actual hardware. -However, it is treated as a hardware screen saver within the sample server code. -.TP -.B \-geometry \fIW\fBx\fIH\fB+\fIX\fB+\fIY\fP -This option specifies the geometry parameters for the top-level -.B Xnest -window. -See \(lqGEOMETRY SPECIFICATIONS\(rq in -.BR X (__miscmansuffix__) -for a discusson of this option's syntax. -This window corresponds to the root window of the nested server. -The width -.I W -and height -.I H -specified with this option will be the maximum width and height of each -top-level -.B Xnest -window. -.B Xnest -will allow the user to make any top-level window smaller, but it will not -actually change the size of the nested server root window. -.B Xnest -does not yet support the RANDR extension for resizing, rotation, and reflection -of the root window. -If this option is not specified, -.B Xnest -will choose -.I W -and -.I H -to be 3/4ths the dimensions of the root window of the real server. -.TP -.BI "\-bw " int -This option specifies the border width of the top-level -.B Xnest -window. -The integer parameter -.I int -must be positive. -The default border width is 1. -.TP -.BI "\-name " string -This option specifies the name of the top-level -.B Xnest -window as -.IR string . -The default value is the program name. -.TP -.BI "\-scrns " int -This option specifies the number of screens to create in the nested server. -For each screen, -.B Xnest -will create a separate top-level window. -Each screen is referenced by the number after the dot in the client display name -specification. -For example, -.B xterm \-display :1.1 -will open an -.BR xterm (__appmansuffix__) -client in the nested server with the display number -.B :1 -on the second screen. -The number of screens is limited by the hard-coded constant in the server sample -code, which is usually 3. -.TP -.B \-install -This option tells -.B Xnest -to do its own color map installation by bypassing the real window manager. -For it to work properly, the user will probably have to temporarily quit the -real window manager. -By default, -.B Xnest -will keep the nested client window whose color map should be installed in the -real server in the -.I WM_COLORMAP_WINDOWS -property of the top-level -.B Xnest -window. -If this color map is of the same visual type as the root window of the nested -server, -.B Xnest -will associate this color map with the top-level -.B Xnest -window as well. -Since this does not have to be the case, window managers should look primarily -at the -.I WM_COLORMAP_WINDOWS -property rather than the color map associated with the top-level -.B Xnest -window. -.\" Is the following still true? This sentence is several years old. -Unfortunately, window managers are not very good at doing that yet so this -option might come in handy. -.TP -.BI "\-parent " window_id -This option tells -.B Xnest -to use -.I window_id -as the root window instead of creating a window. -.\" XRX is dead, dead, dead. -.\" This option is used by the xrx xnestplugin. -.SH "EXTENDED DESCRIPTION" -Starting up -.B Xnest -is just as simple as starting up -.BR xclock (__appmansuffix__) -from a terminal emulator. -If a user wishes to run -.B Xnest -on the same -workstation as the real server, it is important that the nested server is given -its own listening socket address. -Therefore, if there is a server already running on the user's workstation, -.B Xnest -will have to be started up with a new display number. -Since there is usually no more than one server running on a workstation, -specifying -.RB \(oq "Xnest :1" \(cq -on the command line will be sufficient for most users. -For each server running on the workstation, the display number needs to be -incremented by one. -Thus, if you wish to start another -.BR Xnest , -you will need to type -.RB \(oq "Xnest :2" \(cq -on the command line. -.PP -To run clients in the nested server, each client needs to be given the same -display number as the nested server. -For example, -.RB \(oq "xterm \-display :1" \(cq -will start up an -.B xterm -process in the first nested server -and -.RB \(oq "xterm \-display :2" \(cq -will start an -.B xterm -in the second nested server from the example above. -Additional clients can be started from these -.BR xterm s -in each nested server. -.SS "Xnest as a client" -.B Xnest -behaves and looks to the real server and other real clients as another real -client. -It is a rather demanding client, however, since almost any window or graphics -request from a nested client will result in a window or graphics request from -.B Xnest -to the real server. -Therefore, it is desirable that -.B Xnest -and the real server are on a local network, or even better, on the same machine. -.B Xnest -assumes that the real server supports the SHAPE extension. -There is no way to turn off this assumption dynamically. -.B Xnest -can be compiled without the SHAPE extension built in, in which case the real -server need not support it. -Dynamic SHAPE extension selection support may be considered in further -development of -.BR Xnest . -.PP -Since -.B Xnest -need not use the same default visual as the the real server, the top-level -window of the -.B Xnest -client always has its own color map. -This implies that other windows' colors will not be displayed properly while the -keyboard or pointer focus is in the -.B Xnest -window, unless the real server has support for more than one installed color map -at any time. -The color map associated with the top window of the -.B Xnest -client need not be the appropriate color map that the nested server wants -installed in the real server. -In the case that a nested client attempts to install a color map of a different -visual from the default visual of the nested server, -.B Xnest -will put the top window of this nested client and all other top windows of the -nested clients that use the same color map into the -.I WM_COLORMAP_WINDOWS -property of the top-level -.B Xnest -window on the real server. -Thus, it is important that the real window manager that manages the -.B Xnest -top-level window looks at the -.I WM_COLORMAP_WINDOWS -property rather than the color map associated with the top-level -.B Xnest -window. -Since most window managers don't yet appear to implement this convention -properly, -.B Xnest -can optionally do direct installation of color maps into the real server -bypassing the real window manager. -If the user chooses this option, it is usually necessary to temporarily disable -the real window manager since it will interfere with the -.B Xnest -scheme of color map installation. -.PP -Keyboard and pointer control procedures of the nested server change the keyboard -and pointer control parameters of the real server. -Therefore, after -.B Xnest -is started up, it will change the keyboard and pointer controls of the real -server to its own internal defaults. -.SS "Xnest as a server" -.B Xnest -as a server looks exactly like a real server to its own clients. -For the clients, there is no way of telling if they are running on a real or a -nested server. -.PP -As already mentioned, -.B Xnest -is a very user-friendly server when it comes to customization. -.B Xnest -will pick up a number of command-line arguments that can configure its default -visual class and depth, number of screens, etc. -.PP -The only apparent intricacy from the users' perspective about using -.B Xnest -as a server is the selection of fonts. -.B Xnest -manages fonts by loading them locally and then passing the font name to the real -server and asking it to load that font remotely. -This approach avoids the overload of sending the glyph bits across the network -for every text operation, although it is really a bug. -The consequence of this approach is that the user will have to worry about two -different font paths \(em a local one for the nested server and a remote one for -the real server \(em since -.B Xnest -does not propagate its font path to the real server. -The reason for this is because real and nested servers need not run on the same -file system which makes the two font paths mutually incompatible. -Thus, if there is a font in the local font path of the nested server, there is -no guarantee that this font exists in the remote font path of the real server. -The -.BR xlsfonts (__appmansuffix__) -client, if run on the nested server, will list fonts in the local font path and, -if run on the real server, will list fonts in the remote font path. -Before a font can be successfully opened by the nested server, it has to exist -in local and remote font paths. -It is the users' responsibility to make sure that this is the case. -.SH "FUTURE DIRECTIONS" -Make dynamic the requirement for the SHAPE extension in the real server, rather -than having to recompile -.B Xnest -to turn this requirement on and off. -.PP -Perhaps there should be a command-line option to tell -.B Xnest -to inherit the keyboard and pointer control parameters from the real server -rather than imposing its own. -.PP -.B Xnest -should read a customization input file to provide even greater freedom and -simplicity in selecting the desired layout. -.PP -There is no support for backing store and save unders, but this should also be -considered. -.PP -.\" Is the following still true now that client-side font rendering is -.\" considered the way to go? -The proper implementation of fonts should be moved into the -.I os -layer. -.SH BUGS -Doesn't run well on servers supporting different visual depths. -.PP -Still crashes randomly. -.PP -Probably has some memory leaks. -.SH AUTHOR -Davor Matic, MIT X Consortium -.SH "SEE ALSO" -.BR Xserver (__appmansuffix__), -.BR xdpyinfo (__appmansuffix__), -.BR X (__miscmansuffix__) diff --git a/xorg-server/hw/xnest/man/Makefile.am b/xorg-server/hw/xnest/man/Makefile.am new file mode 100644 index 000000000..30b6370bc --- /dev/null +++ b/xorg-server/hw/xnest/man/Makefile.am @@ -0,0 +1,2 @@ +include $(top_srcdir)/manpages.am +appman_PRE = Xnest.man diff --git a/xorg-server/hw/xnest/man/Xnest.man b/xorg-server/hw/xnest/man/Xnest.man new file mode 100644 index 000000000..024d88e82 --- /dev/null +++ b/xorg-server/hw/xnest/man/Xnest.man @@ -0,0 +1,428 @@ +.\" $Xorg: Xnest.man,v 1.3 2000/08/17 19:53:28 cpqbld Exp $ +.\" Copyright (c) 1993, 1994 X Consortium +.\" +.\" Permission is hereby granted, free of charge, to any person obtaining +.\" a copy of this software and associated documentation files (the +.\" "Software"), to deal in the Software without restriction, including +.\" without limitation the rights to use, copy, modify, merge, publish, +.\" distribute, sublicense, and/or sell copies of the Software, and to +.\" permit persons to whom the Software is furnished to do so, subject to +.\" the following conditions: +.\" +.\" The above copyright notice and this permission notice shall be included +.\" in all copies or substantial portions of the Software. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS +.\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF +.\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. +.\" IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR +.\" OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, +.\" ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR +.\" OTHER DEALINGS IN THE SOFTWARE. +.\" +.\" Except as contained in this notice, the name of the X Consortium shall +.\" not be used in advertising or otherwise to promote the sale, use or +.\" other dealings in this Software without prior written authorization +.\" from the X Consortium. +.\" +.\" $XFree86: xc/programs/Xserver/hw/xnest/Xnest.man,v 1.6 2001/01/27 18:21:00 dawes Exp $ +.\" +.TH Xnest __appmansuffix__ __xorgversion__ +.SH NAME +Xnest \- a nested X server +.SH SYNOPSIS +.B Xnest +[ +.I options +] +.SH DESCRIPTION +.B Xnest +is both an X client and an X server. +.B Xnest +is a client of the real server which manages windows and graphics requests on +its behalf. +.B Xnest +is a server to its own clients. +.B Xnest +manages windows and graphics requests on their behalf. +To these clients, +.B Xnest +appears to be a conventional server. +.SH OPTIONS +.B Xnest +supports all standard options of the sample server implementation. +For more details, please see +.BR Xserver (__appmansuffix__). +The following additional arguments are supported as well. +.TP +.BI "\-display " string +This option specifies the display name of the real server that +.B Xnest +should try to connect to. +If it is not provided on the command line, +.B Xnest +will read the +.I DISPLAY +environment variable in order to find out this information. +.TP +.B \-sync +This option tells +.B Xnest +to synchronize its window and graphics operations with the real server. +This is a useful option for debugging, but it will slow down +.BR Xnest 's +performance considerably. +It should not be used unless absolutely necessary. +.TP +.B \-full +This option tells +.B Xnest +to utilize full regeneration of real server objects and reopen a new connection +to the real server each time the nested server regenerates. +The sample server implementation regenerates all objects in the server when the +last client of this server terminates. +When this happens, +.B Xnest +by default maintains the same top-level window and the same real server +connection in each new generation. +If the user selects full regeneration, even the top-level window and the +connection to the real server will be regenerated for each server generation. +.TP +.BI "\-class " string +This option specifies the default visual class of the nested server. +It is similar to the +.B \-cc +option from the set of standard options except that it will accept a string +rather than a number for the visual class specification. +The +.I string +must be one of the following six values: +.BR StaticGray , +.BR GrayScale , +.BR StaticColor , +.BR PseudoColor , +.BR TrueColor , +or +.BR DirectColor . +If both the +.B \-class +and +.B \-cc +options are specified, the last instance of either option takes precedence. +The class of the default visual of the nested server need not be the same as the +class of the default visual of the real server, but it must be supported by the +real server. +Use +.BR xdpyinfo (__appmansuffix__) +to obtain a list of supported visual classes on the real server before starting +.BR Xnest . +If the user chooses a static class, all the colors in the default color map will +be preallocated. +If the user chooses a dynamic class, colors in the default color map will be +available to individual clients for allocation. +.TP +.BI "\-depth " int +This option specifies the default visual depth of the nested server. +The depth of the default visual of the nested server need not be the same as the +depth of the default visual of the real server, but it must be supported by the +real server. +Use +.BR xdpyinfo (__appmansuffix__) +to obtain a list of supported visual depths on the real server before starting +.BR Xnest . +.TP +.B \-sss +This option tells +.B Xnest +to use the software screen saver. +By default, +.B Xnest +will use the screen saver that corresponds to the hardware screen saver in the +real server. +Of course, even this screen saver is software-generated since +.B Xnest +does not control any actual hardware. +However, it is treated as a hardware screen saver within the sample server code. +.TP +.B \-geometry \fIW\fBx\fIH\fB+\fIX\fB+\fIY\fP +This option specifies the geometry parameters for the top-level +.B Xnest +window. +See \(lqGEOMETRY SPECIFICATIONS\(rq in +.BR X (__miscmansuffix__) +for a discusson of this option's syntax. +This window corresponds to the root window of the nested server. +The width +.I W +and height +.I H +specified with this option will be the maximum width and height of each +top-level +.B Xnest +window. +.B Xnest +will allow the user to make any top-level window smaller, but it will not +actually change the size of the nested server root window. +.B Xnest +does not yet support the RANDR extension for resizing, rotation, and reflection +of the root window. +If this option is not specified, +.B Xnest +will choose +.I W +and +.I H +to be 3/4ths the dimensions of the root window of the real server. +.TP +.BI "\-bw " int +This option specifies the border width of the top-level +.B Xnest +window. +The integer parameter +.I int +must be positive. +The default border width is 1. +.TP +.BI "\-name " string +This option specifies the name of the top-level +.B Xnest +window as +.IR string . +The default value is the program name. +.TP +.BI "\-scrns " int +This option specifies the number of screens to create in the nested server. +For each screen, +.B Xnest +will create a separate top-level window. +Each screen is referenced by the number after the dot in the client display name +specification. +For example, +.B xterm \-display :1.1 +will open an +.BR xterm (__appmansuffix__) +client in the nested server with the display number +.B :1 +on the second screen. +The number of screens is limited by the hard-coded constant in the server sample +code, which is usually 3. +.TP +.B \-install +This option tells +.B Xnest +to do its own color map installation by bypassing the real window manager. +For it to work properly, the user will probably have to temporarily quit the +real window manager. +By default, +.B Xnest +will keep the nested client window whose color map should be installed in the +real server in the +.I WM_COLORMAP_WINDOWS +property of the top-level +.B Xnest +window. +If this color map is of the same visual type as the root window of the nested +server, +.B Xnest +will associate this color map with the top-level +.B Xnest +window as well. +Since this does not have to be the case, window managers should look primarily +at the +.I WM_COLORMAP_WINDOWS +property rather than the color map associated with the top-level +.B Xnest +window. +.\" Is the following still true? This sentence is several years old. +Unfortunately, window managers are not very good at doing that yet so this +option might come in handy. +.TP +.BI "\-parent " window_id +This option tells +.B Xnest +to use +.I window_id +as the root window instead of creating a window. +.\" XRX is dead, dead, dead. +.\" This option is used by the xrx xnestplugin. +.SH "EXTENDED DESCRIPTION" +Starting up +.B Xnest +is just as simple as starting up +.BR xclock (__appmansuffix__) +from a terminal emulator. +If a user wishes to run +.B Xnest +on the same +workstation as the real server, it is important that the nested server is given +its own listening socket address. +Therefore, if there is a server already running on the user's workstation, +.B Xnest +will have to be started up with a new display number. +Since there is usually no more than one server running on a workstation, +specifying +.RB \(oq "Xnest :1" \(cq +on the command line will be sufficient for most users. +For each server running on the workstation, the display number needs to be +incremented by one. +Thus, if you wish to start another +.BR Xnest , +you will need to type +.RB \(oq "Xnest :2" \(cq +on the command line. +.PP +To run clients in the nested server, each client needs to be given the same +display number as the nested server. +For example, +.RB \(oq "xterm \-display :1" \(cq +will start up an +.B xterm +process in the first nested server +and +.RB \(oq "xterm \-display :2" \(cq +will start an +.B xterm +in the second nested server from the example above. +Additional clients can be started from these +.BR xterm s +in each nested server. +.SS "Xnest as a client" +.B Xnest +behaves and looks to the real server and other real clients as another real +client. +It is a rather demanding client, however, since almost any window or graphics +request from a nested client will result in a window or graphics request from +.B Xnest +to the real server. +Therefore, it is desirable that +.B Xnest +and the real server are on a local network, or even better, on the same machine. +.B Xnest +assumes that the real server supports the SHAPE extension. +There is no way to turn off this assumption dynamically. +.B Xnest +can be compiled without the SHAPE extension built in, in which case the real +server need not support it. +Dynamic SHAPE extension selection support may be considered in further +development of +.BR Xnest . +.PP +Since +.B Xnest +need not use the same default visual as the the real server, the top-level +window of the +.B Xnest +client always has its own color map. +This implies that other windows' colors will not be displayed properly while the +keyboard or pointer focus is in the +.B Xnest +window, unless the real server has support for more than one installed color map +at any time. +The color map associated with the top window of the +.B Xnest +client need not be the appropriate color map that the nested server wants +installed in the real server. +In the case that a nested client attempts to install a color map of a different +visual from the default visual of the nested server, +.B Xnest +will put the top window of this nested client and all other top windows of the +nested clients that use the same color map into the +.I WM_COLORMAP_WINDOWS +property of the top-level +.B Xnest +window on the real server. +Thus, it is important that the real window manager that manages the +.B Xnest +top-level window looks at the +.I WM_COLORMAP_WINDOWS +property rather than the color map associated with the top-level +.B Xnest +window. +Since most window managers don't yet appear to implement this convention +properly, +.B Xnest +can optionally do direct installation of color maps into the real server +bypassing the real window manager. +If the user chooses this option, it is usually necessary to temporarily disable +the real window manager since it will interfere with the +.B Xnest +scheme of color map installation. +.PP +Keyboard and pointer control procedures of the nested server change the keyboard +and pointer control parameters of the real server. +Therefore, after +.B Xnest +is started up, it will change the keyboard and pointer controls of the real +server to its own internal defaults. +.SS "Xnest as a server" +.B Xnest +as a server looks exactly like a real server to its own clients. +For the clients, there is no way of telling if they are running on a real or a +nested server. +.PP +As already mentioned, +.B Xnest +is a very user-friendly server when it comes to customization. +.B Xnest +will pick up a number of command-line arguments that can configure its default +visual class and depth, number of screens, etc. +.PP +The only apparent intricacy from the users' perspective about using +.B Xnest +as a server is the selection of fonts. +.B Xnest +manages fonts by loading them locally and then passing the font name to the real +server and asking it to load that font remotely. +This approach avoids the overload of sending the glyph bits across the network +for every text operation, although it is really a bug. +The consequence of this approach is that the user will have to worry about two +different font paths \(em a local one for the nested server and a remote one for +the real server \(em since +.B Xnest +does not propagate its font path to the real server. +The reason for this is because real and nested servers need not run on the same +file system which makes the two font paths mutually incompatible. +Thus, if there is a font in the local font path of the nested server, there is +no guarantee that this font exists in the remote font path of the real server. +The +.BR xlsfonts (__appmansuffix__) +client, if run on the nested server, will list fonts in the local font path and, +if run on the real server, will list fonts in the remote font path. +Before a font can be successfully opened by the nested server, it has to exist +in local and remote font paths. +It is the users' responsibility to make sure that this is the case. +.SH "FUTURE DIRECTIONS" +Make dynamic the requirement for the SHAPE extension in the real server, rather +than having to recompile +.B Xnest +to turn this requirement on and off. +.PP +Perhaps there should be a command-line option to tell +.B Xnest +to inherit the keyboard and pointer control parameters from the real server +rather than imposing its own. +.PP +.B Xnest +should read a customization input file to provide even greater freedom and +simplicity in selecting the desired layout. +.PP +There is no support for backing store and save unders, but this should also be +considered. +.PP +.\" Is the following still true now that client-side font rendering is +.\" considered the way to go? +The proper implementation of fonts should be moved into the +.I os +layer. +.SH BUGS +Doesn't run well on servers supporting different visual depths. +.PP +Still crashes randomly. +.PP +Probably has some memory leaks. +.SH AUTHOR +Davor Matic, MIT X Consortium +.SH "SEE ALSO" +.BR Xserver (__appmansuffix__), +.BR xdpyinfo (__appmansuffix__), +.BR X (__miscmansuffix__) -- cgit v1.2.3