FW: Win32 XServer

["Suhaib Siddiqi" <ssiddiqi at inspirepharm dot com>]

Mike

Below is one response to your suggestions about Video for XF86.

Suhaib


> -----Original Message-----
> From: owner-devel@XFree86.Org
> [mailto:owner-devel@XFree86.Org]On Behalf
> Of Kendall Bennett
> Sent: Monday, November 15, 1999 11:38 PM
> To: devel@XFree86.Org
> Subject: Re: FW: Win32 XServer
>
>
> "Tim Roberts" <timr@probo.com> wrote:
>
> [Most of this is actually a reply to the original poster, not Tim
> Roberts]
>
> > >> do a lock in xf86MapVidMem
> > >>
> > >> do an unlock in xf86UnMapVidMem
> > >>
> > >> I don't know if those sync up to work, (I'm not sure when
> > >> X calls those  functions) but thats my current thinking..
> >
> > As far as I know, xf86[Un]MapVidMem get called exactly once per
> > session, when the server starts and ends.
>
> Lock and Unlock in DirectX will take the Win16Mutex, an
> will cause
> all multi-tasking to grind to a halt while you have the surface
> locked under Windows 9x. Hence this is a very bad idea.
> You will need
> to have the locking done at a much lowever granuality
> than this. The
> only real way to make this work properly under Windows 9x
> is pretty
> much to do surface locking on a per-primitive basis, or
> the OS just
> falls apart.
>
> > The major disadvantage to the DirectX full-screen
> solution is that
> > it prohibits co-locating X windows and Windows windows
> on the same
> > screen.  One would be required to Alt-Tab into the X session,
> > which would take over and repaint the entire desktop.  Windows
> > would be locked out until we Alt-Tabbed away.  Compare this to
> > solutions like Hummingbird or PC-Xware, where you can have an
> > Xterm and a DOS window side-by-side.  That's the expected user
> > experience.
>
> This has been discussed before, and three points always come up:
>
>  1. Lot of people have mentioned that Win32 users who run
> X apps run
> them most of the time in a fullscreen X session (so you
> can have a
> real window manager and the like).
>
>  2. OS/2 does things this way with XFree86/2, and the OS/2 users
> think it works great ;-)
>
>  3. They have to walk before they can run. Although a
> Win32 seamless
> X-server would be everyones dream, a fullscreen one is a
> hell of a
> lot easier to get going ;-)
>
> > If you're really DirectX fullscreen, you won't have the
> benefit of
> > GDI.  It would all be raw writes to the surface.
>
> Actually since the Win32 X-server will not be using
> anything except
> the primary surface (ie: it is not a game and hence not
> double/triple
> buffering), then GDI can be used for all drawing on the primary
> surface. For offscren surfaces (ie: pixmaps etc) then GDI
> cannot be
> used, however DirectDraw does have accelerated solid
> fills and bitblt
> operations (MS says it does pattern fills also, but I have never
> gotten that to work ;-).
>
> > >> For the accelerated, I'm going to try using/modifying
> > >> mapmem to provide memory mapping functionality, and
> > >> getio for port access.
> >
> > Here be dragons.  Since the display driver will already have
> > claimed the frame buffer, register, and i/o spaces, you
> would have
> > to modify mapmem and getio to grab the space without
> claiming it.
> > That can be done, but it's slimy.
>
> Mapping MMIO registers and gaining IOPL for the X-server
> is the easy
> part. Getting the X-server to co-exist with Windows is
> the hard part,
> and I seriously doubt it will be possible to do that at all. Why?
> Because under DirectX you don't have the options of
> controlling what
> happens when a user switches away from your app; DirectX does the
> switch, and then the next time you try to access a surface (via a
> Lock, BitBlt etc) you get a 'Surface Lost' error!
> Horrible, but that
> is how it is done. Not also that DirectX and XFree86 have
> different
> ideas about how offscreen memory should be managed, and
> the XFree86
> driver will not be able to take over all the offscreen memory for
> it's own purposes (not without royally screwing up the
> Windows driver
> that is!).
>
> Couple that with the fact that the X-server will be
> programming the
> graphics hardware the way it wants it to be programmed,
> which in many
> cases will have subtle but devastating differences to the Windows
> drivers, and you have a major problem! You can probably get it to
> work with a couple of chipsets, but making it work with
> all supported
> drivers will be really hard. I know this because we are doing
> something very similar in our DirectDraw stereo drivers
> (we do direct
> to hardware blits in a window to speed up some stuff that
> DirectX is
> dog slow at), and so far we have had to do quite a bit of
> fine tuning
> to get it to work (and we are only doing blits and solid fills,
> without any offscreen memory caching!).
>
> > Further, you're talking about communicating directly with the
> > graphics hardware without the knowledge of the existing Windows
> > driver.  This is going to lead to Badness of the First Degree.
> > The driver is still active, even in DirectX exclusive mode.  It
> > will be making assumption about the state of the hardware which
> > you cannot possibly know.  I believe there is little point in
> > trying to exploit any of the existing XAA drivers in a Win32
> > solution.
>
> Nice to know someone else agrees with me. I have actually
> mentioned
> this on number occasions to Suhaib and the others folks
> on the Cygwin
> mailing list. But if they want to go ahead and try it, go right
> ahead. I know what the end result will be, but I guess
> some people
> want to find out for themselves (which is perfectly fine for
> experimentation purposes; that is how I figured it all
> out after all
> ;-).
>
> > >> For mouse, keyboard, ttys - mapmem, and getio.
> >
> > The same comments apply here.  You're talking about mucking
> > directly with the hardware without the knowledge of the existing
> > Windows drivers, which will still be running.
>
> Yep, and in fact you simply cannot do that under Windows.
> No matter
> what you do you won't be able to directly program the mouse and
> keyboard. Instead you will need to write X event wrapper layers
> around DirectInput and/or the regular Win32 message queue.
>
> > I believe you will have to concoct a user-mode layer which
> > installs "hooks" to trap the existing keyboard/mouse
> messages.  I
> > think you'll find this is the approach used by all the competing
> > solutions.
>
> DirectInput does all that stuff for you these days...
>
> 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  |
> +---------------------------------------------------------------+
>