Written by Ove Kåven <ovek@arcticnet.no>
(Extracted from wine/documentation/x11drv)
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 have 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/config, but I will only cover the x11drv driver in this article.
The x11drv driver 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.
The default. Specified by using the Managed wine config file 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 currently being done, though, and it's planned to be finished before the Wine 1.0 release).
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. Unmanaged mode is only used if both Managed and Desktop are set to disabled.
Specified by using the Desktop wine config file option (see below). (adding a geometry, e.g. 800x600 for a such-sized desktop, or even 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. Note: currently there's one desktop window for every application; this will be fixed at some time.
Wine can let frame windows be managed by your window manager. This option specifies whether you want that by default.
Creates a main desktop window of a specified size to display all Windows applications in. The size argument could e.g. be "800x600".
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).
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.
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.
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.
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.
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.
To be used for debugging X11 operations. If Wine crashes with an X11 error, then you should enable Synchronous mode to disable X11 request caching in order to make sure that the X11 error happens directly after the corresponding X11 call in the log file appears. Will slow down X11 output !
Applies only to multi-depth displays. It specifies which of the available depths Wine should use (and tell Windows apps about).
This specifies which X11 display to use, and if specified, will override the DISPLAY environment variable.
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.
Codepage to be used for rendering the text in X11 output. Some sample values would be 437 (USA, Canada), 850 (Europe), 852 (Central/Eastern Europe), 855 (Cyrillic). For additional suitable values, see e.g. the Linux kernel's codepage configuration page.