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/man/Makefile.am | 2 + xorg-server/hw/xnest/man/Xnest.man | 428 +++++++++++++++++++++++++++++++++++ 2 files changed, 430 insertions(+) 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/man') 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