FW: Cygwin/XFree86 New Server Architecture (Windows 95/98/Me/NT/2000 compatible)

[Harold Hunt]

I just posted this to patches@xfree86.org.

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:huntharo@msu.edu ]
Sent: Saturday, March 31, 2001 3:45 PM
To: 'patches@xfree86.org'
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