Merge branch 'master' of ssh://herrb@git.freedesktop.org/git/xorg/xserver

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

composite/compext.c

@@ -696,11 +696,13 @@ CompositeExtensionInit (void)
 	if (GetPictureScreenIfSet(pScreen) == NULL)
 	    return;
     }
+#ifdef PANORAMIX
     /* Xinerama's rewriting of window drawing before Composite gets to it
      * breaks Composite.
      */
     if (!noPanoramiXExtension)
 	return;
+#endif
 
     CompositeClientWindowType = CreateNewResourceType (FreeCompositeClientWindow);
     if (!CompositeClientWindowType)

configure.ac

@@ -123,19 +123,19 @@ b = __swap16(a);
 ], [SYS_ENDIAN__SWAP='yes'], [SYS_ENDIAN__SWAP='no'])
 	AC_MSG_RESULT([$SYS_ENDIAN__SWAP])
 
-	AC_MSG_CHECKING([for bswap_16 variant of <sys/endian.h> byteswapping macros])
+	AC_MSG_CHECKING([for bswap16 variant of <sys/endian.h> byteswapping macros])
 	AC_LINK_IFELSE([AC_LANG_PROGRAM([
 #include <sys/endian.h>
  ], [
 int a = 1, b;
-b = bswap_16(a);
+b = bswap16(a);
  ])
 ], [SYS_ENDIAN_BSWAP='yes'], [SYS_ENDIAN_BSWAP='no'])
 	AC_MSG_RESULT([$SYS_ENDIAN_BSWAP])
 
     	if test "$SYS_ENDIAN_BSWAP" = "yes" ; then
 		USE_SYS_ENDIAN_H=yes
-		BSWAP=bswap_
+		BSWAP=bswap
 	else	
 	    	if test "$SYS_ENDIAN__SWAP" = "yes" ; then
 			USE_SYS_ENDIAN_H=yes
@@ -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}"
 
 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])
@@ -1596,7 +1600,7 @@ AC_MSG_CHECKING([whether to build Xprint DDX])
 AC_MSG_RESULT([$XPRINT])
 
 if test "x$XPRINT" = xyes; then
-	PKG_CHECK_MODULES([XPRINT], [printproto x11 xfont $XDMCP_MODULES xau])
+	PKG_CHECK_MODULES([XPRINT], [printproto x11 xfont $XDMCP_MODULES xau $PIXMAN])
 	XPRINT_EXTENSIONS="$XEXT_LIB $DBE_LIB $XTRAP_LIB $RECORD_LIB $RENDER_LIB $COMPOSITE_LIB $RANDR_LIB $XI_LIB $FIXES_LIB $DAMAGE_LIB $XI_LIB $GLX_LIBS"
 	XPRINT_LIBS="$DIX_LIB $CONFIG_LIB $XKB_LIB $XKB_STUB_LIB $XPRINT_EXTENSIONS $MI_LIB $MIEXT_DAMAGE_LIB $CWRAP_LIB $OS_LIB $LIBS $XPRINT_LIBS"
 	AC_SUBST([XPRINT_CFLAGS])

dix/devices.c

@@ -425,6 +425,7 @@ InitAndStartDevices(void)
     for (dev = inputInfo.devices;
 	 dev && (dev != inputInfo.keyboard);
 	 dev = dev->next)
+	;
     if (!dev || (dev != inputInfo.keyboard)) {
 	ErrorF("No core keyboard\n");
 	return BadImplementation;

dix/events.c

@@ -695,6 +695,13 @@ XineramaChangeToCursor(CursorPtr cursor)
     }
 }
 
+#else
+#define SyntheticMotion(x, y) \
+     PostSyntheticMotion(x, y, \
+                         0, \
+                         syncEvents.playingEvents ? \
+                           syncEvents.time.milliseconds : \
+                           currentTime.milliseconds);
 
 #endif  /* PANORAMIX */
 

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

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
 
 /*

hw/xfree86/common/xf86xv.c

@@ -979,6 +979,9 @@ xf86XVEnlistPortInWindow(WindowPtr pWin, XvPortRecPrivatePtr portPriv)
 	winPriv->next = PrivRoot;
 	pWin->devPrivates[XF86XVWindowIndex].ptr = (pointer)winPriv;
    }
+
+   portPriv->pDraw = (DrawablePtr)pWin;
+
    return Success;
 }
 
@@ -1375,7 +1378,6 @@ xf86XVPutVideo(
   result =  xf86XVEnlistPortInWindow((WindowPtr)pDraw, portPriv);
   if(result != Success) return result;
 
-  portPriv->pDraw = pDraw;
   portPriv->type = XvInputMask;
 
   /* save a copy of these parameters */
