DGA, DirectX, XF86Sup.sys style port, etc.

[Federico Bianchi <bianchi at www dot arte dot unipi dot it>]

On Mon, 8 Nov 1999, Mike MacDonald wrote:

> What is DGA?  DirectX is the only way I know of to do properly what is
> trying to be done here.   DX can be used to get a pseudo linear buffer,
> address ports, etc.  Plus its guaranteed to work in every version of
> windows, and new versions.   Plus you can possibly used full screen and
> windowed modes..   Anything else is a dangerous hack..

In fact. This was my main point in my discussion with Suhaib. Straight
ports (like XF86Sup.sys) are [wonderful] hacks, and I wouldn't trust on
them.
 
> Why can't a driver be written with DirectX to provide the same services as
> xf86sup.sys?  Then would it need to interact directly with X?

XF86Sup.sys is an OS/2 kernel mode driver (BTW: it is a mixed 16-32 bit
stuff, so it would have to be rewritten from scratch anyway - look at the
NE header). Apart from the pty support (which is downright useful, but
whose need might be circumvented thanks to CygWin), it lets user mode
programs access physical memory and I/O ports. Please note OS/2 also has
a vastly better mode switching support than is usually available under NT
- there are some NT drivers who know nothing but GDI32/DirectX can switch
to non-VGA modes, and therefore don't save all of their context (Windows
NT drivers are often downright _DIRTY_, by the way - some of them bypass
the HAL altogether, some others busy-wait on the PCI/AGP bus when writing
on the FIFO buffer, ...).

You can use DirectX to simulate something like XF86Sup.sys, but I am not
sure it would be a good design criterium. With all of its kludginess
(especially since we would need to deal with DirectX 3 - there is no full
retail DirectX 5 or 6 available for Windows NT 4.0), the DirectX layer is
a pretty powerful hardware abstraction.

In a nutshell, the OS/2 XFree86 port uses XFree86 video drivers. This
_may_ be reasonable under OS/2 (and I wouldn't share this point of view, 
either - GRADD would probably be a better route; I am not sure whether it
was available at the time the project started, though), but IMHO it
_should_not_ be the case under Win32 - both for the presence of better
video drivers under 9x/NT and for stability sake.

My basic idea is to find and isolate the "driver" part in XFree86 and map
it in terms of DirectX 3; in some older XFree86 a suitable candidate was
the so-called Direct Graphics Access layer, but (as I told you 
before) this turned out to be a false step of mine, since not only DGA was
not generalized, but it is now part of the "obsolete" APIs. Current
versions use a different mechanism, based upon dlopen() - and I need to
look at that more carefully, I am not sure I am grasping all of it yet.

Looking at the eventual discussion thread:

>>> Mike MacDonald >>>
Ok, good.  That makes sense.  Ok, then I need to look at as much source as
possible for the XF86SUP.SYS - The questions still in my mind are this, do
we need two drivers, one a windows driver, and the other a DOS driver for
the config.sys?  Or will just a Windows driver that works with NT and Win 98
be fine?  Then, something I prolly gotta figgure out myself, is can I call
directx functions from inside of a driver..  Thats gonna get a little
complicated..  Something like the driver sits there, then when X tries to
communicate with it it makes the DX calls or something..  
.....
<<< Mike MacDonald <<<

You certainly don't need a DOS driver. You can (sort of) call DirectX
COM APIs from a driver posting a message to a "shim" Win32 user mode
application, but I am not sure you need a driver at all (see above); I
think all you need may be done in a safer and better way from user mode,
either calling the DirectX APIs or by extending the XLib over GDI code
I found in the rxvt Win32 port (this presents a lot of other nasties, but
would have a sheer advantage in transparently handling X11 apps much like
Win32 ones, e.g. placing them on the same desktop - and performance might
be improved by following Emanuele Aliberti suggestion to use NTAPI INT 2Eh
calls where available instead of their user mode GDI32.DLL counterparts).

>>> Suhaib Siddiqi >>>
...
I prefer people communicate via mailing list instead of private
messages.  this way others can be kept informed and upto date.

All we need Windows Nt and 98 support.  DOS driver is not the way to
go "I think".
<<< Suhaib Siddiqi <<<

I couldn't agree more with this latter point. I often use private messages
to avoid noise on the mailing list, but Suhaib's view makes sense.

>>> Mike MacDonald >>>
I don't see why this can't just be implemented as a service and a library..
The service would mainly be for pty, and I'm not sure that its necessary for
that..  Windows doesn't have the Ring 0 requirement that OS/2 has I don't
think.  Plus Direct X eliminates the need for some of it..  I'll learn more
as I go, but I don't think this needs to be, or should be a driver on the
Windows platform.

Honestly, I can't think of anything that couldn't just be included in a
library..  Tell me if you've heard otherwise, and I have ALOT more research
to do before I have a solid grasp of what needs to be done, but I think a
straight port of XF86SUP.SYS as a .a archive will work (My opinion here is
VERY subject to change :))  I think the only reason he has it loading in the
config.sys is for the ring 0 requirements that are enforced by OS/2..
<<< Mike MacDonald <<<

In fact. The pty support might probably be taken more profitably from the
CygWin*.dll code, the input handled by means of DirectInput and the
display through DirectDraw. I am not sure Ring0 was required even under
OS/2 (thanks to GRADD, see above), but this is the route they chose at
that time.

Comments, suggestions, errata fixes, discussion welcome. No flames,
please...

	 		Federico Bianchi
			Dipartimento di Storia delle Arti
			Universita` degli Studi di Pisa
			p.zza S.Matteo in Soarta, 2 - 56127 Pisa (Italy)
			tel. +39-050-587111 (cent.), +39-050-587224 (uff.)
			fax. +39-050-580128; e-mail: <f.bianchi@arte.unipi.it>
			===================================================
			!DISCLAIMER!: my e-mail reflects _my_own_ opinions!
			===================================================

null