This is the mail archive of the cygwin-xfree@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Win32 version of XFree86


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
> 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]