RE: XF86SUP.SYS

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

The best way to understand how X access video and I/O ports is to
study
code for different OS in xc/programs/Xserver/hw/xfree86/os-support.
The
code in os-support subdirectory are OS dependent, rest of the
XFree86 code is very much OS independent.

I have Windows driver code. I do not remember from where I got it,
but
it is in public domain.  It allows a very fast access to I/O ports
and it even allows to access I/O ports which Windows by default
prohbits.  I have code of this driver at my home PC and would e-mail
you later today.

Suhaib

> -----Original Message-----
> From: cygwin-xfree-owner@sourceware.cygnus.com
> [mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike
> MacDonald
> Sent: Tuesday, November 09, 1999 10:41 AM
> To: 'Holger Veit'; 'cygwin-xfree@sourceware.cygnus.com'
> Subject: RE: XF86SUP.SYS
>
>
> Ok, you have to forgive me, I'm new to alot of this
> stuff.  What you seem to
> be saying is that the driver is there to provide the same
> interface that X
> expects.  I need, I think, to look at the XFree code
> (which I haven't yet)
> to see what you are talking about.   I'm assuming that a
> straight library
> won't give X access to the ports it needs without
> rewriting alot of the asm
> functions.
>
> How do the ASM functions access the ports?  I guess thats
> what I need to
> find out.  if they just do in and out and the port number
> - then the driver
> has to make sure those port numbers are available to X in
> general?  If thats
> the case, then how did you do that?
>
> I'm not sure, but switching to a full screen mode in
> DirectX might give
> direct access to the ports from X..  If thats the case,
> then it might just
> be a matter of changing modes, and depending on DX for
> the direct video card
> access.
>
> Other than that, I think I see where you are coming from.
>  I need to find
> out what the quickest way to access an IO port in
> Winnt/Win98..  Since
> DirectX was designed to be able to access the video card
> directly, and
> quickly, I'm hoping that it will provide the necessary
> connections.
>
>
> -----Original Message-----
> From: Holger Veit [mailto:Holger.Veit@gmd.de]
> Sent: Tuesday, November 09, 1999 2:49 AM
> To: Mike MacDonald
> Subject: Re: XF86SUP.SYS
>
>
> On Mon, Nov 08, 1999 at 07:10:59PM -0500,
> 	Mike MacDonald wrote:
> > Hi, I'm trying to port your driver to Win98/NT.  After
> looking at it
> > superficially, I can't see why we can't just implement
> this as a library -
> > since WinXX doesn't have the same issues with Ring0 as
> OS/2 seems to.  I'm
> > just wondering if there are other reasons for making it
> a driver.  If
> > persistance is necessary for ptys or something, we can
> just provide a
> > service under Windows..  I think though that even that
> can be handled in a
> > library..
>
> There are specific reasons why this is a driver in OS/2.
> OS/2 has a
> mechanism
> to do I/O in a special ring2 mode, i.e. it is possible to
> declare a
> privileged
> ring2 library with function calls that allow access to
> I/O ports. I believe
> NT has a similar facility. The problem is, that this
> results in a callgate
> transition, not just a simple far call for any inb/outb
> instruction. This
> slows down the call by up to two magnitudes. Speed for
> I/O instructions is
> essential particularly for accelerated video cards;
> you'll likely leave the
> acceleration pipeline of the video card empty with too
> slow access thus
> causing
> significant performance loss. A less important reason is
> that I was
> reluctant
> to rewrite all the assembler code in XFree86 that did I/O
> by assembler
> inlines.
> The PTY stuff has, in conjunction with EMX, another
> important reason to make
> it a character driver: some utilities behave different
> when their stdin or
> stdout is connected to a pipe vs. a character device, see
> the 'ls' output
> as a simple example (multi column in xterm, vs single
> column in 'ls |
> more').
> There is too much code already existing that relies on
> that. It would have
> been
> trivial to implement PTYs in xterm with an OS/2 pipe, but
> this would have
> caused
> real differences in behaviour.
>
> Holger
> --
> If Microsoft is ever going to produce something that does
> not suck,
> it is very likely a vacuum cleaner.
>