RE: FW: Win32 XServer

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

Hi john,


>
>
> Most of the discussion here deals with writtng directly
> to the primary
> screen.  This is a bad idea because of the mutex-locking.
>  This is the
> reason I write to a back-buffer and blit to the primary.
> The primary is
> locked for a very short time while the blit is happening.
>
> There has to be message handling in order to make this work with
> windows.  My stuff has this.
>
> As for keyboard/mouse input,  this is raw data, which has to be
> translated.  Shouldn't be a big deal.


Mouse can be handle in XF86 by compiling
with -DMOUSE_PROTOCOL_IN_KERNEL.

This allows XF86 to use system mouse, instead of having mouse
entries
in XF86COnfig file.

>
> There seems to be a lot of negativity towards this
> project from others.
> I'm not saying everything will be perfect first time, but
> some of the
> responses are almost rude..


John,  please ignore those messages. I have a few mentioned on the
list that people should consider contributing instead of only
debating which driver to write and attempting to impose their
opinions through repeated
mails. I appreciate your help and I think
many other users do too.  You are doing a great job with DirectX
support.

Thanks
Suhaib


>
> John
>
> Suhaib Siddiqi wrote:
>
> > 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
|
> >
+---------------------------------------------------------------+
> >