DGA, DirectX, XF86Sup.sys style port, etc.
Tue Nov 9 04:07:00 GMT 1999
you keep bringing same points over and over again.
There is no need to confuse DGA with drivers functionality we are
rying to achive for XFree86 servers.
XF86SUP.SYS is not a mix 16 and 32 bit driver. It is a 32 bit
driver. Word DOS is code should not be confused with DOS as known
It is DOS32 under OS/2.
Please let other developers think and utilize their knowledge. If
you think you could do a better job, then you are most welcome to
> -----Original Message-----
> From: Federico Bianchi [ mailto:firstname.lastname@example.org ]
> Sent: Tuesday, November 09, 1999 3:51 AM
> To: Mike MacDonald
> Cc: Suhaib Siddiqi; Jan Rouvillain; Emanuele Aliberti;
> XFree86 over
> CygWin Mailing List
> Subject: DGA, DirectX, XF86Sup.sys style port, etc.
> 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
> > 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
> (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,
> 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:
> !DISCLAIMER!: my e-mail reflects
> _my_own_ opinions!
More information about the Cygwin-xfree