From: lhall AT rfk DOT com (Larry Hall)
Subject: Re: server X
24 Sep 1998 11:53:41 -0700
Message-ID: <3.0.5.32.19980923154741.00a05ce0.cygnus.gnu-win32@pop.ma.ultranet.com>
References: <001201bde6b5$dae0da40$1f105c18 AT B0B>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: "GoatCheez" <gcheez AT tampabay DOT rr DOT com>, "Jeff Sturm" <jsturm AT sigma6 DOT com>,
        "David Fox" <dsfox AT cogsci DOT ucsd DOT edu>
Cc: <gnu-win32 AT cygnus DOT com>

The problem is DirectX versions don't get updated on NT with the same
alacrity that they do on 9x.  I think the currently supported(?) version
is DirectX 3 on NT.  Here is one place where capabilities in 9x outstrip
those in NT!  So a DirectX approach will not allow an XFree86 "port" to 
address the need of both 9x and NT users at this time...

Larry Hall                              lhall AT rfk DOT com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02482-7797               http://www.rfk.com

At 10:48 PM 9/22/98 -0700, GoatCheez wrote:
>    In the most recent version of DirectX (6), another version of DirectDraw
>was implemented(4). This version allows the locking and unlocking of a video
>surface without the rest of the windows system to stop... in other words,
>accessing the cideo memory directly isn't as scary as it previously was.
>Before, when someone would lock the video memory, the entire cpu would give
>access to only that program running, which made all other applications cease
>untill the surface was unlocked. It was done for backwards compatablility or
>something, but in DirectX6 there's an option to allow the system to respond
>normally. The old system would also not allow debugging because the debugger
>wouldn't be running then the surface was locked. A DirectX  X server would
>be a good idea. The only thing needed is some DirectX programmers that are
>willing to port the XFree86 code... I know a little DirectDraw and would be
>willing to help, but we would need a lot more.
>
>GoatCheez
>gcheez AT tampabay DOT rr DOT com
>
>-----Original Message-----
>From: Jeff Sturm <jsturm AT sigma6 DOT com>
>To: David Fox <dsfox AT cogsci DOT ucsd DOT edu>
>Cc: <gnu-win32 AT cygnus DOT com>
>Date: Tuesday, September 22, 1998 7:30 PM
>Subject: Re: server X
>
>
>>David Fox wrote:
>>> Sergey Okhapkin <sos AT prospect DOT com DOT ru> writes:
>>> > Porting _Xfree86_ to win32 is a bad idea, because Xfree86 requires
>direct
>>> > video hardware access.
>>>
>>> Could you expand on this further?  Why is direct video hardware access
>>> more of a problem under windows than it is under Unix?
>>
>>(A small clarification to Sergey's post: XFree86 is designed for video
>>framebuffer access.  It need not access video registers directly.
>>Recent work in Linux for example has moved video drivers out of X and
>>into the kernel; X opens the display via the /dev/fb device.)
>>
>>The big difference is that under Unix, the X server controls the entire
>>display.  Under Win32 however, X has to cooperate with the native window
>>subsystem.  I think that precludes an X server from accessing video
>>memory from Win32 (does anyone know otherwise?).  It may be able to
>>write to backing store... I'm not sure if this is better (easier or more
>>efficient, that is) than just translating X drawing requests into GDI
>>requests.
>>
>>If it turns out that the "virtual framebuffer" technique is feasible,
>>I'd contend that the XFree86 source is a better starting point than
>>TOG's X11R6.4, since they have cleaned up and fixed a lot of the cfb
>>code.
>>
>>--
>>Jeff Sturm
>>jsturm AT sigma6 DOT com
>>-
>>For help on using this list (especially unsubscribing), send a message to
>>"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
>
>-
>For help on using this list (especially unsubscribing), send a message to
>"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
>
>
Larry
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".