This is the mail archive of the cygwin-xfree@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: FW: XF86SUP.SYS


Mike MacDonald <mmacdona@tsi.gte.com> wrote:

> Hello again.  I have some other questions.  How does X change
> video modes? I see where you get the vidmem, but not where the
> graphics mode is actually set on the card.  

Internally XFree86 is rather complicated in the way that it sets the 
display mode. Basically the mechanism is that a function fills in a 
'register' structure that contains the complete state for the 
hardware when a mode is set. Then the Save/Restore functions are used 
to actually copy all the register values from the structure and 
program the hardware. In the case of save the S3 Virge driver 
(vga256\drivers\s3v\), the functions are in the s3v_driver.c module. 
The code is the S3VRestore (which programs the actual hardware) and 
the S3VSave (for VT switches). The function that fills in the 
register structure is the S3VInit function.

> I can use directx to get a pointer to memory, but I would have to
> use directx to set the video mode I think. 

Yes, you definately need to be using DirectX to set the graphics 
mode; you can't let XFree86 do this without causing major problems.

> I have a sinking feeling that X is setting the video mode through
> the io ports on the card, which meens I prolly can't use direct x,
> and need to switch to fullscreen mode if I can, and map the memory
> over. 

Yes, XF86_SVGA sets the graphics mode directly through I/O ports 
writes to the hardware. Unfortunately there is no such thing as a 
'fullscreen' mode under Win32 (something OS/2 has however which is 
used by XFree86/2). The only solution is to follow the guidelines I 
posted in my other email.

> Unfortunately that makes it more difficult to display X in a
> window which would be nice.  

The only way you will be able to get a seamless X server working 
under Win32 is to use DirectX, and either draw directly to the window 
surface (make sure you honor the attached clip regions however!) or 
use DirectX functions (or GDI functions) to do the drawing. It is 
simply not feasible to have your own code draw directly to the 
hardware. If you try this, you will need to deal with mutual 
exclusion to the hardware as you can't have your code get task 
switched away from while you are halfway through drawing a rectangle, 
and then have some other code (say the Windows driver) start another 
graphics command.

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  |
+---------------------------------------------------------------+


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