This is the mail archive of the cygwin@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: server X


    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@tampabay.rr.com

-----Original Message-----
From: Jeff Sturm <jsturm@sigma6.com>
To: David Fox <dsfox@cogsci.ucsd.edu>
Cc: <gnu-win32@cygnus.com>
Date: Tuesday, September 22, 1998 7:30 PM
Subject: Re: server X


>David Fox wrote:
>> Sergey Okhapkin <sos@prospect.com.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@sigma6.com
>-
>For help on using this list (especially unsubscribing), send a message to
>"gnu-win32-request@cygnus.com" with one line of text: "help".

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


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