From: gcheez AT tampabay DOT rr DOT com (GoatCheez) Subject: Re: server X 23 Sep 1998 10:06:20 -0700 Message-ID: <001201bde6b5$dae0da40$1f105c18.cygnus.gnu-win32@B0B> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit To: "Jeff Sturm" , "David Fox" Cc: 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 To: David Fox Cc: Date: Tuesday, September 22, 1998 7:30 PM Subject: Re: server X >David Fox wrote: >> Sergey Okhapkin 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".