The X11 driver
--------------

   Most Wine users run Wine under the windowing system known as X11.
   During most of Wine's history, this was the only display driver
   available, but in recent years, parts of Wine has been reorganized to
   allow for other display drivers (although the only alternative
   currently available is Patrik Stridvall's ncurses-based ttydrv, which
   he claims works for displaying calc.exe). The display driver is chosen
   with the "GraphicsDriver" option in the [wine] section of
   wine.conf/.winerc, but I will only cover the x11drv in this document.
   
  x11drv modes of operation
  
   The x11drv consists of two conceptually distinct pieces, the graphics
   driver (GDI part), and the windowing driver (USER part). Both of these
   are linked into the libx11drv.so module, though (which you load with
   the "GraphicsDriver" option). In Wine, running on X11, the graphics
   driver must draw on drawables (window interiors) provided by the
   windowing driver. This differs a bit from the Windows model, where the
   windowing system creates and configures device contexts controlled by
   the graphics driver, and applications are allowed to hook into this
   relationship anywhere they like. Thus, to provide any reasonable
   tradeoff between compatibility and usability, the x11drv has three
   different modes of operation.
   
   Unmanaged/Normal
          The default. Window-manager-independent (any running window
          manager is ignored completely). Window decorations (title bars,
          borders, etc) are drawn by Wine to look and feel like the real
          Windows. This is compatible with applications that depend on
          being able to compute the exact sizes of any such decorations,
          or that want to draw their own.
          
   Managed
          Specified by using the --managed command-line option or the
          Managed wine.conf option (see below). Ordinary top-level frame
          windows with thick borders, title bars, and system menus will
          be managed by your window manager. This lets these applications
          integrate better with the rest of your desktop, but may not
          always work perfectly. (A rewrite of this mode of operation, to
          make it more robust and less patchy, is highly desirable,
          though, and is planned to be done before the Wine 1.0 release.)
          
   Desktop-in-a-Box
          Specified by using the --desktop command-line option (with a
          geometry, e.g. --desktop 800x600 for a such-sized desktop, or
          even --desktop 800x600+0+0 to automatically position the
          desktop at the upper-left corner of the display). This is the
          mode most compatible with the Windows model. All application
          windows will just be Wine-drawn windows inside the
          Wine-provided desktop window (which will itself be managed by
          your window manager), and Windows applications can roam freely
          within this virtual workspace and think they own it all,
          without disturbing your other X apps.
          
  The [x11drv] section
  
   AllocSystemColors
          Applies only if you have a palette-based display, i.e. if your
          X server is set to a depth of 8bpp, and if you haven't
          requested a private color map. It specifies the maximum number
          of shared colormap cells (palette entries) Wine should occupy.
          The higher this value, the less colors will be available to
          other applications.
          
   PrivateColorMap
          Applies only if you have a palette-based display, i.e. if your
          X server is set to a depth of 8bpp. It specifies that you don't
          want to use the shared color map, but a private color map,
          where all 256 colors are available. The disadvantage is that
          Wine's private color map is only seen while the mouse pointer
          is inside a Wine window, so psychedelic flashing and funky
          colors will become routine if you use the mouse a lot.
          
   PerfectGraphics
          This option only determines whether fast X11 routines or exact
          Wine routines will be used for certain ROP codes in blit
          operations. Most users won't notice any difference.
          
   ScreenDepth
          Applies only to multi-depth displays. It specifies which of the
          available depths Wine should use (and tell Windows apps about).
          
   Display
          This specifies which X11 display to use, and if specified, will
          override both the DISPLAY environment variable and the
          --display command-line option.
          
   Managed
          Wine can let frame windows be managed by your window manager.
          This option specifies whether you want that by default.
          
   UseDGA
          This specifies whether you want DirectDraw to use XFree86's
          Direct Graphics Architecture (DGA), which is able to take over
          the entire display and run the game full-screen at maximum
          speed. (With DGA1 (XFree86 3.x), you still have to configure
          the X server to the game's requested bpp first, but with DGA2
          (XFree86 4.x), runtime depth-switching may be possible,
          depending on your driver's capabilities.) But be aware that if
          Wine crashes while in DGA mode, it may not be possible to
          regain control over your computer without rebooting. DGA
          normally requires either root privileges or read/write access
          to /dev/mem.
          
   UseXShm
          If you don't want DirectX to use DGA, you can at least use X
          Shared Memory extensions (XShm). It is much slower than DGA,
          since the app doesn't have direct access to the physical frame
          buffer, but using shared memory to draw the frame is at least
          faster than sending the data through the standard X11 socket,
          even though Wine's XShm support is still known to crash
          sometimes.
          
   DXGrab
          If you don't use DGA, you may want an alternative means to
          convince the mouse cursor to stay within the game window. This
          option does that. Of course, as with DGA, if Wine crashes,
          you're in trouble (although not as badly as in the DGA case,
          since you can still use the keyboard to get out of X).
          
   DesktopDoubleBuffered
          Applies only if you use the --desktop command-line option to
          run in a desktop window. Specifies whether to create the
          desktop window with a double-buffered visual, something most
          OpenGL games need to run correctly.
          
                                                              - Ove Kven