@@ -1479,7 +1481,6 @@ xf86XVPutStill(
 
      xf86XVEnlistPortInWindow((WindowPtr)pDraw, portPriv);
      portPriv->isOn = XV_ON;
-     portPriv->pDraw = pDraw;
      portPriv->drw_x = drw_x;  portPriv->drw_y = drw_y;
      portPriv->drw_w = drw_w;  portPriv->drw_h = drw_h;
      portPriv->type = 0;  /* no mask means it's transient and should
@@ -1529,7 +1530,6 @@ xf86XVGetVideo(
   result =  xf86XVEnlistPortInWindow((WindowPtr)pDraw, portPriv);
   if(result != Success) return result;
 
-  portPriv->pDraw = pDraw;
   portPriv->type = XvOutputMask;
 
   /* save a copy of these parameters */
@@ -1784,7 +1784,6 @@ xf86XVPutImage(
 	(portPriv->AdaptorRec->flags & VIDEO_OVERLAID_IMAGES)) {
 
      portPriv->isOn = XV_ON;
-     portPriv->pDraw = pDraw;
      portPriv->drw_x = drw_x;  portPriv->drw_y = drw_y;
      portPriv->drw_w = drw_w;  portPriv->drw_h = drw_h;
      portPriv->type = 0;  /* no mask means it's transient and should
@@ -1876,42 +1875,35 @@ xf86XVFillKeyHelperDrawable (DrawablePtr pDraw, CARD32 key, RegionPtr clipboxes)
 _X_EXPORT void
 xf86XVFillKeyHelper (ScreenPtr pScreen, CARD32 key, RegionPtr clipboxes)
 {
-   XF86XVScreenPtr ScreenPriv = GET_XF86XV_SCREEN(pScreen);
    DrawablePtr root = &WindowTable[pScreen->myNum]->drawable;
    XID pval[2];
    BoxPtr pbox = REGION_RECTS(clipboxes);
    int i, nbox = REGION_NUM_RECTS(clipboxes);
    xRectangle *rects;
+   GCPtr gc;
 
    if(!xf86Screens[pScreen->myNum]->vtSema) return;
 
-   if(!ScreenPriv->videoGC) {
+   gc = GetScratchGC(root->depth, pScreen);
-       int status;
    pval[0] = key;
    pval[1] = IncludeInferiors;
-       ScreenPriv->videoGC = CreateGC(root, GCForeground | GCSubwindowMode,
+   (void) ChangeGC(gc, GCForeground|GCSubwindowMode, pval);
-				      pval, &status);
+   ValidateGC(root, gc);
-       if(!ScreenPriv->videoGC) return;
-       ValidateGC(root, ScreenPriv->videoGC);
-   } else if (key != ScreenPriv->videoGC->fgPixel){
-       pval[0] = key;
-       ChangeGC(ScreenPriv->videoGC, GCForeground, pval);
-       ValidateGC(root, ScreenPriv->videoGC);
-   }
 
-   rects = ALLOCATE_LOCAL(nbox * sizeof(xRectangle));
+   rects = xalloc (nbox * sizeof(xRectangle));
 
-   for(i = 0; i < nbox; i++, pbox++) {
+   for(i = 0; i < nbox; i++, pbox++) 
+   {
       rects[i].x = pbox->x1;
       rects[i].y = pbox->y1;
       rects[i].width = pbox->x2 - pbox->x1;
       rects[i].height = pbox->y2 - pbox->y1;
    }
    
-   (*ScreenPriv->videoGC->ops->PolyFillRect)(
+   (*gc->ops->PolyFillRect)(root, gc, nbox, rects);
-			     root, ScreenPriv->videoGC, nbox, rects);
    
-   DEALLOCATE_LOCAL(rects);
+   xfree (rects);
+   FreeScratchGC (gc);
 }
 
 /* xf86XVClipVideoHelper -

hw/xfree86/os-support/bsd/i386_video.c

@@ -50,6 +50,11 @@
 #include <machine/mtrr.h>
 #include <machine/sysarch.h>
 #include <sys/queue.h>
+#ifdef __x86_64__
+#define i386_set_mtrr x86_64_set_mtrr
+#define i386_get_mtrr x86_64_get_mtrr
+#define i386_iopl x86_64_iopl
+#endif
 #endif
 
 #if defined(__OpenBSD__) && defined(__amd64__)

hw/xfree86/os-support/bus/linuxPci.c

@@ -788,8 +788,10 @@ xf86ReadDomainMemory(PCITAG Tag, ADDRESS Base, int Len, unsigned char *Buf)
 	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);

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");

hw/xnest/Xnest.man.pre

@@ -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
+.B Xnest
-real server which manages windows and graphics requests on its behalf.
+is both an X client and an X server.
-\fIXnest\fP is a server to its own clients.  \fIXnest\fP manages
+.B Xnest
-windows and graphics requests on their behalf.  To these clients
+is a client of the real server which manages windows and graphics requests on
-\fIXnest\fP appears to be a conventional server.
+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
+.B Xnest
-implementation.  For more details, please see the manual page on your
+supports all standard options of the sample server implementation.
-system for \fIXserver\fP.  The following additional arguments are
+For more details, please see
-supported as well.
+.BR Xserver (__appmansuffix__).
-.TP 4
+The following additional arguments are supported as well.
-.B \-display \fIstring\fP
+.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
+.B Xnest
-command line \fIXnest\fP will read the \fIDISPLAY\fP environment
+should try to connect to.
-variable in order to find out the same information.
+If it is not provided on the command line,
-.TP 4
+.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
+This option tells
-operations with the real server.  This is a useful option for
+.B Xnest
-debugging, but it will slow down the performance considerably.  It
+to synchronize its window and graphics operations with the real server.
-should not be used unless absolutely necessary.
+This is a useful option for debugging, but it will slow down
-.TP 4
+.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
+This option tells
-server objects and reopen a new connection to the real server each
+.B Xnest
-time the nested server regenerates.  The sample server implementation
+to utilize full regeneration of real server objects and reopen a new connection
-regenerates all objects in the server when the last client of this
+to the real server each time the nested server regenerates.
-server terminates.  When this happens, \fIXnest\fP by default
+The sample server implementation regenerates all objects in the server when the
-maintains the same top level window and the same real server
+last client of this server terminates.
-connection in each new generation.  If the user selects full
+When this happens,
-regeneration, even the top level window and the connection to the real
+.B Xnest
-server will be regenerated for each server generation.
+by default maintains the same top-level window and the same real server
-.TP 4
+connection in each new generation.
-.B \-class \fIstring\fP
+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
+It is similar to the
-except that it will accept a string rather than a number for the
+.B \-cc
-visual class specification.  The string must be one of the following
+option from the set of standard options except that it will accept a string
-six values: \fIStaticGray\fP, \fIGrayScale\fP, \fIStaticColor\fP,
+rather than a number for the visual class specification.
-\fIPseudoColor\fP, \fITrueColor\fP, or \fIDirectColor\fP.  If both,
+The
-\fI-class\fP and \fI-cc\fP options are specified, the last instance of
+.I string
-either option assumes precedence.  The class of the default visual of
+must be one of the following six values:
-the nested server need not be the same as the class of the default
+.BR StaticGray ,
-visual of the real server; although, it has to be supported by the
+.BR GrayScale ,
-real server.  See \fIxdpyinfo\fP for a list of supported visual
+.BR StaticColor ,
-classes on the real server before starting \fIXnest\fP.  If the user
+.BR PseudoColor ,
-chooses a static class, all the colors in the default colormap will be
+.BR TrueColor ,
-preallocated.  If the user chooses a dynamic class, colors in the
+or
-default colormap will be available to individual clients for
+.BR DirectColor .
-allocation.
+If both the
-.TP 4
+.B \-class
-.B \-depth \fIint\fP
+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
+The depth of the default visual of the nested server need not be the same as the
-same as the depth of the default visual of the real server; although,
+depth of the default visual of the real server, but it must be supported by the
-it has to be supported by the real server.  See \fIxdpyinfo\fP for a
+real server.
-list of supported visual depths on the real server before starting
+Use
-\fIXnest\fP.
+.BR xdpyinfo (__appmansuffix__)
-.TP 4
+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
+This option tells
-default \fIXnest\fP will use the screen saver that corresponds to the
+.B Xnest
-hardware screen saver in the real server.  Of course, even this screen
+to use the software screen saver.
-saver is software generated since \fIXnest\fP does not control any
+By default,
-actual hardware.  However, it is treated as a hardware screen saver
+.B Xnest
-within the sample server code.
+will use the screen saver that corresponds to the hardware screen saver in the
-.TP 4
+real server.
-.B \-geometry \fIWxH+X+Y\fP
+Of course, even this screen saver is software-generated since
-This option specifies geometry parameters for the top level
+.B Xnest
-\fIXnest\fP windows.  These windows corresponds to the root windows of
+does not control any actual hardware.
-the nested server.  The width and height specified with this option
+However, it is treated as a hardware screen saver within the sample server code.
-will be the maximum width and height of each top level \fIXnest\fP
+.TP
-window.  \fIXnest\fP will allow the user to make any top level window
+.B \-geometry \fIW\fBx\fIH\fB+\fIX\fB+\fIY\fP
-smaller, but it will not actually change the size of the nested server
+This option specifies the geometry parameters for the top-level
-root window.  As of yet, there is no mechanism within the sample
+.B Xnest
-server implementation to change the size of the root window after
+window.
-screen initialization.  In order to do so, one would probably need to
+See \(lqGEOMETRY SPECIFICATIONS\(rq in
-extend the X protocol.  Therefore, it is not likely that this will be
+.BR X (__miscmansuffix__)
-available any time soon.  If this option is not specified \fIXnest\fP
+for a discusson of this option's syntax.
-will choose width and height to be 3/4 of the dimensions of the root
+This window corresponds to the root window of the nested server.
-window of the real server.
+The width
-.TP 4
+.I W
-.B \-bw \fIint\fP
+and height
-This option specifies the border width of the top level \fIXnest\fP
+.I H
-window.  The integer parameter must be a positive number.  The default
+specified with this option will be the maximum width and height of each
-border width is 1.
+top-level
-.TP 4
+.B Xnest
-.B \-name \fIstring\fP
+window.
-This option specifies the name of the top level \fIXnest\fP 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
+.TP
-.B \-scrns \fIint\fP
+.BI "\-scrns " int
-This option specifies the number of screens to create in the nested
+This option specifies the number of screens to create in the nested server.
-server.  For each screen, \fIXnest\fP will create a separate top level
+For each screen,
-window.  Each screen is referenced by the number after the dot in the
+.B Xnest
-client display name specification.  For example, \fIxterm -display
+will create a separate top-level window.
-:1.1\fP will open an \fIxterm\fP client in the nested server with the
+Each screen is referenced by the number after the dot in the client display name
-display number \fI:1\fP on the second screen.  The number of screens
+specification.
-is limited by the hard coded constant in the server sample code which
+For example,
-is usually 3.
+.B xterm \-display :1.1
-.TP 4
+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
+This option tells
-bypassing the real window manager.  For it to work properly the user
+.B Xnest
-will probably have to temporarily quit the real window manager.  By
+to do its own color map installation by bypassing the real window manager.
-default \fIXnest\fP will keep the nested client window whose colormap
+For it to work properly, the user will probably have to temporarily quit the
-should be installed in the real server in the
+real window manager.
-\fIWM\_COLORMAP\_WINDOWS\fP property of the top level \fIXnest\fP
+By default,
-window.  If this colormap is of the same visual type as the root
+.B Xnest
-window of the nested server, \fIXnest\fP will associate this colormap
+will keep the nested client window whose color map should be installed in the
-with the top level \fIXnest\fP window as well.  Since this does not
+real server in the
-have to be the case, window managers should look primarily at the
+.I WM_COLORMAP_WINDOWS
-\fIWM\_COLORMAP\_WINDOWS\fP property rather than the colormap
+property of the top-level
-associated with the top level \fIXnest\fP window.  Unfortunately,
+.B Xnest
-window managers are not very good at doing that yet so this option
+window.
-might come in handy.
+If this color map is of the same visual type as the root window of the nested
-.TP 4
+server,
-.B \-parent \fIwindow_id\fP
+.B Xnest
-This option tells \fIXnest\fP to use the \fIwindow_id\fP as the
+will associate this color map with the top-level
-root window instead of creating a window. This option is used
+.B Xnest
-by the xrx xnestplugin.
+window as well.
-.SH USAGE 
+Since this does not have to be the case, window managers should look primarily
-Starting up \fIXnest\fP is as simple as starting up \fIxclock\fP from
+at the
-a terminal emulator.  If a user wishes to run \fIXnest\fP on the same
+.I WM_COLORMAP_WINDOWS
-workstation as the real server, it is important that the nested server
+property rather than the color map associated with the top-level
-is given its own listening socket address.  Therefore, if there is a
+.B Xnest
-server already running on the user's workstation, \fIXnest\fP will
+window.
-have to be started up with a new display number.  Since there is
+.\" Is the following still true?  This sentence is several years old.
-usually no more than one server running on a workstation, specifying
+Unfortunately, window managers are not very good at doing that yet so this
-\fIXnest :1\fP on the command line will be sufficient for most users.
+option might come in handy.
-For each server running on the workstation the display number needs to
+.TP
-be incremented by one.  Thus, if you wish to start another
+.BI "\-parent " window_id
-\fIXnest\fP, you will need to type \fIXnest :2\fP on the command line.
+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
+To run clients in the nested server, each client needs to be given the same
-same display number as the nested server.  For example, \fIxterm
+display number as the nested server.
--display :1\fP will start up an \fIxterm\fP in the first nested server
+For example,
-and \fIxterm -display :2\fP will start an \fIxterm\fP in the second
+.RB \(oq "xterm \-display :1" \(cq
-nested server from the example above.  Additional clients can be
+will start up an
-started from these \fIxterm\fPs in each nested server.
+.B xterm
-.SH XNEST AS A CLIENT
+process in the first nested server
-\fIXnest\fP behaves and looks to the real server and other real
+and
-clients as another real client.  It is a rather demanding client,
+.RB \(oq "xterm \-display :2" \(cq
-however, since almost any window or graphics request from a nested
+will start an
-client will result in a window or graphics request from \fIXnest\fP to
+.B xterm
-the real server.  Therefore, it is desirable that \fIXnest\fP and the
+in the second nested server from the example above.
-real server are on a local network, or even better, on the same
+Additional clients can be started from these
-machine.  As of now, \fIXnest\fP assumes that the real server supports
+.BR xterm s
-the shape extension.  There is no way to turn off this assumption
+in each nested server.
-dynamically.  \fIXnest\fP can be compiled without the shape extension
+.SS "Xnest as a client"
-built in, and in that case the real server need not support it.  The
+.B Xnest
-dynamic shape extension selection support should be considered in
+behaves and looks to the real server and other real clients as another real
-further development of \fIXnest\fP.
+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 \fIXnest\fP need not use the same default visual as the the real
+Since
-server, the top level window of the \fIXnest\fP client always has its
+.B Xnest
-own colormap.  This implies that other windows' colors will not be
+need not use the same default visual as the the real server, the top-level
-displayed properly while the keyboard or pointer focus is in the
+window of the
-\fIXnest\fP window, unless the real server has support for more than
+.B Xnest
-one installed colormap at any time.  The colormap associated with the
+client always has its own color map.
-top window of the \fIXnest\fP client need not be the appropriate
+This implies that other windows' colors will not be displayed properly while the
-colormap that the nested server wants installed in the real server.
+keyboard or pointer focus is in the
-In the case that a nested client attempts to install a colormap of a
+.B Xnest
-different visual from the default visual of the nested server,
+window, unless the real server has support for more than one installed color map
-\fIXnest\fP will put the top window of this nested client and all
+at any time.
-other top windows of the nested clients that use the same colormap
+The color map associated with the top window of the
-into the \fIWM\_COLORMAP\_WINDOWS\fP property of the top level
+.B Xnest
-\fIXnest\fP window on the real server.  Thus, it is important that the
+client need not be the appropriate color map that the nested server wants
-real window manager that manages the \fIXnest\fP top level window
+installed in the real server.
-looks at the \fIWM\_COLORMAP\_WINDOWS\fP property rather than the
+In the case that a nested client attempts to install a color map of a different
-colormap associated with the top level \fIXnest\fP window.  Since most
+visual from the default visual of the nested server,
-window managers appear to not implement this convention properly as of
+.B Xnest
-yet, \fIXnest\fP can optionally do direct installation of colormaps
+will put the top window of this nested client and all other top windows of the
-into the real server bypassing the real window manager.  If the user
+nested clients that use the same color map into the
-chooses this option, it is usually necessary to temporarily disable
+.I WM_COLORMAP_WINDOWS
-the real window manager since it will interfere with the \fIXnest\fP
+property of the top-level
-scheme of colormap installation.
+.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
+Keyboard and pointer control procedures of the nested server change the keyboard
-the keyboard and pointer control parameters of the real server.
+and pointer control parameters of the real server.
-Therefore, after \fIXnest\fP is started up, it will change the
+Therefore, after
-keyboard and pointer controls of the real server to its own internal
+.B Xnest
-defaults.  Perhaps there should be a command line option to tell
+is started up, it will change the keyboard and pointer controls of the real
-\fIXnest\fP to inherit the keyboard and pointer control parameters
+server to its own internal defaults.
-from the real server rather than imposing its own.  This is a future
+.SS "Xnest as a server"
-consideration.
+.B Xnest
-.SH XNEST AS A SERVER
+as a server looks exactly like a real server to its own clients.
-\fIXnest\fP as a server looks exactly like a real server to its own
+For the clients, there is no way of telling if they are running on a real or a
-clients.  For the clients there is no way of telling if they are
+nested server.
-running on a real or a nested server.
 .PP
-As already mentioned, \fIXnest\fP is a very user friendly server when
+As already mentioned,
-it comes to customization.  \fIXnest\fP will pick up a number of
+.B Xnest
-command line arguments that can configure its default visual class and
+is a very user-friendly server when it comes to customization.
-depth, number of screens, etc.  In the future, \fIXnest\fP should read
+.B Xnest
-a customization input file to provide even greater freedom and
+will pick up a number of command-line arguments that can configure its default
-simplicity in selecting the desired layout.  Unfortunately, there is
+visual class and depth, number of screens, etc.
-no support for backing store and save under as of yet, but this should
-also be considered in the future development of \fIXnest\fP.
 .PP
 The only apparent intricacy from the users' perspective about using
-\fIXnest\fP as a server is the selection of fonts.  \fIXnest\fP
+.B Xnest
-manages fonts by loading them locally and then passing the font name
+as a server is the selection of fonts.
-to the real server and asking it to load that font remotely.  This
+.B Xnest
-approach avoids the overload of sending the glyph bits across the
+manages fonts by loading them locally and then passing the font name to the real
-network for every text operation, although it is really a bug.  The
+server and asking it to load that font remotely.
-proper implementation of fonts should be moved into the \fIos\fP
+This approach avoids the overload of sending the glyph bits across the network
-layer. The consequence of this approach is that the user will have to
+for every text operation, although it is really a bug.
-worry about two different font paths - a local one for the nested
+The consequence of this approach is that the user will have to worry about two
-server and a remote one for the real server - since \fIXnest\fP does
+different font paths \(em a local one for the nested server and a remote one for
-not propagate its font path to the real server.  The reason for this
+the real server \(em since
-is because real and nested servers need not run on the same file
+.B Xnest
-system which makes the two font paths mutually incompatible.  Thus, if
+does not propagate its font path to the real server.
-there is a font in the local font path of the nested server, there is
+The reason for this is because real and nested servers need not run on the same
-no guarantee that this font exists in the remote font path of the real
+file system which makes the two font paths mutually incompatible.
-server.  \fIXlsfonts\fP client, if run on the nested server will list
+Thus, if there is a font in the local font path of the nested server, there is
-fonts in the local font path and if run on the real server will list
+no guarantee that this font exists in the remote font path of the real server.
-fonts in the remote font path.  Before a font can be successfully
+The
-opened by the nested server it has to exist in local and remote font
+.BR xlsfonts (__appmansuffix__)
-paths.  It is the users' responsibility to make sure that this is the
+client, if run on the nested server, will list fonts in the local font path and,
-case.
+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.
+Doesn't run well on servers supporting different visual depths.
-Still crashes randomly.  Probably has some memory leaks.
+.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__)

hw/xprint/Makefile.am

@@ -10,9 +10,9 @@ Xprt_CFLAGS = @DIX_CFLAGS@ @XPRINT_CFLAGS@ \
 
 Xprt_LDFLAGS = -L$(top_srcdir)
 Xprt_LDADD = @XPRINT_LIBS@ ps/libps.la raster/libraster.la  \
-	pcl/libpcl.la pcl-mono/libpcl.la ../../fb/libfb.la \
+	pcl/libpcl.la pcl-mono/libpcl.la $(top_builddir)/fb/libfb.la \
-	../../render/librender.la ../../mi/libmi.la ../../Xext/libXext.la \
+	$(top_builddir)/render/librender.la $(top_builddir)/mi/libmi.la \
-	@FREETYPE_LIBS@
+	$(top_builddir)/Xext/libXext.la  @FREETYPE_LIBS@
 
 miinitext-wrapper.c:
 	echo "#include \"$(top_srcdir)/mi/miinitext.c\"" >> $@

hw/xwin/winmultiwindowclass.c

@@ -264,7 +264,7 @@ winMultiWindowGetTransientFor (WindowPtr pWin, WindowPtr *ppDaddy)
       if (prop->propertyName == XA_WM_TRANSIENT_FOR)
         {
           if (ppDaddy)
-            memcpy (*ppDaddy, prop->data, sizeof (WindowPtr *));
+            memcpy (*ppDaddy, prop->data, sizeof (WindowPtr));
           return 1;
         }
       else

include/servermd.h

@@ -516,6 +516,14 @@ SOFTWARE.
 #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.

os/utils.c

@@ -64,8 +64,10 @@ OR PERFORMANCE OF THIS SOFTWARE.
 #include <X11/Xos.h>
 #include <stdio.h>
 #include <time.h>
+#if !defined(WIN32) || !defined(__MINGW32__)
 #include <sys/time.h>
 #include <sys/resource.h>
+#endif
 #include "misc.h"
 #include <X11/X.h>
 #define XSERV_t
@@ -527,6 +529,13 @@ GiveUp(int sig)
     errno = olderrno;
 }
 
+#if defined WIN32 && defined __MINGW32__
+_X_EXPORT CARD32
+GetTimeInMillis (void)
+{
+  return GetTickCount ();
+}
+#else
 _X_EXPORT CARD32
 GetTimeInMillis(void)
 {
@@ -541,6 +550,7 @@ GetTimeInMillis(void)
     X_GETTIMEOFDAY(&tv);
     return(tv.tv_sec * 1000) + (tv.tv_usec / 1000);
 }
+#endif
 
 _X_EXPORT void
 AdjustWaitForDelay (pointer waitTime, unsigned long newdelay)
@@ -798,11 +808,13 @@ ProcessCommandLine(int argc, char *argv[])
 	}
 	else if ( strcmp( argv[i], "-core") == 0)
 	{
-	    struct rlimit   core_limit;
 	    CoreDump = TRUE;
+#if !defined(WIN32) || !defined(__MINGW32__)
+	    struct rlimit   core_limit;
 	    getrlimit (RLIMIT_CORE, &core_limit);
 	    core_limit.rlim_cur = core_limit.rlim_max;
 	    setrlimit (RLIMIT_CORE, &core_limit);
+#endif
 	}
 	else if ( strcmp( argv[i], "-dpi") == 0)
 	{

randr/Makefile.am

@@ -2,6 +2,8 @@ noinst_LTLIBRARIES = librandr.la
 
 AM_CFLAGS = $(DIX_CFLAGS)
 
+XINERAMA_SRCS = rrxinerama.c
+
 if XORG
 sdk_HEADERS = randrstr.h
 endif
@@ -18,5 +20,9 @@ librandr_la_SOURCES =	\
 	rrpointer.c	\
 	rrproperty.c	\
 	rrscreen.c	\
-	rrsdispatch.c	\
+	rrsdispatch.c
-	rrxinerama.c
+
+if XINERAMA
+librandr_la_SOURCES += ${XINERAMA_SRCS}
+endif
+

randr/randr.c

@@ -358,8 +358,9 @@ RRExtensionInit (void)
 	SRRScreenChangeNotifyEvent;
     EventSwapVector[RREventBase + RRNotify] = (EventSwapPtr)
 	SRRNotifyEvent;
-
+#ifdef PANORAMIX
     RRXineramaExtensionInit();
+#endif
 }
 
 static int