RE: [Fwd: FW: Win32 XServer]

[Mike MacDonald <mmacdona at tsi dot gte dot com>]

Thanks for your comments.

I aggree with most everything that you have said.  Getting the native X
accel drivers up and running directly to the hardware is definately
possible, definately not easy, and definately the best way to go.

If you look at one of my previous posts you might see some mention of using
GDI for its accelerated 2d primitives.  Between that, and some assembly
routines I have laying around we should be able to come up with some pretty
good xaa direct x stuff.

However, my thinking is that why not just get something out now that works,
and speed it up later.

So if you look at my posts you'll see that I want to modify the code in the
unaccelerated vga256 driver, and create an XF86_DX that uses completely
unaccelerated 2d primitives.  The only major change will be to init the
screen using DX, and bring back a pointer to a DX surface instead of setting
the mode registers directly calling an XF86MapVidMem that maps the memory.

At that point (with not much work) we should have a working, unaccelerated,
(256 color?) directx server that we can now release.  Then we can make sure
and raise the color depths, and accelerate certain most used functions.

If GDI is faster than software then we use GDI.  If we find something else
we can use that.


I think one thing you have to remember is that DX is just a driver.  We can
write our own drivers.   What we are doing by using DX is accepting that
they are doing things well enough already that we don't need to duplicate
their efforts.   We are also accepting alot of constraints - like having to
use a little slower acceleration, and depending on Microsoft to continue
supporting DX, and the functions we are using.

There is alot to balance here.  I personally tipped to DX because I saw how
quickly I could put something together (I still plan to directly access the
keyboard and mouse amoung other things), and I saw how complicated it could
get to get the kind of low level device access we need.

In other words - It can be done, it is NOT a fruitless task, there would be
NO compatibility issues.  There would be issues, and they can be overcome.
However, DirectX has (appatently) overcome many of these obstacles for us,
and its proven, and its quicker to develop with.   On the other hand if we
find that DirectX is not suitable for running X, then we will have to look
closer at direct hardware access.

If you look at some of my previous posts (I was very interactive during my
research process)  You'll see that those are the conclusions I came to.

I do plan to use everything in xc/programs/Xserver/hw - I think it would be
a HORRIBLE waiste to throw away alot of good, tested code.  Besides using an
existing server's code to create the new DX server there is also the
keyboard and mouse and pty stuff - John is working on a DX version of this
stuff -at least the keyboard and mouse.  This is the right way to do things,
however it is a long project from what I've heard.  I think that I can use
some existing drivers for NT and get them to work with Holger's os2 code and
get something up and running.  I definately forsee us switching our
dependence to a direct input final solution there, I don't see us abandoning
the os-support stuff completely though, especially for ptys.


-----Original Message-----
From: cygwin-xfree-owner@sourceware.cygnus.com
[mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Kendall
Bennett
Sent: Thursday, November 18, 1999 12:25 PM
To: cygwin-xfree@sourceware.cygnus.com
Subject: RE: [Fwd: FW: Win32 XServer]


"Suhaib Siddiqi" <ssiddiqi@inspirepharm.com> wrote:

> I noticed a lot of suggestions from Kendall.  My understanding is
> John and Mike had been taking the same approaches. 

Sure, except for that fact that some people still seem bent on the 
idea of getting XF86_SVGA to program the hardware directly under 
Win32. Doing so will be a fruitless task due to the major 
compatbility issues that will ensue. The whole thrust of my posts has 
been to forget about doing that (at least for now), and get a good 
DirectX based server up and running.

> I also do not accept the idea of GDI.  It is too slow and not good
> for any X server. 

I tried to make this clear in my other posts, but I will re-iterate 
this again:  

 1. GDI *and* DirectDraw *can* be used at the same time for the 
primary surface under DirectX. Since the X-server will not be 
flipping this should be perfectly possible.

 2. DirectDraw can be used for some stuff, but not everything is 
available. Specifically DirectDraw does not support hardware line 
drawing, hardware pattern fills or hardware text.

 3. GDI can be used for those specific functions that can't be 
accelerated by DirectDraw, and those functions *will* use the 
hardware. Using the GDI line, pattern fill and text functions will 
blow away any software implementation (sure it won't be as fast as if 
you had native code from the XF86_SVGA server, but it will be faster 
than software).

> As far as DirectX is concerned, I would rather leave this topic to
> our exerts (John and Mike).  I am very confident they would do
> excellent job. 

I am sure they will do a excellent job. However I resent the 
insinuation that I don't know what I am talking about when it comes 
to DirectX. I know what I am talking about because I had done all of 
the DirectX code in our SciTech MGL graphics library; the same 
library that was used to port Quake to Windows, and has been used in 
countless commercial games on the Windows platform.

Perhaps actually *listening* to what I have to say would help you get 
to the ultimate goal of a working DirectX based X-sever in a more 
timely manner?

> Without Cygwin it certainly would not have been possible to port
> the code in xc/programs/Xserver/hw to Win32. 

Sure. But another thrust of my posts is that the code under that 
directory is not useful for the Win32 port anyway. Getting XF86_SVGA 
to compile is not a useful task, because getting it to work is 
fraught with major compatibility problems.

I think you have already found that it simply won't work out of the 
box, given that you have already gotten it compiling and linking.

Regards,

+---------------------------------------------------------------+
|   SciTech Software - Building Truly Plug'n'Play Software!     |
+---------------------------------------------------------------+
| Kendall Bennett          | Email: KendallB@scitechsoft.com    |
| Director of Engineering  | Phone: (530) 894 8400              |
| SciTech Software, Inc.   | Fax  : (530) 894 9069              |
| 505 Wall Street          | ftp  : ftp.scitechsoft.com         |
| Chico, CA 95928, USA     | www  : http://www.scitechsoft.com  |
+---------------------------------------------------------------+