xorg-server: Changes to 'debian-experimental'
Xext/Makefile.am | 1
composite/compext.c | 2
configure.ac | 10
debian/changelog | 14
debian/patches/03_xnest_manpage_overhaul.diff | 653 -------------
debian/patches/04_read_rom_in_chunks.diff | 16
debian/patches/08_s390_servermd.diff | 29
debian/patches/12_security_policy_in_etc.diff | 34
debian/patches/16_s390_fix.diff | 26
debian/patches/23_kfreebsd_support.diff | 13
debian/patches/series | 6
dix/devices.c | 1
dix/events.c | 7
fb/Makefile.am | 4
fb/fb.h | 4
fb/fbedge.c | 314 ------
fb/fbedgeimp.h | 145 --
fb/fbpict.c | 243 ++--
fb/fbpict.h | 12
fb/fbtrap.c | 105 --
hw/kdrive/linux/agp.c | 2
hw/xfree86/common/compiler.h | 2
hw/xfree86/common/xf86xv.c | 42
hw/xfree86/doc/man/xorg.conf.man.pre | 1290 ++++++++++++++------------
hw/xfree86/os-support/bsd/i386_video.c | 5
hw/xfree86/os-support/bus/linuxPci.c | 4
hw/xfree86/os-support/linux/lnx_video.c | 2
hw/xnest/Xnest.man.pre | 596 +++++++-----
hw/xwin/winmultiwindowclass.c | 2
include/servermd.h | 10
os/utils.c | 14
randr/Makefile.am | 10
randr/randr.c | 3
render/renderedge.c | 119 --
render/renderedge.h | 15
35 files changed, 1368 insertions(+), 2387 deletions(-)
New commits:
commit 1504e14fe781a283ab63109f6bf070f0e53b713f
Author: David Nusinow <dnusinow@debian.org>
Date: Mon May 28 22:06:22 2007 -0400
Update upstream pull and remove patches that were pushed upstream
+ 03_xnest_manpage_overhaul.diff
+ 04_read_rom_in_chunks.diff
+ 08_s390_servermd.diff
+ 12_security_policy_in_etc.diff
+ 16_s390_fix.diff
+ 23_kfreebsd_support.diff
diff --git a/debian/changelog b/debian/changelog
index b0dbe7c..4df8091 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
-xorg-server (2:1.3.99.0~git20070523-1) UNRELEASED; urgency=low
+xorg-server (2:1.3.99.0~git20070528-1) UNRELEASED; urgency=low
+ [ Julien Cristau ]
* New upstream snapshot.
+ Update patches:
- 04_read_rom_in_chunks.diff refreshed;
@@ -26,7 +27,16 @@ xorg-server (2:1.3.99.0~git20070523-1) UNRELEASED; urgency=low
rebuilt).
* Disable xprint for now, it fails to build.
- -- Julien Cristau <jcristau@debian.org> Wed, 23 May 2007 20:50:30 +0200
+ [ David Nusinow ]
+ * Remove patches that were pushed upstream
+ + 03_xnest_manpage_overhaul.diff
+ + 04_read_rom_in_chunks.diff
+ + 08_s390_servermd.diff
+ + 12_security_policy_in_etc.diff
+ + 16_s390_fix.diff
+ + 23_kfreebsd_support.diff
+
+ -- David Nusinow <dnusinow@debian.org> Mon, 28 May 2007 22:03:27 -0400
xorg-server (2:1.3.0.0.dfsg-5) unstable; urgency=low
diff --git a/debian/patches/03_xnest_manpage_overhaul.diff b/debian/patches/03_xnest_manpage_overhaul.diff
deleted file mode 100644
index 75cc414..0000000
--- a/debian/patches/03_xnest_manpage_overhaul.diff
+++ /dev/null
@@ -1,653 +0,0 @@
-Index: xorg-server-X11R7.0-1.0.1/hw/xnest/Xnest.man.pre
-===================================================================
---- xorg-server-X11R7.0-1.0.1.orig/hw/xnest/Xnest.man.pre 2006-01-04 23:07:24.000000000 -0500
-+++ xorg-server-X11R7.0-1.0.1/hw/xnest/Xnest.man.pre 2006-02-26 21:29:59.000000000 -0500
-@@ -1,6 +1,6 @@
- .\" $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
-@@ -8,10 +8,10 @@
- .\" 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.
-@@ -19,7 +19,7 @@
- .\" 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
-@@ -27,238 +27,402 @@
- .\"
- .\" $XFree86: xc/programs/Xserver/hw/xnest/Xnest.man,v 1.6 2001/01/27 18:21:00 dawes Exp $
- .\"
--.TH XNEST 1 __xorgversion__
-+.TH Xnest __appmansuffix__ __xorgversion__
- .SH NAME
- Xnest \- a nested X server
- .SH SYNOPSIS
- .B Xnest
--[-options]
-+[
-+.I options
-+]
- .SH DESCRIPTION
--\fIXnest\fP is a client and a server. \fIXnest\fP is a client of the
--real server which manages windows and graphics requests on its behalf.
--\fIXnest\fP is a server to its own clients. \fIXnest\fP manages
--windows and graphics requests on their behalf. To these clients
--\fIXnest\fP appears to be a conventional server.
-+.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
--\fIXnest\fP supports all standard options of the sample server
--implementation. For more details, please see the manual page on your
--system for \fIXserver\fP. The following additional arguments are
--supported as well.
--.TP 4
--.B \-display \fIstring\fP
-+.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
--\fIXnest\fP should try to connect with. If it is not provided on the
--command line \fIXnest\fP will read the \fIDISPLAY\fP environment
--variable in order to find out the same information.
--.TP 4
-+.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 \fIXnest\fP to synchronize its window and graphics
--operations with the real server. This is a useful option for
--debugging, but it will slow down the performance considerably. It
--should not be used unless absolutely necessary.
--.TP 4
-+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 \fIXnest\fP 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, \fIXnest\fP 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 4
--.B \-class \fIstring\fP
-+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 \fI-cc\fP option from the set of standard options
--except that it will accept a string rather than a number for the
--visual class specification. The string must be one of the following
--six values: \fIStaticGray\fP, \fIGrayScale\fP, \fIStaticColor\fP,
--\fIPseudoColor\fP, \fITrueColor\fP, or \fIDirectColor\fP. If both,
--\fI-class\fP and \fI-cc\fP options are specified, the last instance of
--either option assumes 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; although, it has to be supported by the
--real server. See \fIxdpyinfo\fP for a list of supported visual
--classes on the real server before starting \fIXnest\fP. If the user
--chooses a static class, all the colors in the default colormap will be
--preallocated. If the user chooses a dynamic class, colors in the
--default colormap will be available to individual clients for
--allocation.
--.TP 4
--.B \-depth \fIint\fP
-+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; although,
--it has to be supported by the real server. See \fIxdpyinfo\fP for a
--list of supported visual depths on the real server before starting
--\fIXnest\fP.
--.TP 4
-+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 \fIXnest\fP to use the software screen saver. By
--default \fIXnest\fP 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 \fIXnest\fP does not control any
--actual hardware. However, it is treated as a hardware screen saver
--within the sample server code.
--.TP 4
--.B \-geometry \fIWxH+X+Y\fP
--This option specifies geometry parameters for the top level
--\fIXnest\fP windows. These windows corresponds to the root windows of
--the nested server. The width and height specified with this option
--will be the maximum width and height of each top level \fIXnest\fP
--window. \fIXnest\fP 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. As of yet, there is no mechanism within the sample
--server implementation to change the size of the root window after
--screen initialization. In order to do so, one would probably need to
--extend the X protocol. Therefore, it is not likely that this will be
--available any time soon. If this option is not specified \fIXnest\fP
--will choose width and height to be 3/4 of the dimensions of the root
--window of the real server.
--.TP 4
--.B \-bw \fIint\fP
--This option specifies the border width of the top level \fIXnest\fP
--window. The integer parameter must be a positive number. The default
--border width is 1.
--.TP 4
--.B \-name \fIstring\fP
--This option specifies the name of the top level \fIXnest\fP window.
-+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 4
--.B \-scrns \fIint\fP
--This option specifies the number of screens to create in the nested
--server. For each screen, \fIXnest\fP 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, \fIxterm -display
--:1.1\fP will open an \fIxterm\fP client in the nested server with the
--display number \fI:1\fP 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 4
-+.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 \fIXnest\fP to do its own colormap 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 \fIXnest\fP will keep the nested client window whose colormap
--should be installed in the real server in the
--\fIWM\_COLORMAP\_WINDOWS\fP property of the top level \fIXnest\fP
--window. If this colormap is of the same visual type as the root
--window of the nested server, \fIXnest\fP will associate this colormap
--with the top level \fIXnest\fP window as well. Since this does not
--have to be the case, window managers should look primarily at the
--\fIWM\_COLORMAP\_WINDOWS\fP property rather than the colormap
--associated with the top level \fIXnest\fP window. Unfortunately,
--window managers are not very good at doing that yet so this option
--might come in handy.
--.TP 4
--.B \-parent \fIwindow_id\fP
--This option tells \fIXnest\fP to use the \fIwindow_id\fP as the
--root window instead of creating a window. This option is used
--by the xrx xnestplugin.
--.SH USAGE
--Starting up \fIXnest\fP is as simple as starting up \fIxclock\fP from
--a terminal emulator. If a user wishes to run \fIXnest\fP 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, \fIXnest\fP 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
--\fIXnest :1\fP 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
--\fIXnest\fP, you will need to type \fIXnest :2\fP 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, \fIxterm
---display :1\fP will start up an \fIxterm\fP in the first nested server
--and \fIxterm -display :2\fP will start an \fIxterm\fP in the second
--nested server from the example above. Additional clients can be
--started from these \fIxterm\fPs in each nested server.
--.SH XNEST AS A CLIENT
--\fIXnest\fP 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 \fIXnest\fP to
--the real server. Therefore, it is desirable that \fIXnest\fP and the
--real server are on a local network, or even better, on the same
--machine. As of now, \fIXnest\fP assumes that the real server supports
--the shape extension. There is no way to turn off this assumption
--dynamically. \fIXnest\fP can be compiled without the shape extension
--built in, and in that case the real server need not support it. The
--dynamic shape extension selection support should be considered in
--further development of \fIXnest\fP.
--.PP
--Since \fIXnest\fP need not use the same default visual as the the real
--server, the top level window of the \fIXnest\fP client always has its
--own colormap. This implies that other windows' colors will not be
--displayed properly while the keyboard or pointer focus is in the
--\fIXnest\fP window, unless the real server has support for more than
--one installed colormap at any time. The colormap associated with the
--top window of the \fIXnest\fP client need not be the appropriate
--colormap that the nested server wants installed in the real server.
--In the case that a nested client attempts to install a colormap of a
--different visual from the default visual of the nested server,
--\fIXnest\fP will put the top window of this nested client and all
--other top windows of the nested clients that use the same colormap
--into the \fIWM\_COLORMAP\_WINDOWS\fP property of the top level
--\fIXnest\fP window on the real server. Thus, it is important that the
--real window manager that manages the \fIXnest\fP top level window
--looks at the \fIWM\_COLORMAP\_WINDOWS\fP property rather than the
--colormap associated with the top level \fIXnest\fP window. Since most
--window managers appear to not implement this convention properly as of
--yet, \fIXnest\fP can optionally do direct installation of colormaps
--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 \fIXnest\fP
--scheme of colormap installation.
--.PP
--Keyboard and pointer control procedures of the nested server change
--the keyboard and pointer control parameters of the real server.
--Therefore, after \fIXnest\fP is started up, it will change the
--keyboard and pointer controls of the real server to its own internal
--defaults. Perhaps there should be a command line option to tell
--\fIXnest\fP to inherit the keyboard and pointer control parameters
--from the real server rather than imposing its own. This is a future
--consideration.
--.SH XNEST AS A SERVER
--\fIXnest\fP 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, \fIXnest\fP is a very user friendly server when
--it comes to customization. \fIXnest\fP will pick up a number of
--command line arguments that can configure its default visual class and
--depth, number of screens, etc. In the future, \fIXnest\fP should read
--a customization input file to provide even greater freedom and
--simplicity in selecting the desired layout. Unfortunately, there is
--no support for backing store and save under as of yet, but this should
--also be considered in the future development of \fIXnest\fP.
-+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
--\fIXnest\fP as a server is the selection of fonts. \fIXnest\fP
--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
--proper implementation of fonts should be moved into the \fIos\fP
--layer. The consequence of this approach is that the user will have to
--worry about two different font paths - a local one for the nested
--server and a remote one for the real server - since \fIXnest\fP 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. \fIXlsfonts\fP 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.
-+.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
--Won't run well on servers supporting different visual depths.
--Still crashes randomly. Probably has some memory leaks.
-+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/debian/patches/04_read_rom_in_chunks.diff b/debian/patches/04_read_rom_in_chunks.diff
deleted file mode 100644
index ba9c2d0..0000000
--- a/debian/patches/04_read_rom_in_chunks.diff
+++ /dev/null
@@ -1,16 +0,0 @@
-Index: xorg-server/hw/xfree86/os-support/bus/linuxPci.c
-===================================================================
---- xorg-server.orig/hw/xfree86/os-support/bus/linuxPci.c 2007-05-23 17:22:18.000000000 +0200
-+++ xorg-server/hw/xfree86/os-support/bus/linuxPci.c 2007-05-23 17:28:22.000000000 +0200
-@@ -788,8 +788,10 @@
- write(fd, "1", 2);
- lseek(fd, 0, SEEK_SET);
-
-+ len = min(Len, st.st_size);
-+
- /* copy the ROM until we hit Len, EOF or read error */
-- for (i = 0; i < Len && read(fd, Buf, 1) > 0; Buf++, i++)
-+ for (; len && (size = read(fd, Buf, len)) > 0 ; Buf+=size, len-=size)
- ;
-
- write(fd, "0", 2);
diff --git a/debian/patches/08_s390_servermd.diff b/debian/patches/08_s390_servermd.diff
deleted file mode 100644
index 5eab685..0000000
--- a/debian/patches/08_s390_servermd.diff
+++ /dev/null
@@ -1,29 +0,0 @@
-$Id: 500_s390_support.diff 689 2005-10-19 22:11:30Z dnusinow $
-
-Miscellaneous fixes for S/390.
-
-This patch by Gerhard Tonn.
-
-Not submitted to XFree86.
-
-Index: xorg-server/include/servermd.h
-===================================================================
---- xorg-server.orig/include/servermd.h 2006-11-13 19:59:23.000000000 +0100
-+++ xorg-server/include/servermd.h 2006-11-26 01:53:14.000000000 +0100
-@@ -515,7 +515,15 @@
- #define GLYPHPADBYTES 4
- #define GETLEFTBITS_ALIGNMENT 1
- #endif
--
-+
-+/* linux on IBM S/390 */
-+#if defined (linux) && defined (__s390__)
-+#define IMAGE_BYTE_ORDER MSBFirst
-+#define BITMAP_BIT_ORDER MSBFirst
-+#define GLYPHPADBYTES 4
-+#define GETLEFTBITS_ALIGNMENT 1
-+#endif /* linux/s390 */
-+
- /* size of buffer to use with GetImage, measured in bytes. There's obviously
- * a trade-off between the amount of stack (or whatever ALLOCATE_LOCAL gives
- * you) used and the number of times the ddx routine has to be called.
diff --git a/debian/patches/12_security_policy_in_etc.diff b/debian/patches/12_security_policy_in_etc.diff
deleted file mode 100644
index 6c5e845..0000000
--- a/debian/patches/12_security_policy_in_etc.diff
+++ /dev/null
@@ -1,34 +0,0 @@
-Index: xorg-server/configure.ac
-===================================================================
---- xorg-server.orig/configure.ac 2007-05-23 17:21:52.000000000 +0200
-+++ xorg-server/configure.ac 2007-05-23 18:02:13.000000000 +0200
-@@ -465,6 +465,9 @@
- AC_ARG_WITH(rgb-path, AS_HELP_STRING([--with-rgb-path=PATH], [Path to RGB database (default: ${datadir}/X11/rgb)]),
- [ RGBPATH="$withval" ],
- [ RGBPATH="${datadir}/X11/rgb" ])
-+AC_ARG_WITH(serverconfig-path, AS_HELP_STRING([--with-serverconfig-path=PATH], [Path to server config (default: ${libdir}/xserver)]),
-+ [ SERVERCONFIG="$withval" ],
-+ [ SERVERCONFIG="${libdir}/xserver" ])
- APPLE_APPLICATIONS_DIR="${bindir}/Applications"
- AC_ARG_WITH(apple-applications-dir,AS_HELP_STRING([--with-apple-applications-dir=PATH], [Path to the Applications directory (default: ${bindir}/Applications)]),
- [ APPLE_APPLICATIONS_DIR="${withval}" ].
-@@ -938,6 +941,7 @@
-
- AC_DEFINE_DIR(COMPILEDDEFAULTFONTPATH, FONTPATH, [Default font path])
- AC_DEFINE_DIR(RGB_DB, RGBPATH, [Default RGB path])
-+AC_DEFINE_DIR(SERVERCONFIGdir, SERVERCONFIG, [Server config path])
- AC_DEFINE_DIR(BASE_FONT_PATH, FONTDIR, [Default base font path])
- AC_DEFINE_DIR(DRI_DRIVER_PATH, DRI_DRIVER_PATH, [Default DRI driver path])
- AC_DEFINE_UNQUOTED(XVENDORNAME, ["$VENDOR_STRING"], [Vendor name])
-Index: xorg-server/Xext/Makefile.am
-===================================================================
---- xorg-server.orig/Xext/Makefile.am 2007-05-16 15:51:05.000000000 +0200
-+++ xorg-server/Xext/Makefile.am 2007-05-23 18:00:38.000000000 +0200
-@@ -34,7 +34,6 @@
- xcmisc.c
-
- # Extra configuration files ship with some extensions
--SERVERCONFIGdir = $(libdir)/xserver
- SERVERCONFIG_DATA =
-
- # Optional sources included if extension enabled by configure.ac rules
diff --git a/debian/patches/16_s390_fix.diff b/debian/patches/16_s390_fix.diff
deleted file mode 100644
index 5c503df..0000000
--- a/debian/patches/16_s390_fix.diff
+++ /dev/null
@@ -1,26 +0,0 @@
-Index: xorg-server/hw/xfree86/os-support/linux/lnx_video.c
-===================================================================
---- xorg-server.orig/hw/xfree86/os-support/linux/lnx_video.c 2006-11-13 19:59:23.000000000 +0100
-+++ xorg-server/hw/xfree86/os-support/linux/lnx_video.c 2006-11-26 02:06:51.000000000 +0100
-@@ -567,7 +567,7 @@
- #endif
- }
- close(fd);
--#elif !defined(__mc68000__) && !defined(__sparc__) && !defined(__mips__) && !defined(__sh__) && !defined(__hppa__)
-+#elif !defined(__mc68000__) && !defined(__sparc__) && !defined(__mips__) && !defined(__sh__) && !defined(__hppa__) && !defined(__s390__)
- if (ioperm(0, 1024, 1) || iopl(3)) {
- if (errno == ENODEV)
- ErrorF("xf86EnableIOPorts: no I/O ports found\n");
-Index: xorg-server/hw/xfree86/common/compiler.h
-===================================================================
---- xorg-server.orig/hw/xfree86/common/compiler.h 2006-11-13 19:59:23.000000000 +0100
-+++ xorg-server/hw/xfree86/common/compiler.h 2006-11-26 02:06:51.000000000 +0100
-@@ -1365,7 +1365,7 @@
- # define write_mem_barrier() /* NOP */
-
- # if !defined(__SUNPRO_C)
--# if !defined(FAKEIT) && !defined(__mc68000__) && !defined(__arm__) && !defined(__sh__) && !defined(__hppa__)
-+# if !defined(FAKEIT) && !defined(__mc68000__) && !defined(__arm__) && !defined(__sh__) && !defined(__hppa__) && !defined(__s390__)
- # ifdef GCCUSESGAS
-
- /*
diff --git a/debian/patches/23_kfreebsd_support.diff b/debian/patches/23_kfreebsd_support.diff
deleted file mode 100644
index 48e5bc7..0000000
--- a/debian/patches/23_kfreebsd_support.diff
+++ /dev/null
@@ -1,13 +0,0 @@
-Index: xorg-server/hw/kdrive/linux/agp.c
-===================================================================
---- xorg-server.orig/hw/kdrive/linux/agp.c 2007-05-23 17:22:18.000000000 +0200
-+++ xorg-server/hw/kdrive/linux/agp.c 2007-05-23 18:06:59.000000000 +0200
-@@ -65,7 +65,7 @@
-
- #include <linux/agpgart.h>
-
--#elif defined(__FreeBSD__)
-+#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
- #include <sys/ioctl.h>
- #include <sys/agpio.h>
- #endif
diff --git a/debian/patches/series b/debian/patches/series
index b6bf995..ffae1dc 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,16 +1,10 @@
001_ubuntu_add_extra_modelines_from_xorg.patch -p1
02_libvgahw_gcc4_volatile_fix.diff
-03_xnest_manpage_overhaul.diff
-04_read_rom_in_chunks.diff
06_use_proc_instead_of_sysfs_for_pci_domains.diff
07_xorgconf_manpage_overhaul.diff -p0
-08_s390_servermd.diff
10_dont_look_in_home_for_config.diff -p0
-12_security_policy_in_etc.diff
13_debian_add_xkbpath_env_variable.diff
-16_s390_fix.diff
21_glx_align_fixes.patch
-23_kfreebsd_support.diff
24_hurd_ioperm_fix.diff
46_export-ramdac-symbols.diff
91_ttf2pt1
commit ba0b7d47ab0c24d5a29228f8af583044060464bd
Author: David Nusinow <dnusinow@debian.org>
Date: Mon May 28 21:57:04 2007 -0400
Fix for GNU/kFreeBSD
diff --git a/hw/kdrive/linux/agp.c b/hw/kdrive/linux/agp.c
index c2ae625..4fb0cb3 100644
--- a/hw/kdrive/linux/agp.c
+++ b/hw/kdrive/linux/agp.c
@@ -65,7 +65,7 @@ of the copyright holder.
#include <linux/agpgart.h>
-#elif defined(__FreeBSD__)
+#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
#include <sys/ioctl.h>
#include <sys/agpio.h>
#endif
commit 2267bf48b385c93243e26c3bb84ebb04c7fdb39f
Author: Bastian Blank <waldi@debian.org>
Date: Mon May 28 21:55:05 2007 -0400
Fixes for s390
diff --git a/hw/xfree86/common/compiler.h b/hw/xfree86/common/compiler.h
index ea995ed..becd3da 100644
--- a/hw/xfree86/common/compiler.h
+++ b/hw/xfree86/common/compiler.h
@@ -1365,7 +1365,7 @@ do { \
# define write_mem_barrier() /* NOP */
# if !defined(__SUNPRO_C)
-# if !defined(FAKEIT) && !defined(__mc68000__) && !defined(__arm__) && !defined(__sh__) && !defined(__hppa__)
+# if !defined(FAKEIT) && !defined(__mc68000__) && !defined(__arm__) && !defined(__sh__) && !defined(__hppa__) && !defined(__s390__)
# ifdef GCCUSESGAS
/*
diff --git a/hw/xfree86/os-support/linux/lnx_video.c b/hw/xfree86/os-support/linux/lnx_video.c
index 4b58046..02a1310 100644
--- a/hw/xfree86/os-support/linux/lnx_video.c
+++ b/hw/xfree86/os-support/linux/lnx_video.c
@@ -567,7 +567,7 @@ xf86EnableIO(void)
#endif
}
close(fd);
-#elif !defined(__mc68000__) && !defined(__sparc__) && !defined(__mips__) && !defined(__sh__) && !defined(__hppa__)
+#elif !defined(__mc68000__) && !defined(__sparc__) && !defined(__mips__) && !defined(__sh__) && !defined(__hppa__) && !defined(__s390__)
if (ioperm(0, 1024, 1) || iopl(3)) {
if (errno == ENODEV)
ErrorF("xf86EnableIOPorts: no I/O ports found\n");
commit 857ddbb660a21cad1c16f4fb2dc8a904d6655304
Author: Eugene Konev <ejka@imfi.kspu.ru>
Date: Mon May 28 21:53:02 2007 -0400
Allow configurable serverconfigdir for security policy location
Allow the location of the SERVERCONFIGdir variable to be defined at
compile-time. This allows us to specify where the security policy will be
located (Debian uses this to put it in /etc). The default is to the
previous location.
diff --git a/Xext/Makefile.am b/Xext/Makefile.am
index 6ea3d74..d0d23b7 100644
--- a/Xext/Makefile.am
+++ b/Xext/Makefile.am
@@ -34,7 +34,6 @@ MODULE_SRCS = \
xcmisc.c
# Extra configuration files ship with some extensions
-SERVERCONFIGdir = $(libdir)/xserver
SERVERCONFIG_DATA =
# Optional sources included if extension enabled by configure.ac rules
diff --git a/configure.ac b/configure.ac
index 37199cf..7ff712f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -465,6 +465,9 @@ AC_ARG_WITH(xkb-output, AS_HELP_STRING([--with-xkb-output=PATH], [Path to
AC_ARG_WITH(rgb-path, AS_HELP_STRING([--with-rgb-path=PATH], [Path to RGB database (default: ${datadir}/X11/rgb)]),
[ RGBPATH="$withval" ],
[ RGBPATH="${datadir}/X11/rgb" ])
+AC_ARG_WITH(serverconfig-path, AS_HELP_STRING([--with-serverconfig-path=PATH], [Path to server config (default: ${libdir}/xserver)]),
+ [ SERVERCONFIG="$withval" ],
+ [ SERVERCONFIG="${libdir}/xserver" ])
APPLE_APPLICATIONS_DIR="${bindir}/Applications"
AC_ARG_WITH(apple-applications-dir,AS_HELP_STRING([--with-apple-applications-dir=PATH], [Path to the Applications directory (default: ${bindir}/Applications)]),
[ APPLE_APPLICATIONS_DIR="${withval}" ].
@@ -938,6 +941,7 @@ VENDOR_MAN_VERSION="Version ${VENDOR_VERSION_STRING}"
Reply to: