I just posted this to [EMAIL PROTECTED] I figured you guys might be interested. I removed the 70 kB of attached diffs to avoid being on the receiving end of a flame fest :) Harold -----Original Message----- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Saturday, March 31, 2001 3:45 PM To: '[EMAIL PROTECTED]' Subject: Cygwin/XFree86 New Server Architecture (Windows 95/98/Me/NT/2000 compatible) These patches completely replace the Cygwin/XFree86 server stored under xc/programs/Xserver/hw/xwin/. The Cygwin/XFree86 project has been testing these patches for the last week and the resulting server is quite stable and runs on nearly all tester's machines (if not all). Suhaib Siddiqi approves of these patches and acknowledges that they completely replace the existing hw/xwin code; however, he will be out of town until tomorrow, and thus unreachable by email until then. Why the old server had to be replaced: The old server was based on the cfb code and required that the video card framebuffer be exposed at all times; the video card framebuffer can only be exposed across Win32 API calls on Windows NT/2000, exposing the video card framebuffer across Win32 API calls freezes Windows 95/98/Me. Windows 95/98/Me takes the Win16Mutex when exposing the video card framebuffer on those platforms; those Windows platforms have code that, for compatibility reasons, requires the Win16Mutex before processing; thus, holding the framebuffer pointer while calling another Win32 API function causes a deadlock that freezes Windows 95/98/Me completely. Changes -------------------------------------------------------------------- On the output front: The new server is based on the fb code and uses the shadow fb code to remove the need to obtain a pointer to the video card framebuffer. Three methods are used by the new server to update the damaged regions of the screen: the GDI blitter, the DirectDraw blitter, and the DirectDraw4 blitter. The fastest supported blitter is determined at screen initialization time and the appropriate function pointers are stored in screen privates. On the color front: The old server had whacky colors that were entirely off, but it did run in 8 bpp mode. The new server cannot yet display correct colors in 8bpp mode, but it has beautifully correct colors in 16, 24, and 32 bpp modes. :) On the input front: The new server uses standard Win32 API messages for processing keyboard and mouse input. The old server used DirectInput, which was not initializing correctly for a lot of testers. DirectDraw sends the scancode of the key instead of the key symbol, while the Win32 API keyboard messages virtualize the key codes; thus the Win32 API method works the same for every keyboard, while DirectInput is keyboard dependent. On the server structure front: The new server now has dynamically allocated screen privates and a strong aversion towards global variables :) On the coding convention front: All files, except ddraw.h and obj_base.h, follow the GNU C coding standard. Comments are sprinkled liberally throughout the code. On the compilation front: The new server compiles completely from the XFree86 tree using gcc; the Visual C++ compiled xf_dx.dll is no longer used. On the dependencies front: The new server can be run on machines that do not have DirectDraw/DirectX installed at all. The server will detect on startup that DirectDraw is not installed, or is installed but not operable, and will fall back on using the GDI blitter. Ironically, the GDI blitter has nearly identical performance to the DirectDraw4 blitter. On the extensions front: The new server now supports the Xrender extension, as fb supports Xrender. On the command line options front: 1) '-engine n' suggests which blitter the server should use; however, the server ignores this parameter if the suggested blitter is not installed, is not operable, or is not supported on a particular platform. 2) '-fullscreen' tells the server to run the server in fullscreen mode. When running with a DirectDraw blitter this causes the current video mode to be changed; when running with the GDI blitter this causes the display window to be the size of the screen and on top of all other windows (in a manner similar to how IE runs in fullscreen). ----------------------------------------------------------------- Hopefully we made the 4.1.0 deadline, Harold Hunt
