This is the mail archive of the
cygwin-xfree@sourceware.cygnus.com
mailing list for the Cygwin project.
RE: Win32 version of XFree86
- To: "Rich Thomson" <rich.thomson@xmission.com>, "Chris Faylor" <cgf@cygnus.com>
- Subject: RE: Win32 version of XFree86
- From: "Suhaib M. Siddiqi" <ssiddiqi@inspirepharm.com>
- Date: Sun, 22 Aug 1999 14:00:27 -0400
- Cc: "Kendall Bennett" <KendallB@scitechsoft.com>, <cygwin-xfree@sourceware.cygnus.com>
- Reply-To: <ssiddiqi@ipass.net>
Your approach is fine with me, if you are willing to do the
DirectX work???
I have sorted out most of the core X11R6.x with MSVC a while ago.
Suhaib
> -----Original Message-----
> From: legalize@mail.xmission.com [mailto:legalize@mail.xmission.com]On
> Behalf Of Rich Thomson
> Sent: Sunday, August 22, 1999 1:05 PM
> To: Chris Faylor
> Cc: Kendall Bennett; Suhaib Siddiqi; cygwin-xfree@sourceware.cygnus.com;
> Rich Thomson
> Subject: Re: Win32 version of XFree86
>
>
>
> Hi,
>
> There isn't any need to cc: me on messages regarding a port of Xfree86
> to Windows. In fact, I've unsubscribed from all xfree86 mailing
> lists.
>
> My interest is in a DirectX based server, not a port of Xfree86. I
> just don't think a port of xfree86 is the best path to a DirectX X
> server. I think you will get a better server by starting with the
> X11R6.4 sample server code and starting with a very simple X server hw
> layer that just pushes spans to the DirectDraw code.
>
> The X server is already plenty portable enough on its own for things
> like the necessary O/S services. Everything in the core X server code
> is written very portably. You may need to adjust the imake environment
> to suit newer compiler switches and so-on, but you should not need to
> make any changes to the X server core code. The X library code has
> already been built on Win32, so some Win32 environment support is
> already present in X. I believe they punted on xterm because of its
> pty usage, but it is a special case. Perhaps you could get xterm
> compiled with gcc/cygwin. At any rate, I'm more interested in a server
> before xterm.
>
> The difficulty in a Win32 non-DirectX X server in the past has had to
> do with the way resources are shared under X and under Windows. The
> two are not very compatible when it comes to things like colormap
> management and focus management and so-on. Trying to make top-level X
> client windows look like Win32 app client windows is annoying and
> tedious.
>
> DirectX lets you do away with GDI and take over the screen, which is
> exactly what an X server wants to do when it starts. No hw-specific
> drivers are needed because you rely on DirectDraw to provide the device
> abstraction. The X sample server is coded to handle memory-mapped
> frame buffers quite efficiently all in software. From a basic working
> server you begin optimizing higher-level requests from there.
>
> That is the X server I'm interested in making. Since a DX-based server
> wouldn't need any of xfree86/hw code, all that code just goes away.
> But wait, you just threw out 90% of the xfree86 server effort. Is
> there any reason to keep the remaining 10%? The remaining 10% of code
> consists of startup/shutdown code, font code, input device code, and
> the OS layer code. All of this code in xfree86 is from a unix
> viewpoint, so it must be changed anyway for a Win32 DirectX based X
> server.
>
> The startup/shutdown code can't be used from xfree86 because device
> management is totally different under Windows.
>
> The X server only requires a few routines for supporting the basic
> keyboard and mouse events and a few more for extension devices (like a
> gamepad/joystick). We can use Windows event mechanism, or use
> DirectInput for device input. Either way, we can't use the xfree86
> code.
>
> The font code is probably stock X server font code, which means it
> can't take advantage of Windows fonts. Eventually you'd like to be
> able to take advantage of Windows installed fonts for a DirectX based
> server, so you'd need to adjust the font code.
>
> The OS layer code is easy to supply for native Win32. For several of
> the functions, you can use the unix equivalent just fine on Win32
> (things like opening files, opening socket connections, etc).
>
> So, in the end, you can't hardly use any of the xfree86 code in a very
> useful way for a native Win32 directX-based X server. The part of the
> code that you can reuse comes from the core sample server, not from
> xfree86.
>
> If you tried to use the xfree86 code, you have to deal with the way it
> wants to talk directly to all the different hardware out there. The
> core X server itself isn't coded this way, the xfree86 portions of it
> are. The xfree86 portions include assembly code, unix-oriented I/O
> code, unix-oriented device management code. For a DirectX server these
> are replaced with DirectDraw and Win32.
>
> So in the end I came to the conclusion that trying to port Xfree86
> would be more work than just porting the core sample server itself.
> This is usually not the case, because normally you don't have a
> HW-independent abstraction beneath you when porting the X server.
> Usually you have to do what Xfree86 has done and support the different
> hardware directly. Its tedious, cumbersome and *lots* of code for the
> amount of hardware in the PC world today.
>
> But with a DirectX PC, MS and the hardware vendor have already provided
> the abstraction that takes away the complexity of the hardware.
>
> You are, of course, free to pursue your own direction. However, I am
> more interested in making the X server I've described in this message.
>
> -- Rich
>