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




> That sounds really cool. All we need to do then is build a chipset
> driver that runs on top of DirectX. I am very familiar with DirectX,
> so I can probably whip that up quickly.

Could you first look into various OS-specific codes in the
Xserver/hw/xfree86/os-support?  That is where most of the work we need to
do.  That is provide those functionalities for Win32 API.

> I thought the X11R6.4 source tree was C code only since it can
> compile for non-intel CPU's? What assembler code is present in the
> code, and is it localised at all? More specifically if the assembler
> code is just in chipset drivers, we can throw those away since we
> don't need that (DirectX becomes the chipset driver).

X11R6.4 is, but not the Xfree86 which is being added by Xfree86 Org.

> Sure, but we don't need *any* of that code to be compiled for the
> Win32 version, since we don't be doing any chipset specific code. All
> the code to talk to the hardware will be going via DirectX.

I think for you would be best to start putting directX support in
Xserver/hw/xfree86/os-support by adding your code to a sub-directory called
win32.  Then for there we start and see waht would need further fix or would
need to be unnecessary.

> Actually the assembler code in XFree86 is supposed to be portable to
> non-GCC compilers, but perhaps it isn't. I thought there was some
> kind of assyntax.h header file that would allow the code to be
> converted into MASM assembler code.

True, but Xfree86 best compiles with GCC and it is known since long time.
Some of the commercial compilers on Linux cannot even handle some of the
dirty X headers... on Win32 MSVC, simply hates the X headers, unless you pay
to Hummingbird and buy their Xceed XDK but then you cannot redistribute your
X code without paying $$ to Hummingbird first.

>
> But like I said, we can probably remove 95% of the assembler code
> problems since a lot of it may just be in the chipset drivers. Unless
> of course gobs of it are in the cfb code?


cfb, mfb and dix etc is not a problem.  That is pure C code and compiles
perfect with GCC.

As far as your comments on GCC 2.95 performance are concerned I think GCC
2.95 can do a better job when porting a UNIX code then commercial compilers.
However Mumit Khan is the GCC Win32 expert and would be a right person to
address you comments.

Regards
Suhaib

>
> 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  |
> +---------------------------------------------------------------+
>


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