From ssiddiqi@inspirepharm.com Mon Nov 1 05:58:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Mon, 01 Nov 1999 05:58:00 -0000 Subject: X11R6.x libs Message-ID: I have removed X11R6.x developments tools from my URLS at http://siddiqi.webjump.com and http://www.geocities/ResearchTriangle/Forum6298 . The X11R6.x developments tools are now available ONLY from http://sourceware.cygnus.com/cygwin/xfree (Cygwin-xfree). This is to avoid confusions ater Cygwin v 1.0 was released. 3 different versions of X11 are available: X11R6.3 from XFRee86 3.3.5 for Cygwin B20.1 X11R6.4 for Cygwin B20.1 (derived from XFree86 3.9.16) X11R6.4 for Cygwin v 1.0 (Cygwin Cd Distribution) (derived from XFree86 3.9.16 - XFree86 4.0 Developers Snapshots). The Cygwin-xfree URL (hhtp://sourceware.cygnus.com/cygwin/xfree) now has a FAQ. Suhaib PS: Sorry for duplicate message. I am cc'ing to Cygwin List for users who are not yet aware of Cygwin-xfree project. From mmacdona@tsi.gte.com Mon Nov 1 06:32:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Mon, 01 Nov 1999 06:32:00 -0000 Subject: X11R6.x libs Message-ID: What is better? getting the cd, or just downloading all the latest stuff? -----Original Message----- From: cygwin-owner@sourceware.cygnus.com [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of Suhaib Siddiqi Sent: Monday, November 01, 1999 8:55 AM To: Cygwin@Sourceware.Cygnus.Com Cc: Cygwin-Xfree@Sourceware.Cygnus.Com Subject: X11R6.x libs I have removed X11R6.x developments tools from my URLS at http://siddiqi.webjump.com and http://www.geocities/ResearchTriangle/Forum6298 . The X11R6.x developments tools are now available ONLY from http://sourceware.cygnus.com/cygwin/xfree (Cygwin-xfree). This is to avoid confusions ater Cygwin v 1.0 was released. 3 different versions of X11 are available: X11R6.3 from XFRee86 3.3.5 for Cygwin B20.1 X11R6.4 for Cygwin B20.1 (derived from XFree86 3.9.16) X11R6.4 for Cygwin v 1.0 (Cygwin Cd Distribution) (derived from XFree86 3.9.16 - XFree86 4.0 Developers Snapshots). The Cygwin-xfree URL (hhtp://sourceware.cygnus.com/cygwin/xfree) now has a FAQ. Suhaib PS: Sorry for duplicate message. I am cc'ing to Cygwin List for users who are not yet aware of Cygwin-xfree project. -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com From sssiddiqi@ipass.net Mon Nov 1 06:35:00 1999 From: sssiddiqi@ipass.net (Suhaib Siddiqi) Date: Mon, 01 Nov 1999 06:35:00 -0000 Subject: X11R6.x libs References: Message-ID: Your choice! CD has some very cool stuff and I would certainly recommend it. BTW. Cd has no X11R6.x on it, you will still need to download it. Suhaib > -----Original Message----- > From: cygwin-owner@sourceware.cygnus.com > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > Mike MacDonald > Sent: Monday, November 01, 1999 9:32 AM > To: 'Suhaib Siddiqi'; 'Cygwin@Sourceware.Cygnus.Com' > Cc: 'Cygwin-Xfree@Sourceware.Cygnus.Com' > Subject: RE: X11R6.x libs > > > What is better? getting the cd, or just downloading all > the latest stuff? > > -----Original Message----- > From: cygwin-owner@sourceware.cygnus.com > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > Suhaib Siddiqi > Sent: Monday, November 01, 1999 8:55 AM > To: Cygwin@Sourceware.Cygnus.Com > Cc: Cygwin-Xfree@Sourceware.Cygnus.Com > Subject: X11R6.x libs > > > > > I have removed X11R6.x developments tools from my URLS at > http://siddiqi.webjump.com and > http://www.geocities/ResearchTriangle/Forum6298 . > > The X11R6.x developments tools are now available ONLY from > http://sourceware.cygnus.com/cygwin/xfree > (Cygwin-xfree). This is to avoid confusions ater Cygwin v 1.0 was > released. > > 3 different versions of X11 are available: > X11R6.3 from XFRee86 3.3.5 for Cygwin B20.1 > > X11R6.4 for Cygwin B20.1 (derived from XFree86 3.9.16) > > X11R6.4 for Cygwin v 1.0 (Cygwin Cd Distribution) (derived from > XFree86 3.9.16 - XFree86 4.0 Developers Snapshots). > > The Cygwin-xfree URL > (hhtp://sourceware.cygnus.com/cygwin/xfree) now > has a FAQ. > > > Suhaib > > > PS: Sorry for duplicate message. I am cc'ing to Cygwin List for > users > who are not yet aware of Cygwin-xfree project. > > > -- > Want to unsubscribe from this list? > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > > -- > Want to unsubscribe from this list? > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > From mmacdona@tsi.gte.com Mon Nov 1 07:17:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Mon, 01 Nov 1999 07:17:00 -0000 Subject: Eterm Message-ID: Well, It doesn't look like something easy for me to chop out.. Here's the error I'm getting, and the piece of code: ERROR: ---------------------------------------------------------------------------- --------------------------------------------------------- Program received signal SIGSEGV, Segmentation fault. 0x40abd9 in Create_Windows (argc=1, argv=0xa041380) at command.c:5454 5454 for (i = 0; i < (Xdepth <= 2 ? 2 : NRS_COLORS); i++) { ---------------------------------------------------------------------------- --------------------------------------------------------- CODE: ---------------------------------------------------------------------------- --------------------------------------------------------- /* * grab colors before netscape does */ for (i = 0; i < (Xdepth <= 2 ? 2 : NRS_COLORS); i++) { XColor xcol; unsigned char found_color; if (!rs_color[i]) continue; if (!XParseColor(Xdisplay, Xcmap, rs_color[i], &xcol)) { print_warning("Unable to resolve \"%s\" as a color name. Falling back on \"%s\".", rs_color[i], def_colorName[i] ? def_colorName[i] : "(nil)"); rs_color[i] = def_colorName[i]; if (!rs_color[i]) continue; ---------------------------------------------------------------------------- --------------------------------------------------------------------------- From ssiddiqi@inspirepharm.com Mon Nov 1 07:26:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Mon, 01 Nov 1999 07:26:00 -0000 Subject: Eterm References: Message-ID: No idea. Which version of X11R6.x? version of Cygwin? Does it need MOTIf libs too? Looks to me a Widget problem. You need to fix the code. I noticed *netscape* in the code. Mozilla does have problems with LessTif. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Monday, November 01, 1999 10:17 AM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: Eterm > > > Well, It doesn't look like something easy for me to chop > out.. Here's the > error I'm getting, and the piece of code: > > ERROR: > > ---------------------------------------------------------- > ------------------ > --------------------------------------------------------- > Program received signal SIGSEGV, Segmentation fault. > 0x40abd9 in Create_Windows (argc=1, argv=0xa041380) at > command.c:5454 > 5454 for (i = 0; i < (Xdepth <= 2 ? 2 : NRS_COLORS); i++) { > ---------------------------------------------------------- > ------------------ > --------------------------------------------------------- > > CODE: > > ---------------------------------------------------------- > ------------------ > --------------------------------------------------------- > /* > * grab colors before netscape does > */ > for (i = 0; i < (Xdepth <= 2 ? 2 : NRS_COLORS); i++) { > > XColor xcol; > unsigned char found_color; > > if (!rs_color[i]) > continue; > > if (!XParseColor(Xdisplay, Xcmap, rs_color[i], &xcol)) { > print_warning("Unable to resolve \"%s\" as a color > name. Falling back > on \"%s\".", > rs_color[i], def_colorName[i] ? > def_colorName[i] : > "(nil)"); > rs_color[i] = def_colorName[i]; > if (!rs_color[i]) > continue; > > ---------------------------------------------------------- > ------------------ > ---------------------------------------------------------- > ----------------- > From mmacdona@tsi.gte.com Mon Nov 1 08:15:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Mon, 01 Nov 1999 08:15:00 -0000 Subject: Eterm Message-ID: Ok, I'm giving up on Eterm for a while.. I cleared up that seg fault, but it knocked down to another line that got another segfault for different reasons. Looks like X stuff too.. Mebbe later when I have time I'll try to get with you on what is causing these probs.. -----Original Message----- From: cygwin-xfree-owner@sourceware.cygnus.com [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Suhaib Siddiqi Sent: Monday, November 01, 1999 10:22 AM To: cygwin-xfree@sourceware.cygnus.com Subject: RE: Eterm No idea. Which version of X11R6.x? version of Cygwin? Does it need MOTIf libs too? Looks to me a Widget problem. You need to fix the code. I noticed *netscape* in the code. Mozilla does have problems with LessTif. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Monday, November 01, 1999 10:17 AM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: Eterm > > > Well, It doesn't look like something easy for me to chop > out.. Here's the > error I'm getting, and the piece of code: > > ERROR: > > ---------------------------------------------------------- > ------------------ > --------------------------------------------------------- > Program received signal SIGSEGV, Segmentation fault. > 0x40abd9 in Create_Windows (argc=1, argv=0xa041380) at > command.c:5454 > 5454 for (i = 0; i < (Xdepth <= 2 ? 2 : NRS_COLORS); i++) { > ---------------------------------------------------------- > ------------------ > --------------------------------------------------------- > > CODE: > > ---------------------------------------------------------- > ------------------ > --------------------------------------------------------- > /* > * grab colors before netscape does > */ > for (i = 0; i < (Xdepth <= 2 ? 2 : NRS_COLORS); i++) { > > XColor xcol; > unsigned char found_color; > > if (!rs_color[i]) > continue; > > if (!XParseColor(Xdisplay, Xcmap, rs_color[i], &xcol)) { > print_warning("Unable to resolve \"%s\" as a color > name. Falling back > on \"%s\".", > rs_color[i], def_colorName[i] ? > def_colorName[i] : > "(nil)"); > rs_color[i] = def_colorName[i]; > if (!rs_color[i]) > continue; > > ---------------------------------------------------------- > ------------------ > ---------------------------------------------------------- > ----------------- > From mmacdona@tsi.gte.com Mon Nov 1 14:25:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Mon, 01 Nov 1999 14:25:00 -0000 Subject: Gimp Message-ID: Well, I got gimp to compile (it compiles without modification) It loads bmp fine, but I gotta fix my libjpg, but it is cool though!! From ssiddiqi@inspirepharm.com Tue Nov 2 04:03:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Tue, 02 Nov 1999 04:03:00 -0000 Subject: DirectX and XFree86 References: Message-ID: Nope, DGA is only for XFree86 3.3.5, not even for 3.3.6 (wich will be relased end of this month) and 4.0. And it works only with Glide2x SDK. The DGA issue was discussed in details yesterday at XFree86 Developers list. The DGA will not function on Win32 the way it does on Linux. John Fortin notified me that he was working on DirectX Input code for XGGI. Due to John Fortin efforts, we will have XGGI bases X-server ready in the near future. The Devices drivers for Windows, which XFree86 folks prefer too will take time. Suhaib > -----Original Message----- > From: Federico Bianchi [ mailto:bianchi@pc-arte2.arte.unipi.it ] > Sent: Tuesday, November 02, 1999 2:45 AM > To: Suhaib Siddiqi > Subject: DirectX and XFree86 > > > > It is not easy at all. It might become quite a bit easier > with the new > release, though, thanks to the DGA layer (that's why I > talked about a DGA > -> DirectX 3 shim). > > The more I look at Direct X, the messier it looks to me, though. > > Best regards again > Federico Bianchi > Dipartimento di Storia delle Arti > Universita` degli Studi di Pisa > p.zza S.Matteo in Soarta, 2 - 56127 > Pisa (Italy) > tel. +39-050-587111 (cent.), > +39-050-587224 (uff.) > fax. +39-050-580128; e-mail: > > > =================================================== > !DISCLAIMER!: my e-mail reflects > _my_own_ opinions! > > =================================================== > > From ssiddiqi@inspirepharm.com Tue Nov 2 04:19:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Tue, 02 Nov 1999 04:19:00 -0000 Subject: XFree86 4.0 References: Message-ID: the URL is www.xfree86.org for public snapshots, which are usually a month behind. The most up-to-date XFree86 4.0 Developers snapshots are password protected, for which I am not allowed to give access to people who are not members of XFree86 Developers group, sorry. The comments for DGA in my previous message were from Daryl, author of DGA. Regards Suhaib > -----Original Message----- > From: Federico Bianchi [ mailto:bianchi@pc-arte2.arte.unipi.it ] > Sent: Tuesday, November 02, 1999 7:35 AM > To: Suhaib Siddiqi > Subject: XFree86 4.0 > > > > Looks like I'll have to download the latest XFree86 4.0 > snapshot. Might > you please send me the proper URLs? > > I know there is some V86 support for INT 10h in some > (internal?) snapshot, > probably enough to use the needed AH=4Fh calls. > > Thanks in advance, and sorry for bothering you > > Federico Bianchi > Dipartimento di Storia delle Arti > Universita` degli Studi di Pisa > p.zza S.Matteo in Soarta, 2 - 56127 > Pisa (Italy) > tel. +39-050-587111 (cent.), > +39-050-587224 (uff.) > fax. +39-050-580128; e-mail: > > > =================================================== > !DISCLAIMER!: my e-mail reflects > _my_own_ opinions! > > =================================================== > > From sssiddiqi@ipass.net Tue Nov 2 12:08:00 1999 From: sssiddiqi@ipass.net (Suhaib Siddiqi) Date: Tue, 02 Nov 1999 12:08:00 -0000 Subject: X11R6.x libs References: <0.52791aa8.2550911d@aol.com> Message-ID: Can you provide more details? I use Exceed 6.1 and the libs were tested before releasing them. This seems to X server not accepting X socket connections??? > waiting for X server to begin accepting connections . A while ago someone mailed me problems with ReflectionX and it turns out that the issue was ReflectionX configuration. I need the X server log files. I have no idea where ReflectionX creates them because I have never used it. You need to find it and send me your X-server log file. Which application you were using? Have you TCP/IP installed? The X requires a TCP/IP insatlled and localhost 127.0.0.1:0 in your /etc/hosts directory defined. On Windows Nt /etc/hosts entry are in /Winnt/system32/drivers/etc/hosts, that is where RefelectionX would search for /etc/hosts file, unless ReflectionX folks has some weird configuration files. Regards Suhaib I have moved this discussion to cygwin-xfree list. > -----Original Message----- > From: cygwin-owner@sourceware.cygnus.com > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > Dtcohen@aol.com > Sent: Tuesday, November 02, 1999 2:10 PM > To: cygwin@sourceware.cygnus.com > Cc: Dtcohen@aol.com > Subject: Re: X11R6.x libs > > > Suhaib and/or other interested parties, > > I am having trouble with the "X11R6.4 for Cygwin v 1.0" > download you > mention below. When I try to start up X-windows with > Reflection X, > I get the following error messages: > > _X11TransSocketOpen: socket() failed for local > _X11TransSocketOpenCOTSClient: Unable to open socket for local > _X11TransOpen: transcript open failed for local/JGRISHAW-NTHOME:0 > > waiting for X server to begin accepting connections . > _X11TransSocketOpen: socket() failed for local > _X11TransSocketOpenCOTSClient: Unable to open socket for local > _X11TransOpen: transcript open failed for local/jgrishaw-nthome:0 > . > _X11TransSocketOpen: socket() failed for local > _X11TransSocketOpenCOTSClient: Unable to open socket for local > _X11TransOpen: transcript open failed for local/jgrishaw-nthome:0 > . > etc > etc > etc > > This used to work fine with Sergey's X11R6.4 binaries and the > Cygwin B20.1 release. Any ideas how to fix this? > > I am running Windows NT 4.0 SP3 and Cygwin v1.0 from the CD-ROM. > > Many thanks, > > Jim Grishaw. > > > > I have removed X11R6.x developments tools from my URLS at > > http://siddiqi.webjump.com and > > http://www.geocities/ResearchTriangle/Forum6298 . > > > > The X11R6.x developments tools are now available ONLY from > > http://sourceware.cygnus.com/cygwin/xfree > > (Cygwin-xfree). This is to avoid confusions ater Cygwin > v 1.0 was > > released. > > > > 3 different versions of X11 are available: > > X11R6.3 from XFRee86 3.3.5 for Cygwin B20.1 > > > > X11R6.4 for Cygwin B20.1 (derived from XFree86 3.9.16) > > > > X11R6.4 for Cygwin v 1.0 (Cygwin Cd Distribution) (derived from > > XFree86 3.9.16 - XFree86 4.0 Developers Snapshots). > > > > The Cygwin-xfree URL > (hhtp://sourceware.cygnus.com/cygwin/xfree) now > > has a FAQ. > > > > > > Suhaib > > > > > > -- > Want to unsubscribe from this list? > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > From ssiddiqi@inspirepharm.com Wed Nov 3 04:58:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Wed, 03 Nov 1999 04:58:00 -0000 Subject: X11R6.x libs Message-ID: Jim, Could you please verify the following regarding X11R6.x problems you had with ReflectionX? 1) Were the errors you reported relates to using XTERM.exe? 2) Or, was it one of your application you compiled with Cygwin B20.1 and now attempting to use on Cygwin v 1.0 CD Release? 3) Did adding /etc/hosts entry help? I found a few socket related bugs in libX11.dll but I am not really sure they were the cause of problems you reported. I could use Xterm and all the clients from cygwin-xfree-4.0-cygwin-v-1.tar.bz2 with Exceed server. The Clients work fiune for me with Cygwin v 1.0 and also Cygwin Developemnt Snapshots. Xterm may give the following warnings: bash-2.03$ ./xterm Warning: locale not supported by C library, locale unchanged Warning: locale not supported by Xlib, locale set to C Warning: X locale modifiers not supported, using default Failed to open input method This is because xterm code in XFree86 4.0 has changed and it uses some X Input routines from XFree86 4.0. These warnings are due to the fact we still do not have XFree86 X-server. However, these are harmless warnings and should not cause a crash or _X11TransSock Errno. Suhaib From Dtcohen@aol.com Wed Nov 3 13:25:00 1999 From: Dtcohen@aol.com (Dtcohen@aol.com) Date: Wed, 03 Nov 1999 13:25:00 -0000 Subject: X11R6.x libs Message-ID: <0.c7f06dad.2552022c@aol.com> Suhaib, Thanks for getting back to me with your suggestions. Unfortunately modifying the hosts files does not seem to work. Just to be sure that my system was indeed set up correctly, last night I downloaded X11R6.4 from ftp.x.org, applied the 3 fixes, applied Sergey's patch, compiled/installed. The compile wasn't perfect, but at least X came up OK with no problems connecting to the server. This, plus the fact that Arlindo da Silva's X11R6.4 compile for B20.1 seems to work fine leads me to wonder if there is some sort of problem with your compile. Or is there some other black magic to get it to work? Arlindo da Silva's X11R6.4 seems to be rock solid, even on Cygwin v1.0 (CD). However, I can't compile ("_ctype_" link problem with the Cygwin B20.1-compiled X11 libraries). If I can't get X11 running I might have to go back to B20.1, so I greatly appreciate the time you are spending on this. Below are detailed responses to your e-mails. Thanks again, Jim Grishaw. > Jim, > > Could you please verify the following regarding X11R6.x problems you > had > with ReflectionX? > > 1) Were the errors you reported relates to using XTERM.exe? No, I hadn't gotten to xterm.exe yet. > > 2) Or, was it one of your application you compiled with Cygwin B20.1 > and now attempting to use on Cygwin v 1.0 CD Release? No, Cygwin B20.1 has been completely removed. I made sure that da Silva's X11R6.4 for B20.1 was gone. > > 3) Did adding /etc/hosts entry help? Thanks for the suggestion but it didn't help > > I found a few socket related bugs in libX11.dll but I am not > really sure they were the cause of problems you reported. Hmm... sounds suspicious. > I could use Xterm and all the clients from > cygwin-xfree-4.0-cygwin-v-1.tar.bz2 with Exceed server. The Clients > work fiune for me with Cygwin v 1.0 and also Cygwin Developemnt > Snapshots. Excellent > Xterm may give the following warnings: > > bash-2.03$ ./xterm > Warning: locale not supported by C library, locale unchanged > Warning: locale not supported by Xlib, locale set to C > Warning: X locale modifiers not supported, using default > Failed to open input method > > This is because xterm code in XFree86 4.0 has changed and it uses > some > X Input routines from XFree86 4.0. These warnings are due to the > fact we still do not have XFree86 X-server. However, these are > harmless > warnings and should not cause a crash or _X11TransSock Errno. OK, duly noted. > > Suhaib -------------------------------------------------------------------------- > Can you provide more details? I use Exceed 6.1 and the libs were > tested > before releasing them. > > This seems to X server not accepting X socket connections??? Yes. > > > waiting for X server to begin accepting connections . > > A while ago someone mailed me problems with ReflectionX and it turns > out that the issue was ReflectionX configuration. > > I need the X server log files. I have no idea where ReflectionX > creates them because I have never used it. You need to find it and > send me your > X-server log file. OK, here is my Reflection X log file: Nov 3 12:28:58: Starting server 'D:\Program Files\Reflection\rx.exe' (RX271) Nov 3 12:28:58: Server startup command line parameters: '' (RX280) Nov 3 12:28:58: Socket error: gethostbyname failed (RX2489) Nov 3 12:28:58: Socket error: gethostbyname failed (RX2489) Nov 3 12:28:58: << Executable Information >> (RX2002) Nov 3 12:28:58: Program name: Reflection X (LSL) for Windows NT (RX2003) Nov 3 12:28:58: Program version: Version 7.20 (RX2004) Nov 3 12:28:58: Program UPI: RMUL-0720-333333333 (RX2005) Nov 3 12:28:58: Program creation date: Wednesday, April 14, 1999 (RX2006) Nov 3 12:28:59: << System and Network Information >> (RX2008) Nov 3 12:28:59: System CPU: Pentium processor (RX2009) Nov 3 12:28:59: System OS: Windows NT Version 4.0 (build 1381: Service Pack 3) (RX2010) Nov 3 12:28:59: Current display driver: mga64 Version 4.0.85 (RX2011) Nov 3 12:28:59: Current screen resolution: 1280 x 1024 (RX2012) Nov 3 12:28:59: Current screen pixel depth: 16 (RX2013) Nov 3 12:28:59: Current Network stack: WinSock 2.0 (RX2014) Nov 3 12:28:59: Available transports: TCP/IP (RX2015) Nov 3 12:28:59: Local IP address: 144.254.205.117 (RX2016) Nov 3 12:28:59: Local DECNET node: Not applicable (RX2017) Nov 3 12:29:00: rxstart.exe (cf) - Client startup is initializing (RX5006) Nov 3 12:29:30: rxstart.exe (cf) - Client startup is closing down (RX5007) > > Which application you were using? I was running "startx". This should be the same as "xinit $HOME/.xinitrc -- $HOME/.xserverrc". Both exhibit the same behavior. Here is my .xinitrc (deliberately kept very simple): |#!/bin/sh | |## |# Load the X resources |xrdb -load $HOME/.Xresources | |## |# Set the background bitmap |xsetroot -bitmap /usr/local/share/backdrops/BrickWall.bm -fg firebrick -bg black | |twm Here is my .xserverrc: |#!/bin/sh | |//D/Program\ Files/Reflection/rx.exe My DISPLAY variable is set to jgrishaw-nthome:0.0 > > Have you TCP/IP installed? The X requires a TCP/IP insatlled and > localhost 127.0.0.1:0 in your /etc/hosts directory defined. On > Windows Nt /etc/hosts entry are in > /Winnt/system32/drivers/etc/hosts, that is where > RefelectionX would search for /etc/hosts file, unless ReflectionX > folks has some weird configuration files. Yes, TCP/IP is installed. I have modified /etc/hosts and /winnt/system32/etc/hosts as per your previous instructions, and still no success. > > Regards > Suhaib > > I have moved this discussion to cygwin-xfree list. > > > > > -----Original Message----- > > From: cygwin-owner@sourceware.cygnus.com > > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > > Dtcohen@aol.com > > Sent: Tuesday, November 02, 1999 2:10 PM > > To: cygwin@sourceware.cygnus.com > > Cc: Dtcohen@aol.com > > Subject: Re: X11R6.x libs > > > > > > Suhaib and/or other interested parties, > > > > I am having trouble with the "X11R6.4 for Cygwin v 1.0" > > download you > > mention below. When I try to start up X-windows with > > Reflection X, > > I get the following error messages: > > > > _X11TransSocketOpen: socket() failed for local > > _X11TransSocketOpenCOTSClient: Unable to open socket for local > > _X11TransOpen: transcript open failed for local/JGRISHAW-NTHOME:0 > > > > waiting for X server to begin accepting connections . > > _X11TransSocketOpen: socket() failed for local > > _X11TransSocketOpenCOTSClient: Unable to open socket for local > > _X11TransOpen: transcript open failed for local/jgrishaw-nthome:0 > > . > > _X11TransSocketOpen: socket() failed for local > > _X11TransSocketOpenCOTSClient: Unable to open socket for local > > _X11TransOpen: transcript open failed for local/jgrishaw-nthome:0 > > . > > etc > > etc > > etc > > > > This used to work fine with Sergey's X11R6.4 binaries and the > > Cygwin B20.1 release. Any ideas how to fix this? > > > > I am running Windows NT 4.0 SP3 and Cygwin v1.0 from the CD-ROM. > > > > Many thanks, > > > > Jim Grishaw. > > > > > > > I have removed X11R6.x developments tools from my URLS at > > > http://siddiqi.webjump.com and > > > http://www.geocities/ResearchTriangle/Forum6298 . > > > > > > The X11R6.x developments tools are now available ONLY from > > > http://sourceware.cygnus.com/cygwin/xfree > > > (Cygwin-xfree). This is to avoid confusions ater Cygwin > > v 1.0 was > > > released. > > > > > > 3 different versions of X11 are available: > > > X11R6.3 from XFRee86 3.3.5 for Cygwin B20.1 > > > > > > X11R6.4 for Cygwin B20.1 (derived from XFree86 3.9.16) > > > > > > X11R6.4 for Cygwin v 1.0 (Cygwin Cd Distribution) (derived from > > > XFree86 3.9.16 - XFree86 4.0 Developers Snapshots). > > > > > > The Cygwin-xfree URL > > (hhtp://sourceware.cygnus.com/cygwin/xfree) now > > > has a FAQ. > > > > > > > > > Suhaib > > > > > > > > From ssiddiqi@inspirepharm.com Wed Nov 3 13:37:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Wed, 03 Nov 1999 13:37:00 -0000 Subject: X11R6.x libs References: <0.c7f06dad.2552022c@aol.com> Message-ID: Jim, I know what is the problem. The startx and initx and .initrx could not be used from XFree86 4.0. Have a look at the bottom of your message... that is what you are doing. Sergey's and others distrubtions are from X11R6, not XFree86. In my case the starx script will attmpt to execute the XF86 servers which is NON FUNCTIONAL and should give _X11TransSock errno 111 error. Try going to X11R6/bin directory and type ./xterm (after starting RelectionX manually) to see if you can use all the X-clients. If you wish to use starx with ReflectionX then you need to edit that script and have to make a symlink to ReflectionX executable. The Symlink must be X, e.g First delete the X symblic link in X11R6/bin directory which point to either XGGI or XF86 servers. then: ln -s > > Suhaib, > > Thanks for getting back to me with your suggestions. > Unfortunately > modifying the hosts files does not seem to work. > > Just to be sure that my system was indeed set up > correctly, last > night I downloaded X11R6.4 from ftp.x.org, applied the 3 > fixes, applied > Sergey's patch, compiled/installed. The compile wasn't > perfect, but > at least X came up OK with no problems connecting to the server. > > This, plus the fact that Arlindo da Silva's X11R6.4 > compile for B20.1 > seems to work fine leads me to wonder if there is some > sort of problem with > your compile. Or is there some other black magic to get > it to work? > > Arlindo da Silva's X11R6.4 seems to be rock solid, even on > Cygwin v1.0 (CD). However, I can't compile ("_ctype_" > link problem > with the Cygwin B20.1-compiled X11 libraries). > > If I can't get X11 running I might have to go back > to B20.1, so I > greatly appreciate the time you are spending on this. > > Below are detailed responses to your e-mails. > > Thanks again, > > Jim Grishaw. > > > > Jim, > > > > Could you please verify the following regarding > X11R6.x problems you > > had > > with ReflectionX? > > > > 1) Were the errors you reported relates to using XTERM.exe? > > No, I hadn't gotten to xterm.exe yet. > > > > > 2) Or, was it one of your application you compiled > with Cygwin B20.1 > > and now attempting to use on Cygwin v 1.0 CD Release? > > No, Cygwin B20.1 has been completely removed. I made > sure that da Silva's > X11R6.4 for B20.1 was gone. > > > > > 3) Did adding /etc/hosts entry help? > > Thanks for the suggestion but it didn't help > > > > > I found a few socket related bugs in libX11.dll but I am not > > really sure they were the cause of problems you reported. > > Hmm... sounds suspicious. > > > I could use Xterm and all the clients from > > cygwin-xfree-4.0-cygwin-v-1.tar.bz2 with Exceed > server. The Clients > > work fiune for me with Cygwin v 1.0 and also Cygwin Developemnt > > Snapshots. > > Excellent > > > Xterm may give the following warnings: > > > > bash-2.03$ ./xterm > > Warning: locale not supported by C library, locale unchanged > > Warning: locale not supported by Xlib, locale set to C > > Warning: X locale modifiers not supported, using default > > Failed to open input method > > > > This is because xterm code in XFree86 4.0 has changed > and it uses > > some > > X Input routines from XFree86 4.0. These warnings are > due to the > > fact we still do not have XFree86 X-server. However, these are > > harmless > > warnings and should not cause a crash or _X11TransSock Errno. > > OK, duly noted. > > > > > Suhaib > > ---------------------------------------------------------- > ---------------- > > > > Can you provide more details? I use Exceed 6.1 and > the libs were > > tested > > before releasing them. > > > > This seems to X server not accepting X socket connections??? > > Yes. > > > > > > waiting for X server to begin accepting connections . > > > > A while ago someone mailed me problems with > ReflectionX and it turns > > out that the issue was ReflectionX configuration. > > > > I need the X server log files. I have no idea where > ReflectionX > > creates them because I have never used it. You need > to find it and > > send me your > > X-server log file. > > OK, here is my Reflection X log file: > > Nov 3 12:28:58: Starting server 'D:\Program > Files\Reflection\rx.exe' (RX271) > Nov 3 12:28:58: Server startup command line parameters: '' (RX280) > Nov 3 12:28:58: Socket error: gethostbyname failed (RX2489) > Nov 3 12:28:58: Socket error: gethostbyname failed (RX2489) > Nov 3 12:28:58: << Executable Information >> (RX2002) > Nov 3 12:28:58: Program name: Reflection X > (LSL) for Windows NT (RX2003) > Nov 3 12:28:58: Program version: Version 7.20 (RX2004) > Nov 3 12:28:58: Program UPI: > RMUL-0720-333333333 (RX2005) > Nov 3 12:28:58: Program creation date: Wednesday, > April 14, 1999 (RX2006) > Nov 3 12:28:59: << System and Network Information >> (RX2008) > Nov 3 12:28:59: System CPU: Pentium > processor (RX2009) > Nov 3 12:28:59: System OS: Windows NT > Version 4.0 (build 1381: Service Pack 3) (RX2010) > Nov 3 12:28:59: Current display driver: mga64 Version > 4.0.85 (RX2011) > Nov 3 12:28:59: Current screen resolution: 1280 x 1024 (RX2012) > Nov 3 12:28:59: Current screen pixel depth: 16 (RX2013) > Nov 3 12:28:59: Current Network stack: WinSock 2.0 (RX2014) > Nov 3 12:28:59: Available transports: TCP/IP (RX2015) > Nov 3 12:28:59: Local IP address: > 144.254.205.117 (RX2016) > Nov 3 12:28:59: Local DECNET node: Not > applicable (RX2017) > Nov 3 12:29:00: rxstart.exe (cf) - Client startup is > initializing (RX5006) > Nov 3 12:29:30: rxstart.exe (cf) - Client startup is > closing down (RX5007) > > > > > Which application you were using? > > I was running "startx". This should be the same as > "xinit $HOME/.xinitrc -- $HOME/.xserverrc". Both exhibit the same > behavior. > > Here is my .xinitrc (deliberately kept very simple): > |#!/bin/sh > | > |## > |# Load the X resources > |xrdb -load $HOME/.Xresources > | > |## > |# Set the background bitmap > |xsetroot -bitmap /usr/local/share/backdrops/BrickWall.bm > -fg firebrick -bg black > | > |twm > > Here is my .xserverrc: > |#!/bin/sh > | > |//D/Program\ Files/Reflection/rx.exe > > My DISPLAY variable is set to jgrishaw-nthome:0.0 > > > > > Have you TCP/IP installed? The X requires a TCP/IP > insatlled and > > localhost 127.0.0.1:0 in your /etc/hosts directory defined. On > > Windows Nt /etc/hosts entry are in > > /Winnt/system32/drivers/etc/hosts, that is where > > RefelectionX would search for /etc/hosts file, unless > ReflectionX > > folks has some weird configuration files. > > Yes, TCP/IP is installed. I have modified /etc/hosts and > /winnt/system32/etc/hosts as per your previous > instructions, and still > no success. > > > > Regards > > Suhaib > > > > I have moved this discussion to cygwin-xfree list. > > > > > > > > > -----Original Message----- > > > From: cygwin-owner@sourceware.cygnus.com > > > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > > > Dtcohen@aol.com > > > Sent: Tuesday, November 02, 1999 2:10 PM > > > To: cygwin@sourceware.cygnus.com > > > Cc: Dtcohen@aol.com > > > Subject: Re: X11R6.x libs > > > > > > > > > Suhaib and/or other interested parties, > > > > > > I am having trouble with the "X11R6.4 for Cygwin v 1.0" > > > download you > > > mention below. When I try to start up X-windows with > > > Reflection X, > > > I get the following error messages: > > > > > > _X11TransSocketOpen: socket() failed for local > > > _X11TransSocketOpenCOTSClient: Unable to open socket > for local > > > _X11TransOpen: transcript open failed for > local/JGRISHAW-NTHOME:0 > > > > > > waiting for X server to begin accepting connections . > > > _X11TransSocketOpen: socket() failed for local > > > _X11TransSocketOpenCOTSClient: Unable to open socket > for local > > > _X11TransOpen: transcript open failed for > local/jgrishaw-nthome:0 > > > . > > > _X11TransSocketOpen: socket() failed for local > > > _X11TransSocketOpenCOTSClient: Unable to open socket > for local > > > _X11TransOpen: transcript open failed for > local/jgrishaw-nthome:0 > > > . > > > etc > > > etc > > > etc > > > > > > This used to work fine with Sergey's X11R6.4 binaries and the > > > Cygwin B20.1 release. Any ideas how to fix this? > > > > > > I am running Windows NT 4.0 SP3 and Cygwin v1.0 from > the CD-ROM. > > > > > > Many thanks, > > > > > > Jim Grishaw. > > > > > > > > > > I have removed X11R6.x developments tools from my URLS at > > > > http://siddiqi.webjump.com and > > > > http://www.geocities/ResearchTriangle/Forum6298 . > > > > > > > > The X11R6.x developments tools are now available ONLY from > > > > http://sourceware.cygnus.com/cygwin/xfree > > > > (Cygwin-xfree). This is to avoid confusions ater Cygwin > > > v 1.0 was > > > > released. > > > > > > > > 3 different versions of X11 are available: > > > > X11R6.3 from XFRee86 3.3.5 for Cygwin B20.1 > > > > > > > > X11R6.4 for Cygwin B20.1 (derived from XFree86 3.9.16) > > > > > > > > X11R6.4 for Cygwin v 1.0 (Cygwin Cd Distribution) > (derived from > > > > XFree86 3.9.16 - XFree86 4.0 Developers Snapshots). > > > > > > > > The Cygwin-xfree URL > > > (hhtp://sourceware.cygnus.com/cygwin/xfree) now > > > > has a FAQ. > > > > > > > > > > > > Suhaib > > > > > > > > > > > > From Dtcohen@aol.com Wed Nov 3 14:58:00 1999 From: Dtcohen@aol.com (Dtcohen@aol.com) Date: Wed, 03 Nov 1999 14:58:00 -0000 Subject: X11R6.x libs Message-ID: <0.b02f2dc8.255217d9@aol.com> > > Jim, > > I know what is the problem. The startx and initx and .initrx could > not be used from XFree86 4.0. Have a look at the bottom of your > message... that is what you are doing. Sergey's and others > distrubtions are from X11R6, not XFree86. In my case the starx > script will attmpt to execute > the XF86 servers which is NON FUNCTIONAL and should give > _X11TransSock errno 111 error. > > Try going to X11R6/bin directory and type ./xterm (after starting > RelectionX manually) to see if you can use all the X-clients. Yes, xterm works fine when I start Reflection X manually. > > If you wish to use starx with ReflectionX then you need to edit that > script and have to make a symlink to ReflectionX executable. The You must mean the "startx" script. I had a look at it doesn't seem that anything needs to be changed... > Symlink must be X, e.g > > First delete the X symblic link in X11R6/bin directory which point > to either XGGI or XF86 servers. then: > > ln -s > That would allow you to execute refelctionX X-server executable. OK, I made the symlink to Reflection X but I still have the problem. This is a good idea but I don't think this is the problem. I can see that the Reflection X server is getting started when I run startx. This was true even before I made the symlink. I'm curious, does startx/xinit work for you with Exceed? One would think that we should both be having the same problem. Don't forget to put a .xserverrc file in $HOME with a pointer to your Exceed server. Thanks again, Jim Grishaw. From ssiddiqi@inspirepharm.com Wed Nov 3 17:35:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Wed, 03 Nov 1999 17:35:00 -0000 Subject: X11R6.x libs References: <0.b02f2dc8.255217d9@aol.com> Message-ID: > I'm curious, does startx/xinit work for you with Exceed? One would > think that we should both be having the same problem. Don't forget to put > a .xserverrc file in $HOME with a pointer to your Exceed server. startx and xinit is of no real meaning for commercial Windows X-server, like Hummingbird Exceed or Sun PC X-ware. I keep a shortcut of my x-server executable in my Windows Startup folder. The X-servers gets started on each reboot. I am a heavy user of X-servers, without it I cannot survive. In the startx script I think I may have address some silly thing, which looks obvious and simple but actually points to XF86 executables. Is there a hardcoded xinit.exe or path to it? You should remove it, if it is there. I must have added it while I was compiling XF86 executables, to experiment a few things. Xinit.exe in XFree86 is basically same as in X11R6.4 with few lines of code changed. It would attempt to execute XF86 executables and would return _X11TransSock errno 111 if it could not find or start XF_SVGA.exe (server). I suggest you start your ReflectionX like you do as a Windows program or suggested in ReflectionX User Guide, instead of using xinit.exe. If you could execute xterm and other X cleints then there is really no problems with X11 libs. The socket bugs I mentioned today morning should not affect a normal user. They might cause problems once XF86 server is functional. Regards Suhaib > > Thanks again, > Jim Grishaw. > From Dtcohen@aol.com Thu Nov 4 11:53:00 1999 From: Dtcohen@aol.com (Dtcohen@aol.com) Date: Thu, 04 Nov 1999 11:53:00 -0000 Subject: X11R6.x libs Message-ID: <0.c0ab979e.25533e24@aol.com> Sahaib, I disagree with your suggestion that startx and xinit are useless for Cygwin, but at least we have identified the problem and have a workaround. Maybe if I can find some free time sometime I'll have a look at your souce code and see if I can come up with a patch. At any rate, thank you most kindly for your help with this problem. I now have X11 up and running, and so far it seems to be pretty solid. Sincerely, Jim Grishaw. > > I'm curious, does startx/xinit work for you with Exceed? One would > > think that we should both be having the same problem. Don't forget to put > > a .xserverrc file in $HOME with a pointer to your Exceed server. > > startx and xinit is of no real meaning for commercial Windows X-server, like > Hummingbird Exceed or Sun PC X-ware. I keep a shortcut of my x-server > executable in my Windows Startup folder. The X-servers gets started > on each reboot. I am a heavy user of X-servers, without it I cannot > survive. > > In the startx script I think I may have address some silly thing, which > looks obvious and simple but actually points to XF86 executables. Is there > a hardcoded xinit.exe or path to it? You should remove it, if it is there. > I must have added it while I was compiling XF86 executables, to experiment > a few things. Xinit.exe in XFree86 is basically same as in X11R6.4 with few > lines of code changed. It would attempt to execute XF86 executables > and would return _X11TransSock errno 111 if it could not find or start > XF_SVGA.exe (server). > > I suggest you start your ReflectionX like you do as a Windows program or > suggested > in ReflectionX User Guide, instead of using xinit.exe. > If you could execute xterm and other X cleints then there is really no > problems > with X11 libs. The socket bugs I mentioned today morning should not affect > a normal user. > They might cause problems once XF86 server is functional. > > Regards > Suhaib > > > > > Thanks again, > > Jim Grishaw. > > From ssiddiqi@inspirepharm.com Thu Nov 4 12:06:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Thu, 04 Nov 1999 12:06:00 -0000 Subject: X11R6.x libs References: <0.c0ab979e.25533e24@aol.com> Message-ID: Sure, you and anyone is most welcome to come up with any patches for things i may have missed. For starx if you get rid of all the command and put a simple line for example /prorag~1/reflectionx/rx & this should execute your rs.exe which is your ReflectionX server executable. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of > Dtcohen@aol.com > Sent: Thursday, November 04, 1999 2:53 PM > To: cygwin-xfree@sourceware.cygnus.com > Cc: Dtcohen@aol.com > Subject: Re[4]: X11R6.x libs > > > Sahaib, > > I disagree with your suggestion that startx and > xinit are useless > for Cygwin, but at least we have identified the problem and have > a workaround. Maybe if I can find some free time > sometime I'll have > a look at your souce code and see if I can come up with a patch. > > At any rate, thank you most kindly for your help > with this problem. > I now have X11 up and running, and so far it seems to be > pretty solid. > > Sincerely, > Jim Grishaw. > > > > I'm curious, does startx/xinit work for you with > Exceed? One would > > > think that we should both be having the same problem. > Don't forget to put > > > a .xserverrc file in $HOME with a pointer to your > Exceed server. > > > > startx and xinit is of no real meaning for commercial > Windows X-server, like > > Hummingbird Exceed or Sun PC X-ware. I keep a shortcut > of my x-server > > executable in my Windows Startup folder. The X-servers > gets started > > on each reboot. I am a heavy user of X-servers, without > it I cannot > > survive. > > > > In the startx script I think I may have address some > silly thing, which > > looks obvious and simple but actually points to XF86 > executables. Is there > > a hardcoded xinit.exe or path to it? You should remove > it, if it is there. > > I must have added it while I was compiling XF86 > executables, to experiment > > a few things. Xinit.exe in XFree86 is basically same > as in X11R6.4 with few > > lines of code changed. It would attempt to execute > XF86 executables > > and would return _X11TransSock errno 111 if it could > not find or start > > XF_SVGA.exe (server). > > > > I suggest you start your ReflectionX like you do as a > Windows program or > > suggested > > in ReflectionX User Guide, instead of using xinit.exe. > > If you could execute xterm and other X cleints then > there is really no > > problems > > with X11 libs. The socket bugs I mentioned today > morning should not affect > > a normal user. > > They might cause problems once XF86 server is functional. > > > > Regards > > Suhaib > > > > > > > > Thanks again, > > > Jim Grishaw. > > > > From mmacdona@tsi.gte.com Fri Nov 5 07:07:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Fri, 05 Nov 1999 07:07:00 -0000 Subject: FW: Returned mail: Host unknown Message-ID: -----Original Message----- From: Mailer-Daemon@tsi.gte.com [ mailto:Mailer-Daemon@tsi.gte.com ] Sent: Wednesday, November 03, 1999 11:53 AM To: mmacdona@exchange01.tsi.gte.com Subject: Returned mail: Host unknown ----- Transcript of session follows ----- 421 Host nspm.ipass.net not found for mailer ddn. 550 ... Host unknown ----- Unsent message follows ----- Received: from tpaexc02.tsi.gte.com by tsi.gte.com (5.x/SMI-SVR4) id AA17704; Wed, 3 Nov 1999 11:52:40 -0500 Errors-To: Received: by tpaexc02.tsi.gte.com with Internet Mail Service (5.5.2448.0) id ; Wed, 3 Nov 1999 11:50:53 -0500 Message-Id: From: Mike MacDonald To: "'ssiddiqi@nspm.ipass.net'" Subject: RE: Cygwin CD Date: Wed, 3 Nov 1999 11:50:52 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Ok, I'm gonna look at it now. Oooohhh!! This is right up my alley! I'll keep you posted on any progress I make. I need to do some research of course, but at first glance its giving me warm fuzzies.. I need to map out what the driver does, and who loads it where, etc.. I will need some help with the cygwin1.dll, etc - since those ports/memory addys need to be mapped into cygwins drive structure, I'm also assuming that cygwin will need to be present (X will need to be able to access /dev/ in cygwin's dir structure).. It may be possible to create a device that makes those things present no matter what, but then we get into some issues with how do we do this in NT, as opposed to Win98.. I'll keep reading, but let me know if I'm on/off track with some of this thinking.. -----Original Message----- From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] Sent: Wednesday, November 03, 1999 11:06 AM To: Mike MacDonald Subject: RE: Cygwin CD Have a look at the http://sourceware.cygnus.com/cygwin/xfree . There is a XF86SUP.SYS driver from OS/2 which we need to port to Windows NT. It should be ported using MSVC or other Win32 compiler, but not Cygwin for peformance reasons. It has a lot of ASM code in it,. This what actually holding XFree86 port (X-server) for Cygwin (Windows). I lack the expertise and knowledge of assembly language and devices drivers. If you could get it ported to Win32 using MSVc or another Win32 compiler you would be of great help and would make X-servers functional. Suhaib > -----Original Message----- > From: cygwin-owner@sourceware.cygnus.com > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > Mike MacDonald > Sent: Wednesday, November 03, 1999 10:55 AM > To: 'ssiddiqi@nspm.ipass.net'; 'cygwin@sourceware.cygnus.com' > Subject: RE: Cygwin CD > > > > Is there anything I can do to help with XFree stuff? I'm > kinda new to X, > and Cygwin, and I don't have alot of time to spend on > stuff, but I do have > about 20 years of programming experience including ASM, > and who knows what > else.. (12 years professional - I'm working at GTE now > as a developer).. > > My constraints are that this is not a part of my job > right now, and I don't > use my computer at home anymore - so anything I look at > has to be during > breaks, or when I have time... > > > -- > Want to unsubscribe from this list? > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > From ssiddiqi@inspirepharm.com Fri Nov 5 07:24:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Fri, 05 Nov 1999 07:24:00 -0000 Subject: Returned mail: Host unknown References: Message-ID: Sorry folks if you had been getting mails bounced. I had enough of spam. On average 5 to 10 spam per day comming because the idiots colecting my e-mail addresses from mailing lists. Although i had over 200 IPblocks banned at the router level, still some of the spammers were getting through. Majority of the spammers seems to have accounts at psi.net and popsite.net, so psi.net and popsite.net IP Netblocks had been completely banned. Sorry about the bounced messages. Please send messages through cygwin and cygwin-xfree list if your message bounced... it means your IP block belongs to an ISP from whom I received repeated junk mails. To answer your questions, you are absolutely on the right track. The devices must be accessed via Win32, but X will run on Cygwin. The only /dev/xxx X will need from Cygwin is /dev/conin (/dev/tty) which is needed for xterm, xinit and xdm etc. Accessing hardware memory via Cygwin will slowdown X to unacceptable level and may cause problems. The example driver for OS/2 from Holger is a very nice hack which he wrote to offer /dev/mem and /dev/io which are missing on Windows and OS/2. After you have looked at the source code and you have your suggestions, we could discuss and plan on how to do it. Your help will be highly appreciated. Suhaib > > Ok, I'm gonna look at it now. > > > Oooohhh!! This is right up my alley! I'll keep you > posted on any progress > I make. I need to do some research of course, but at > first glance its > giving me warm fuzzies.. > > I need to map out what the driver does, and who loads it > where, etc.. > > I will need some help with the cygwin1.dll, etc - since > those ports/memory > addys need to be mapped into cygwins drive structure, I'm > also assuming that > cygwin will need to be present (X will need to be able to access > /dev/ in cygwin's dir structure).. It may be > possible to create a > device that makes those things present no matter what, > but then we get into > some issues with how do we do this in NT, as opposed to Win98.. > > I'll keep reading, but let me know if I'm on/off track > with some of this > thinking.. > > -----Original Message----- > From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] > Sent: Wednesday, November 03, 1999 11:06 AM > To: Mike MacDonald > Subject: RE: Cygwin CD > > > > Have a look at the http://sourceware.cygnus.com/cygwin/xfree . > There is a XF86SUP.SYS driver from OS/2 which we need to port > to Windows NT. It should be ported using MSVC or other Win32 > compiler, but not Cygwin for peformance reasons. It has a lot of > ASM code > in it,. This what actually holding XFree86 port (X-server) for > Cygwin (Windows). I lack the expertise and knowledge of > assembly language and devices drivers. > > If you could get it ported to Win32 using MSVc or another Win32 > compiler > you would be of great help and would make X-servers functional. > > Suhaib > > > -----Original Message----- > > From: cygwin-owner@sourceware.cygnus.com > > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > > Mike MacDonald > > Sent: Wednesday, November 03, 1999 10:55 AM > > To: 'ssiddiqi@nspm.ipass.net'; 'cygwin@sourceware.cygnus.com' > > Subject: RE: Cygwin CD > > > > > > > > Is there anything I can do to help with XFree stuff? I'm > > kinda new to X, > > and Cygwin, and I don't have alot of time to spend on > > stuff, but I do have > > about 20 years of programming experience including ASM, > > and who knows what > > else.. (12 years professional - I'm working at GTE now > > as a developer).. > > > > My constraints are that this is not a part of my job > > right now, and I don't > > use my computer at home anymore - so anything I look at > > has to be during > > breaks, or when I have time... > > > > > > -- > > Want to unsubscribe from this list? > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > > > From mmacdona@tsi.gte.com Sun Nov 7 16:49:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Sun, 07 Nov 1999 16:49:00 -0000 Subject: Cygwin CD Message-ID: I read some more on this. Most things (video memory for sure) can be gotten using Direct X. I'm not sure about the IO Ports. I have to read the DX docs on that. I am sure there is a way.. None of this should be to hard to do. My biggest question is, do we want to load this driver at boot up, as a windows driver, as a cygwin driver, or as part of the X initialization? I'm thinking that it should be associated with cygwin, and load up with the cygwin.dll - or load up with X.. I also need to find out what he's patching in X in memory.. Is he patching the source, or the memory locations? I have to look into the X side.. Any more info you got is cool :) -----Original Message----- From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] Sent: Wednesday, November 03, 1999 11:06 AM To: Mike MacDonald Subject: RE: Cygwin CD Have a look at the http://sourceware.cygnus.com/cygwin/xfree . There is a XF86SUP.SYS driver from OS/2 which we need to port to Windows NT. It should be ported using MSVC or other Win32 compiler, but not Cygwin for peformance reasons. It has a lot of ASM code in it,. This what actually holding XFree86 port (X-server) for Cygwin (Windows). I lack the expertise and knowledge of assembly language and devices drivers. If you could get it ported to Win32 using MSVc or another Win32 compiler you would be of great help and would make X-servers functional. Suhaib > -----Original Message----- > From: cygwin-owner@sourceware.cygnus.com > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > Mike MacDonald > Sent: Wednesday, November 03, 1999 10:55 AM > To: 'ssiddiqi@nspm.ipass.net'; 'cygwin@sourceware.cygnus.com' > Subject: RE: Cygwin CD > > > > Is there anything I can do to help with XFree stuff? I'm > kinda new to X, > and Cygwin, and I don't have alot of time to spend on > stuff, but I do have > about 20 years of programming experience including ASM, > and who knows what > else.. (12 years professional - I'm working at GTE now > as a developer).. > > My constraints are that this is not a part of my job > right now, and I don't > use my computer at home anymore - so anything I look at > has to be during > breaks, or when I have time... > > > -- > Want to unsubscribe from this list? > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > From tvaga@math.ut.ee Mon Nov 8 03:36:00 1999 From: tvaga@math.ut.ee (=?ISO-8859-15?Q?T=F5nis_Vaga?=) Date: Mon, 08 Nov 1999 03:36:00 -0000 Subject: Xlib porting References: <941967376.13054.ezmlm@sourceware.cygnus.com> Message-ID: Hi! What is the easiest way to port X app to cygwin (under win95)? Do i really need get all these X client and server files? They about 30M. I remember Moonlight Creator uses b19 dll but did'nt need X server for running. So, what files i should get and what not? tonis From ssiddiqi@inspirepharm.com Mon Nov 8 03:49:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Mon, 08 Nov 1999 03:49:00 -0000 Subject: Xlib porting References: Message-ID: The X-server files are of no use at the moment because they X-server is not functional yet. read the FAQ at http://sourceware.cygnus.com/cygwin/xfree . You need X11 libs which are part of cygwin-xfree archive and link your code to X libs as you do on UNIX. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of T????nis Vaga > Sent: Monday, November 08, 1999 6:36 AM > To: cygwin-xfree@sourceware.cygnus.com > Subject: Xlib porting > > > > Hi! > > What is the easiest way to port X app to cygwin (under > win95)? Do i really > need get all these X client and server files? They about > 30M. I remember > Moonlight Creator uses b19 dll but did'nt need X server > for running. > So, what files i should get and what not? > > tonis > > > > From ssiddiqi@inspirepharm.com Mon Nov 8 12:22:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Mon, 08 Nov 1999 12:22:00 -0000 Subject: Driver for X11 References: Message-ID: > > I read some more on this. Most things (video memory for > sure) can be gotten > using Direct X. I'm not sure about the IO Ports. I > have to read the DX > docs on that. I am sure there is a way.. None of this > should be to hard to > do. > Yes, it is true that video memory issue can be handle with DirectX. The XF86SUP.SYS driver is as an example for you and others, so you could come up with your ideas on how to achive those functionalities more efficiently on Win32 > My biggest question is, do we want to load this driver at > boot up, as a > windows driver, as a cygwin driver, or as part of the X > initialization? > On OS/2 the driver loads at the boot time. He explained it one of his messages, which is also posted on Cygwin-Xfree URL. > I'm thinking that it should be associated with cygwin, > and load up with the > cygwin.dll - or load up with X.. No it should not be associated with Cygwin or Cygwin1.dll otherwise you would be sacrifiying performance. We will need to add needed to code in xc/programs/Xserver/hw/os-support/cygwin. This code will call the driver when needed. I would send you Holger's code from xc/programs/Xserver/hw/os-support/os2, which could server as an example on how he achived it. > > I also need to find out what he's patching in X in > memory.. Is he patching > the source, or the memory locations? I have to look into > the X side.. Will send you his code from X-server which uses this driver as example. It will help you understand how it is used. Suhaib > > Any more info you got is cool :) > > > -----Original Message----- > From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] > Sent: Wednesday, November 03, 1999 11:06 AM > To: Mike MacDonald > Subject: RE: Cygwin CD > > > > Have a look at the http://sourceware.cygnus.com/cygwin/xfree . > There is a XF86SUP.SYS driver from OS/2 which we need to port > to Windows NT. It should be ported using MSVC or other Win32 > compiler, but not Cygwin for peformance reasons. It has a lot of > ASM code > in it,. This what actually holding XFree86 port (X-server) for > Cygwin (Windows). I lack the expertise and knowledge of > assembly language and devices drivers. > > If you could get it ported to Win32 using MSVc or another Win32 > compiler > you would be of great help and would make X-servers functional. > > Suhaib > > > -----Original Message----- > > From: cygwin-owner@sourceware.cygnus.com > > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > > Mike MacDonald > > Sent: Wednesday, November 03, 1999 10:55 AM > > To: 'ssiddiqi@nspm.ipass.net'; 'cygwin@sourceware.cygnus.com' > > Subject: RE: Cygwin CD > > > > > > > > Is there anything I can do to help with XFree stuff? I'm > > kinda new to X, > > and Cygwin, and I don't have alot of time to spend on > > stuff, but I do have > > about 20 years of programming experience including ASM, > > and who knows what > > else.. (12 years professional - I'm working at GTE now > > as a developer).. > > > > My constraints are that this is not a part of my job > > right now, and I don't > > use my computer at home anymore - so anything I look at > > has to be during > > breaks, or when I have time... > > > > > > -- > > Want to unsubscribe from this list? > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > > > From mmacdona@tsi.gte.com Mon Nov 8 12:39:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Mon, 08 Nov 1999 12:39:00 -0000 Subject: Driver for X11 Message-ID: Ok, thanx. Another question, I'm hearing something about the graphics engine changing in newer versions of X, is that going to affect things if we just try to mimic what is done with XF86SUP.SYS using DirectX, or something that lets us get direct memory access? -----Original Message----- From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] Sent: Monday, November 08, 1999 3:18 PM To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com Subject: RE: Driver for X11 > > I read some more on this. Most things (video memory for > sure) can be gotten > using Direct X. I'm not sure about the IO Ports. I > have to read the DX > docs on that. I am sure there is a way.. None of this > should be to hard to > do. > Yes, it is true that video memory issue can be handle with DirectX. The XF86SUP.SYS driver is as an example for you and others, so you could come up with your ideas on how to achive those functionalities more efficiently on Win32 > My biggest question is, do we want to load this driver at > boot up, as a > windows driver, as a cygwin driver, or as part of the X > initialization? > On OS/2 the driver loads at the boot time. He explained it one of his messages, which is also posted on Cygwin-Xfree URL. > I'm thinking that it should be associated with cygwin, > and load up with the > cygwin.dll - or load up with X.. No it should not be associated with Cygwin or Cygwin1.dll otherwise you would be sacrifiying performance. We will need to add needed to code in xc/programs/Xserver/hw/os-support/cygwin. This code will call the driver when needed. I would send you Holger's code from xc/programs/Xserver/hw/os-support/os2, which could server as an example on how he achived it. > > I also need to find out what he's patching in X in > memory.. Is he patching > the source, or the memory locations? I have to look into > the X side.. Will send you his code from X-server which uses this driver as example. It will help you understand how it is used. Suhaib > > Any more info you got is cool :) > > > -----Original Message----- > From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] > Sent: Wednesday, November 03, 1999 11:06 AM > To: Mike MacDonald > Subject: RE: Cygwin CD > > > > Have a look at the http://sourceware.cygnus.com/cygwin/xfree . > There is a XF86SUP.SYS driver from OS/2 which we need to port > to Windows NT. It should be ported using MSVC or other Win32 > compiler, but not Cygwin for peformance reasons. It has a lot of > ASM code > in it,. This what actually holding XFree86 port (X-server) for > Cygwin (Windows). I lack the expertise and knowledge of > assembly language and devices drivers. > > If you could get it ported to Win32 using MSVc or another Win32 > compiler > you would be of great help and would make X-servers functional. > > Suhaib > > > -----Original Message----- > > From: cygwin-owner@sourceware.cygnus.com > > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > > Mike MacDonald > > Sent: Wednesday, November 03, 1999 10:55 AM > > To: 'ssiddiqi@nspm.ipass.net'; 'cygwin@sourceware.cygnus.com' > > Subject: RE: Cygwin CD > > > > > > > > Is there anything I can do to help with XFree stuff? I'm > > kinda new to X, > > and Cygwin, and I don't have alot of time to spend on > > stuff, but I do have > > about 20 years of programming experience including ASM, > > and who knows what > > else.. (12 years professional - I'm working at GTE now > > as a developer).. > > > > My constraints are that this is not a part of my job > > right now, and I don't > > use my computer at home anymore - so anything I look at > > has to be during > > breaks, or when I have time... > > > > > > -- > > Want to unsubscribe from this list? > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > > > From ssiddiqi@inspirepharm.com Mon Nov 8 12:49:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Mon, 08 Nov 1999 12:49:00 -0000 Subject: Driver for X11 References: Message-ID: No, that will not affect any driver. The XF86 4.0 has 3 mechanisms of loaing Xserver, static X-server (which is same as 3.3.x), loadable, and dlopen loadable. Regardless, each X-server still needs System dependent drivers for accessing mouse, keyboard, and memomry etc. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Monday, November 08, 1999 3:38 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: Driver for X11 > > > Ok, thanx. Another question, I'm hearing something about > the graphics > engine changing in newer versions of X, is that going to > affect things if we > just try to mimic what is done with XF86SUP.SYS using > DirectX, or something > that lets us get direct memory access? > > -----Original Message----- > From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] > Sent: Monday, November 08, 1999 3:18 PM > To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com > Subject: RE: Driver for X11 > > > > > > > > I read some more on this. Most things (video memory for > > sure) can be gotten > > using Direct X. I'm not sure about the IO Ports. I > > have to read the DX > > docs on that. I am sure there is a way.. None of this > > should be to hard to > > do. > > > > > Yes, it is true that video memory issue can be handle > with DirectX. > The XF86SUP.SYS driver is as an example for you and others, so you > could come up with your ideas on how to achive those > functionalities > more > efficiently on Win32 > > > My biggest question is, do we want to load this driver at > > boot up, as a > > windows driver, as a cygwin driver, or as part of the X > > initialization? > > > > On OS/2 the driver loads at the boot time. He explained it one of > his messages, which is also posted on Cygwin-Xfree URL. > > > I'm thinking that it should be associated with cygwin, > > and load up with the > > cygwin.dll - or load up with X.. > > No it should not be associated with Cygwin or Cygwin1.dll > otherwise > you would be sacrifiying performance. We will need to > add needed to > code in > xc/programs/Xserver/hw/os-support/cygwin. This code will call the > driver when needed. I would send you Holger's code from > xc/programs/Xserver/hw/os-support/os2, which could server as an > example on how he achived it. > > > > > I also need to find out what he's patching in X in > > memory.. Is he patching > > the source, or the memory locations? I have to look into > > the X side.. > > Will send you his code from X-server which uses this driver as > example. > It will help you understand how it is used. > > > Suhaib > > > > > Any more info you got is cool :) > > > > > > -----Original Message----- > > From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] > > Sent: Wednesday, November 03, 1999 11:06 AM > > To: Mike MacDonald > > Subject: RE: Cygwin CD > > > > > > > > Have a look at the http://sourceware.cygnus.com/cygwin/xfree . > > There is a XF86SUP.SYS driver from OS/2 which we need to port > > to Windows NT. It should be ported using MSVC or other Win32 > > compiler, but not Cygwin for peformance reasons. It > has a lot of > > ASM code > > in it,. This what actually holding XFree86 port (X-server) for > > Cygwin (Windows). I lack the expertise and knowledge of > > assembly language and devices drivers. > > > > If you could get it ported to Win32 using MSVc or another Win32 > > compiler > > you would be of great help and would make X-servers functional. > > > > Suhaib > > > > > -----Original Message----- > > > From: cygwin-owner@sourceware.cygnus.com > > > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > > > Mike MacDonald > > > Sent: Wednesday, November 03, 1999 10:55 AM > > > To: 'ssiddiqi@nspm.ipass.net'; 'cygwin@sourceware.cygnus.com' > > > Subject: RE: Cygwin CD > > > > > > > > > > > > Is there anything I can do to help with XFree stuff? I'm > > > kinda new to X, > > > and Cygwin, and I don't have alot of time to spend on > > > stuff, but I do have > > > about 20 years of programming experience including ASM, > > > and who knows what > > > else.. (12 years professional - I'm working at GTE now > > > as a developer).. > > > > > > My constraints are that this is not a part of my job > > > right now, and I don't > > > use my computer at home anymore - so anything I look at > > > has to be during > > > breaks, or when I have time... > > > > > > > > > -- > > > Want to unsubscribe from this list? > > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > > > > > > From mmacdona@tsi.gte.com Mon Nov 8 13:06:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Mon, 08 Nov 1999 13:06:00 -0000 Subject: Driver for X11 Message-ID: Ok, good. That makes sense. Ok, then I need to look at as much source as possible for the XF86SUP.SYS - The questions still in my mind are this, do we need two drivers, one a windows driver, and the other a DOS driver for the config.sys? Or will just a Windows driver that works with NT and Win 98 be fine? Then, something I prolly gotta figgure out myself, is can I call directx functions from inside of a driver.. Thats gonna get a little complicated.. Something like the driver sits there, then when X tries to communicate with it it makes the DX calls or something.. A dos driver could just open up video memory, but it would have to be disabled and replaced when windows loads up.. Basically, I have to dig around and get my hands dirty.. I think I got some emails from someone else who is working on this.. I would like to hear more about what hes doing, but I think I'm up to date. Theres someone else who is supposedly trying to do this that he mentioned.. I don't want to duplicate efforts with him either.. -----Original Message----- From: cygwin-xfree-owner@sourceware.cygnus.com [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Suhaib Siddiqi Sent: Monday, November 08, 1999 3:45 PM To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com Subject: RE: Driver for X11 No, that will not affect any driver. The XF86 4.0 has 3 mechanisms of loaing Xserver, static X-server (which is same as 3.3.x), loadable, and dlopen loadable. Regardless, each X-server still needs System dependent drivers for accessing mouse, keyboard, and memomry etc. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Monday, November 08, 1999 3:38 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: Driver for X11 > > > Ok, thanx. Another question, I'm hearing something about > the graphics > engine changing in newer versions of X, is that going to > affect things if we > just try to mimic what is done with XF86SUP.SYS using > DirectX, or something > that lets us get direct memory access? > > -----Original Message----- > From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] > Sent: Monday, November 08, 1999 3:18 PM > To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com > Subject: RE: Driver for X11 > > > > > > > > I read some more on this. Most things (video memory for > > sure) can be gotten > > using Direct X. I'm not sure about the IO Ports. I > > have to read the DX > > docs on that. I am sure there is a way.. None of this > > should be to hard to > > do. > > > > > Yes, it is true that video memory issue can be handle > with DirectX. > The XF86SUP.SYS driver is as an example for you and others, so you > could come up with your ideas on how to achive those > functionalities > more > efficiently on Win32 > > > My biggest question is, do we want to load this driver at > > boot up, as a > > windows driver, as a cygwin driver, or as part of the X > > initialization? > > > > On OS/2 the driver loads at the boot time. He explained it one of > his messages, which is also posted on Cygwin-Xfree URL. > > > I'm thinking that it should be associated with cygwin, > > and load up with the > > cygwin.dll - or load up with X.. > > No it should not be associated with Cygwin or Cygwin1.dll > otherwise > you would be sacrifiying performance. We will need to > add needed to > code in > xc/programs/Xserver/hw/os-support/cygwin. This code will call the > driver when needed. I would send you Holger's code from > xc/programs/Xserver/hw/os-support/os2, which could server as an > example on how he achived it. > > > > > I also need to find out what he's patching in X in > > memory.. Is he patching > > the source, or the memory locations? I have to look into > > the X side.. > > Will send you his code from X-server which uses this driver as > example. > It will help you understand how it is used. > > > Suhaib > > > > > Any more info you got is cool :) > > > > > > -----Original Message----- > > From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] > > Sent: Wednesday, November 03, 1999 11:06 AM > > To: Mike MacDonald > > Subject: RE: Cygwin CD > > > > > > > > Have a look at the http://sourceware.cygnus.com/cygwin/xfree . > > There is a XF86SUP.SYS driver from OS/2 which we need to port > > to Windows NT. It should be ported using MSVC or other Win32 > > compiler, but not Cygwin for peformance reasons. It > has a lot of > > ASM code > > in it,. This what actually holding XFree86 port (X-server) for > > Cygwin (Windows). I lack the expertise and knowledge of > > assembly language and devices drivers. > > > > If you could get it ported to Win32 using MSVc or another Win32 > > compiler > > you would be of great help and would make X-servers functional. > > > > Suhaib > > > > > -----Original Message----- > > > From: cygwin-owner@sourceware.cygnus.com > > > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > > > Mike MacDonald > > > Sent: Wednesday, November 03, 1999 10:55 AM > > > To: 'ssiddiqi@nspm.ipass.net'; 'cygwin@sourceware.cygnus.com' > > > Subject: RE: Cygwin CD > > > > > > > > > > > > Is there anything I can do to help with XFree stuff? I'm > > > kinda new to X, > > > and Cygwin, and I don't have alot of time to spend on > > > stuff, but I do have > > > about 20 years of programming experience including ASM, > > > and who knows what > > > else.. (12 years professional - I'm working at GTE now > > > as a developer).. > > > > > > My constraints are that this is not a part of my job > > > right now, and I don't > > > use my computer at home anymore - so anything I look at > > > has to be during > > > breaks, or when I have time... > > > > > > > > > -- > > > Want to unsubscribe from this list? > > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > > > > > > From ssiddiqi@inspirepharm.com Mon Nov 8 13:14:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Mon, 08 Nov 1999 13:14:00 -0000 Subject: Driver for X11 References: Message-ID: Someone else? As far as I know Jan Rouvilan was looking into XF86SUP.SYS driver. If the e-mail is from him then sure please discuss with him, if it is froim someone else then I need to know first who is working. I prefer people communicate via mailing list instead of private messages. this way others can be kept informed and upto date. All we need Windows Nt and 98 support. DOS driver is not the way to go "I think". Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Monday, November 08, 1999 4:03 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: Driver for X11 > > > Ok, good. That makes sense. Ok, then I need to look at > as much source as > possible for the XF86SUP.SYS - The questions still in my > mind are this, do > we need two drivers, one a windows driver, and the other > a DOS driver for > the config.sys? Or will just a Windows driver that works > with NT and Win 98 > be fine? Then, something I prolly gotta figgure out > myself, is can I call > directx functions from inside of a driver.. Thats gonna > get a little > complicated.. Something like the driver sits there, then > when X tries to > communicate with it it makes the DX calls or something.. > > A dos driver could just open up video memory, but it > would have to be > disabled and replaced when windows loads up.. > > Basically, I have to dig around and get my hands dirty.. > I think I got some > emails from someone else who is working on this.. I > would like to hear more > about what hes doing, but I think I'm up to date. Theres > someone else who > is supposedly trying to do this that he mentioned.. I > don't want to > duplicate efforts with him either.. > > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Suhaib > Siddiqi > Sent: Monday, November 08, 1999 3:45 PM > To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com > Subject: RE: Driver for X11 > > > > No, that will not affect any driver. The XF86 4.0 has 3 > mechanisms > of loaing Xserver, static X-server (which is same as 3.3.x), > loadable, > and dlopen loadable. Regardless, each X-server still needs System > dependent drivers for accessing mouse, keyboard, and memomry etc. > > Suhaib > > > > -----Original Message----- > > From: cygwin-xfree-owner@sourceware.cygnus.com > > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Mike > > MacDonald > > Sent: Monday, November 08, 1999 3:38 PM > > To: 'cygwin-xfree@sourceware.cygnus.com' > > Subject: RE: Driver for X11 > > > > > > Ok, thanx. Another question, I'm hearing something about > > the graphics > > engine changing in newer versions of X, is that going to > > affect things if we > > just try to mimic what is done with XF86SUP.SYS using > > DirectX, or something > > that lets us get direct memory access? > > > > -----Original Message----- > > From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] > > Sent: Monday, November 08, 1999 3:18 PM > > To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com > > Subject: RE: Driver for X11 > > > > > > > > > > > > > > I read some more on this. Most things (video memory for > > > sure) can be gotten > > > using Direct X. I'm not sure about the IO Ports. I > > > have to read the DX > > > docs on that. I am sure there is a way.. None of this > > > should be to hard to > > > do. > > > > > > > > > Yes, it is true that video memory issue can be handle > > with DirectX. > > The XF86SUP.SYS driver is as an example for you and > others, so you > > could come up with your ideas on how to achive those > > functionalities > > more > > efficiently on Win32 > > > > > My biggest question is, do we want to load this driver at > > > boot up, as a > > > windows driver, as a cygwin driver, or as part of the X > > > initialization? > > > > > > > On OS/2 the driver loads at the boot time. He > explained it one of > > his messages, which is also posted on Cygwin-Xfree URL. > > > > > I'm thinking that it should be associated with cygwin, > > > and load up with the > > > cygwin.dll - or load up with X.. > > > > No it should not be associated with Cygwin or Cygwin1.dll > > otherwise > > you would be sacrifiying performance. We will need to > > add needed to > > code in > > xc/programs/Xserver/hw/os-support/cygwin. This code > will call the > > driver when needed. I would send you Holger's code from > > xc/programs/Xserver/hw/os-support/os2, which could server as an > > example on how he achived it. > > > > > > > > I also need to find out what he's patching in X in > > > memory.. Is he patching > > > the source, or the memory locations? I have to look into > > > the X side.. > > > > Will send you his code from X-server which uses this driver as > > example. > > It will help you understand how it is used. > > > > > > Suhaib > > > > > > > > Any more info you got is cool :) > > > > > > > > > -----Original Message----- > > > From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] > > > Sent: Wednesday, November 03, 1999 11:06 AM > > > To: Mike MacDonald > > > Subject: RE: Cygwin CD > > > > > > > > > > > > Have a look at the http://sourceware.cygnus.com/cygwin/xfree . > > > There is a XF86SUP.SYS driver from OS/2 which we need to port > > > to Windows NT. It should be ported using MSVC or other Win32 > > > compiler, but not Cygwin for peformance reasons. It > > has a lot of > > > ASM code > > > in it,. This what actually holding XFree86 port > (X-server) for > > > Cygwin (Windows). I lack the expertise and knowledge of > > > assembly language and devices drivers. > > > > > > If you could get it ported to Win32 using MSVc or > another Win32 > > > compiler > > > you would be of great help and would make X-servers > functional. > > > > > > Suhaib > > > > > > > -----Original Message----- > > > > From: cygwin-owner@sourceware.cygnus.com > > > > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > > > > Mike MacDonald > > > > Sent: Wednesday, November 03, 1999 10:55 AM > > > > To: 'ssiddiqi@nspm.ipass.net'; > 'cygwin@sourceware.cygnus.com' > > > > Subject: RE: Cygwin CD > > > > > > > > > > > > > > > > Is there anything I can do to help with XFree stuff? I'm > > > > kinda new to X, > > > > and Cygwin, and I don't have alot of time to spend on > > > > stuff, but I do have > > > > about 20 years of programming experience including ASM, > > > > and who knows what > > > > else.. (12 years professional - I'm working at GTE now > > > > as a developer).. > > > > > > > > My constraints are that this is not a part of my job > > > > right now, and I don't > > > > use my computer at home anymore - so anything I look at > > > > has to be during > > > > breaks, or when I have time... > > > > > > > > > > > > -- > > > > Want to unsubscribe from this list? > > > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > > > > > > > > > > From mmacdona@tsi.gte.com Mon Nov 8 13:25:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Mon, 08 Nov 1999 13:25:00 -0000 Subject: FW: DGA Message-ID: -----Original Message----- From: Federico Bianchi [ mailto:bianchi@pc-arte2.arte.unipi.it ] Sent: Monday, November 08, 1999 2:34 AM To: Mike MacDonald Subject: DGA I was forgetting - in one of his latest messages, Suhaib told me DGA is now defunct (it was only available on Glide servers on my release, and according to the documentation it looked like it was to be used as a general lower level layer for all the X11 stuff). This is one of the reasons why I want to see the newer sources to see what they implemented in its place. The other messages might be misleading without this update, so excuse me for the fuss. There is also a Scitech guy (Fortin) who is looking at the DirectDraw/DirectInput "driver" on his own - I will probably contact him as well. Best regards again Federico Bianchi Dipartimento di Storia delle Arti Universita` degli Studi di Pisa p.zza S.Matteo in Soarta, 2 - 56127 Pisa (Italy) tel. +39-050-587111 (cent.), +39-050-587224 (uff.) fax. +39-050-580128; e-mail: =================================================== !DISCLAIMER!: my e-mail reflects _my_own_ opinions! =================================================== From mmacdona@tsi.gte.com Mon Nov 8 13:39:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Mon, 08 Nov 1999 13:39:00 -0000 Subject: XF86Sup Message-ID: Ok, I'm d/ling the Win98 DDK right now, then I'll start trying to get something together. I need to know what X is gonna want, and how it expects to get it. Can you think of any reason to deviate from the way that XF86SUP did it? And if not, is the source readily available, or do I have to get it from you Suhaib? From ssiddiqi@inspirepharm.com Mon Nov 8 13:47:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Mon, 08 Nov 1999 13:47:00 -0000 Subject: XF86Sup References: Message-ID: The XF86SUP.SYS source is at http://sourceware.cygnus.com/cygwin/xfree If you could not find it there, let me know I would e-mail it to you. You need to study the code in os-support.zip which i sent you a while ago. that code uses XF86SUP driver. XFree86 needs those functions. How you provide them -- by a direct port of XF86SUP.SYS driver, a DX driver or a DDK is your choice and you decide which would be the best and easiest for you to do. XF86SUP.SYS has one advantage, that it also has /dev/pty. Later when we add MingW32 support, XF86SUP.SYS would come handy to support xterm, and xdm. Most of the XF86SUP.SYS code is in assembeler language (masm x86) written for IBM Visual Age C++ and OS/2 DDK. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Monday, November 08, 1999 4:40 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: XF86Sup > > > Ok, I'm d/ling the Win98 DDK right now, then I'll start > trying to get > something together. I need to know what X is gonna want, > and how it expects > to get it. Can you think of any reason to deviate from > the way that XF86SUP > did it? And if not, is the source readily available, or > do I have to get it > from you Suhaib? > From mmacdona@tsi.gte.com Mon Nov 8 16:03:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Mon, 08 Nov 1999 16:03:00 -0000 Subject: XF86SUP.SYS Message-ID: I don't see why this can't just be implemented as a service and a library.. The service would mainly be for pty, and I'm not sure that its necessary for that.. Windows doesn't have the Ring 0 requirement that OS/2 has I don't think. Plus Direct X eliminates the need for some of it.. I'll learn more as I go, but I don't think this needs to be, or should be a driver on the Windows platform. Honestly, I can't think of anything that couldn't just be included in a library.. Tell me if you've heard otherwise, and I have ALOT more research to do before I have a solid grasp of what needs to be done, but I think a straight port of XF86SUP.SYS as a .a archive will work (My opinion here is VERY subject to change :)) I think the only reason he has it loading in the config.sys is for the ring 0 requirements that are enforced by OS/2.. From bianchi@www.arte.unipi.it Tue Nov 9 00:53:00 1999 From: bianchi@www.arte.unipi.it (Federico Bianchi) Date: Tue, 09 Nov 1999 00:53:00 -0000 Subject: DGA, DirectX, XF86Sup.sys style port, etc. References: Message-ID: On Mon, 8 Nov 1999, Mike MacDonald wrote: > What is DGA? DirectX is the only way I know of to do properly what is > trying to be done here. DX can be used to get a pseudo linear buffer, > address ports, etc. Plus its guaranteed to work in every version of > windows, and new versions. Plus you can possibly used full screen and > windowed modes.. Anything else is a dangerous hack.. In fact. This was my main point in my discussion with Suhaib. Straight ports (like XF86Sup.sys) are [wonderful] hacks, and I wouldn't trust on them. > Why can't a driver be written with DirectX to provide the same services as > xf86sup.sys? Then would it need to interact directly with X? XF86Sup.sys is an OS/2 kernel mode driver (BTW: it is a mixed 16-32 bit stuff, so it would have to be rewritten from scratch anyway - look at the NE header). Apart from the pty support (which is downright useful, but whose need might be circumvented thanks to CygWin), it lets user mode programs access physical memory and I/O ports. Please note OS/2 also has a vastly better mode switching support than is usually available under NT - there are some NT drivers who know nothing but GDI32/DirectX can switch to non-VGA modes, and therefore don't save all of their context (Windows NT drivers are often downright _DIRTY_, by the way - some of them bypass the HAL altogether, some others busy-wait on the PCI/AGP bus when writing on the FIFO buffer, ...). You can use DirectX to simulate something like XF86Sup.sys, but I am not sure it would be a good design criterium. With all of its kludginess (especially since we would need to deal with DirectX 3 - there is no full retail DirectX 5 or 6 available for Windows NT 4.0), the DirectX layer is a pretty powerful hardware abstraction. In a nutshell, the OS/2 XFree86 port uses XFree86 video drivers. This _may_ be reasonable under OS/2 (and I wouldn't share this point of view, either - GRADD would probably be a better route; I am not sure whether it was available at the time the project started, though), but IMHO it _should_not_ be the case under Win32 - both for the presence of better video drivers under 9x/NT and for stability sake. My basic idea is to find and isolate the "driver" part in XFree86 and map it in terms of DirectX 3; in some older XFree86 a suitable candidate was the so-called Direct Graphics Access layer, but (as I told you before) this turned out to be a false step of mine, since not only DGA was not generalized, but it is now part of the "obsolete" APIs. Current versions use a different mechanism, based upon dlopen() - and I need to look at that more carefully, I am not sure I am grasping all of it yet. Looking at the eventual discussion thread: >>> Mike MacDonald >>> Ok, good. That makes sense. Ok, then I need to look at as much source as possible for the XF86SUP.SYS - The questions still in my mind are this, do we need two drivers, one a windows driver, and the other a DOS driver for the config.sys? Or will just a Windows driver that works with NT and Win 98 be fine? Then, something I prolly gotta figgure out myself, is can I call directx functions from inside of a driver.. Thats gonna get a little complicated.. Something like the driver sits there, then when X tries to communicate with it it makes the DX calls or something.. ..... <<< Mike MacDonald <<< You certainly don't need a DOS driver. You can (sort of) call DirectX COM APIs from a driver posting a message to a "shim" Win32 user mode application, but I am not sure you need a driver at all (see above); I think all you need may be done in a safer and better way from user mode, either calling the DirectX APIs or by extending the XLib over GDI code I found in the rxvt Win32 port (this presents a lot of other nasties, but would have a sheer advantage in transparently handling X11 apps much like Win32 ones, e.g. placing them on the same desktop - and performance might be improved by following Emanuele Aliberti suggestion to use NTAPI INT 2Eh calls where available instead of their user mode GDI32.DLL counterparts). >>> Suhaib Siddiqi >>> ... I prefer people communicate via mailing list instead of private messages. this way others can be kept informed and upto date. All we need Windows Nt and 98 support. DOS driver is not the way to go "I think". <<< Suhaib Siddiqi <<< I couldn't agree more with this latter point. I often use private messages to avoid noise on the mailing list, but Suhaib's view makes sense. >>> Mike MacDonald >>> I don't see why this can't just be implemented as a service and a library.. The service would mainly be for pty, and I'm not sure that its necessary for that.. Windows doesn't have the Ring 0 requirement that OS/2 has I don't think. Plus Direct X eliminates the need for some of it.. I'll learn more as I go, but I don't think this needs to be, or should be a driver on the Windows platform. Honestly, I can't think of anything that couldn't just be included in a library.. Tell me if you've heard otherwise, and I have ALOT more research to do before I have a solid grasp of what needs to be done, but I think a straight port of XF86SUP.SYS as a .a archive will work (My opinion here is VERY subject to change :)) I think the only reason he has it loading in the config.sys is for the ring 0 requirements that are enforced by OS/2.. <<< Mike MacDonald <<< In fact. The pty support might probably be taken more profitably from the CygWin*.dll code, the input handled by means of DirectInput and the display through DirectDraw. I am not sure Ring0 was required even under OS/2 (thanks to GRADD, see above), but this is the route they chose at that time. Comments, suggestions, errata fixes, discussion welcome. No flames, please... Federico Bianchi Dipartimento di Storia delle Arti Universita` degli Studi di Pisa p.zza S.Matteo in Soarta, 2 - 56127 Pisa (Italy) tel. +39-050-587111 (cent.), +39-050-587224 (uff.) fax. +39-050-580128; e-mail: =================================================== !DISCLAIMER!: my e-mail reflects _my_own_ opinions! =================================================== From ssiddiqi@inspirepharm.com Tue Nov 9 04:07:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Tue, 09 Nov 1999 04:07:00 -0000 Subject: DGA, DirectX, XF86Sup.sys style port, etc. References: Message-ID: Fredrico you keep bringing same points over and over again. There is no need to confuse DGA with drivers functionality we are rying to achive for XFree86 servers. XF86SUP.SYS is not a mix 16 and 32 bit driver. It is a 32 bit driver. Word DOS is code should not be confused with DOS as known on Windows. It is DOS32 under OS/2. Please let other developers think and utilize their knowledge. If you think you could do a better job, then you are most welcome to contribute code. Regards Suhaib > -----Original Message----- > From: Federico Bianchi [ mailto:bianchi@pc-arte2.arte.unipi.it ] > Sent: Tuesday, November 09, 1999 3:51 AM > To: Mike MacDonald > Cc: Suhaib Siddiqi; Jan Rouvillain; Emanuele Aliberti; > XFree86 over > CygWin Mailing List > Subject: DGA, DirectX, XF86Sup.sys style port, etc. > > > On Mon, 8 Nov 1999, Mike MacDonald wrote: > > > What is DGA? DirectX is the only way I know of to do > properly what is > > trying to be done here. DX can be used to get a > pseudo linear buffer, > > address ports, etc. Plus its guaranteed to work in > every version of > > windows, and new versions. Plus you can possibly used > full screen and > > windowed modes.. Anything else is a dangerous hack.. > > In fact. This was my main point in my discussion with > Suhaib. Straight > ports (like XF86Sup.sys) are [wonderful] hacks, and I > wouldn't trust on > them. > > > Why can't a driver be written with DirectX to provide > the same services as > > xf86sup.sys? Then would it need to interact directly with X? > > XF86Sup.sys is an OS/2 kernel mode driver (BTW: it is a > mixed 16-32 bit > stuff, so it would have to be rewritten from scratch > anyway - look at the > NE header). Apart from the pty support (which is > downright useful, but > whose need might be circumvented thanks to CygWin), it > lets user mode > programs access physical memory and I/O ports. Please > note OS/2 also has > a vastly better mode switching support than is usually > available under NT > - there are some NT drivers who know nothing but > GDI32/DirectX can switch > to non-VGA modes, and therefore don't save all of their > context (Windows > NT drivers are often downright _DIRTY_, by the way - some > of them bypass > the HAL altogether, some others busy-wait on the PCI/AGP > bus when writing > on the FIFO buffer, ...). > > You can use DirectX to simulate something like > XF86Sup.sys, but I am not > sure it would be a good design criterium. With all of its > kludginess > (especially since we would need to deal with DirectX 3 - > there is no full > retail DirectX 5 or 6 available for Windows NT 4.0), the > DirectX layer is > a pretty powerful hardware abstraction. > > In a nutshell, the OS/2 XFree86 port uses XFree86 video > drivers. This > _may_ be reasonable under OS/2 (and I wouldn't share this > point of view, > either - GRADD would probably be a better route; I am not > sure whether it > was available at the time the project started, though), > but IMHO it > _should_not_ be the case under Win32 - both for the > presence of better > video drivers under 9x/NT and for stability sake. > > My basic idea is to find and isolate the "driver" part in > XFree86 and map > it in terms of DirectX 3; in some older XFree86 a > suitable candidate was > the so-called Direct Graphics Access layer, but (as I told you > before) this turned out to be a false step of mine, since > not only DGA was > not generalized, but it is now part of the "obsolete" > APIs. Current > versions use a different mechanism, based upon dlopen() - > and I need to > look at that more carefully, I am not sure I am grasping > all of it yet. > > Looking at the eventual discussion thread: > > >>> Mike MacDonald >>> > Ok, good. That makes sense. Ok, then I need to look at > as much source as > possible for the XF86SUP.SYS - The questions still in my > mind are this, do > we need two drivers, one a windows driver, and the other > a DOS driver for > the config.sys? Or will just a Windows driver that works > with NT and Win 98 > be fine? Then, something I prolly gotta figgure out > myself, is can I call > directx functions from inside of a driver.. Thats gonna > get a little > complicated.. Something like the driver sits there, then > when X tries to > communicate with it it makes the DX calls or something.. > ..... > <<< Mike MacDonald <<< > > You certainly don't need a DOS driver. You can (sort of) > call DirectX > COM APIs from a driver posting a message to a "shim" > Win32 user mode > application, but I am not sure you need a driver at all > (see above); I > think all you need may be done in a safer and better way > from user mode, > either calling the DirectX APIs or by extending the XLib > over GDI code > I found in the rxvt Win32 port (this presents a lot of > other nasties, but > would have a sheer advantage in transparently handling > X11 apps much like > Win32 ones, e.g. placing them on the same desktop - and > performance might > be improved by following Emanuele Aliberti suggestion to > use NTAPI INT 2Eh > calls where available instead of their user mode > GDI32.DLL counterparts). > > >>> Suhaib Siddiqi >>> > ... > I prefer people communicate via mailing list instead of private > messages. this way others can be kept informed and upto date. > > All we need Windows Nt and 98 support. DOS driver is not > the way to > go "I think". > <<< Suhaib Siddiqi <<< > > I couldn't agree more with this latter point. I often use > private messages > to avoid noise on the mailing list, but Suhaib's view makes sense. > > >>> Mike MacDonald >>> > I don't see why this can't just be implemented as a > service and a library.. > The service would mainly be for pty, and I'm not sure > that its necessary for > that.. Windows doesn't have the Ring 0 requirement that > OS/2 has I don't > think. Plus Direct X eliminates the need for some of > it.. I'll learn more > as I go, but I don't think this needs to be, or should be > a driver on the > Windows platform. > > Honestly, I can't think of anything that couldn't just be > included in a > library.. Tell me if you've heard otherwise, and I have > ALOT more research > to do before I have a solid grasp of what needs to be > done, but I think a > straight port of XF86SUP.SYS as a .a archive will work > (My opinion here is > VERY subject to change :)) I think the only reason he > has it loading in the > config.sys is for the ring 0 requirements that are > enforced by OS/2.. > <<< Mike MacDonald <<< > > In fact. The pty support might probably be taken more > profitably from the > CygWin*.dll code, the input handled by means of > DirectInput and the > display through DirectDraw. I am not sure Ring0 was > required even under > OS/2 (thanks to GRADD, see above), but this is the route > they chose at > that time. > > Comments, suggestions, errata fixes, discussion welcome. > No flames, > please... > > Federico Bianchi > Dipartimento di Storia delle Arti > Universita` degli Studi di Pisa > p.zza S.Matteo in Soarta, 2 - 56127 > Pisa (Italy) > tel. +39-050-587111 (cent.), > +39-050-587224 (uff.) > fax. +39-050-580128; e-mail: > > > =================================================== > !DISCLAIMER!: my e-mail reflects > _my_own_ opinions! > > =================================================== > From ssiddiqi@inspirepharm.com Tue Nov 9 04:10:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Tue, 09 Nov 1999 04:10:00 -0000 Subject: XF86SUP.SYS References: Message-ID: That is right Windows does not use Ring 0. I also thought of provding these functionality as a static lib or a DLL. Actually, the OS specific code for various OS in xfree86/os-support is built as a static lib during XF86 compilation. I would suggest using DirectX 3.0 so the same driver could be used on Win9x and NT 4.0. Regards Suhaib > > I don't see why this can't just be implemented as a > service and a library.. > The service would mainly be for pty, and I'm not sure > that its necessary for > that.. Windows doesn't have the Ring 0 requirement that > OS/2 has I don't > think. Plus Direct X eliminates the need for some of > it.. I'll learn more > as I go, but I don't think this needs to be, or should be > a driver on the > Windows platform. > > Honestly, I can't think of anything that couldn't just be > included in a > library.. Tell me if you've heard otherwise, and I have > ALOT more research > to do before I have a solid grasp of what needs to be > done, but I think a > straight port of XF86SUP.SYS as a .a archive will work > (My opinion here is > VERY subject to change :)) I think the only reason he > has it loading in the > config.sys is for the ring 0 requirements that are > enforced by OS/2.. > From ssiddiqi@inspirepharm.com Tue Nov 9 07:29:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Tue, 09 Nov 1999 07:29:00 -0000 Subject: [Fwd: cygwin-xfree Digest 9 Nov 1999 08:53:09 -0000 Issue 59] References: <38283BBC.45A0737A@cs.unc.edu> Message-ID: Sorry, I have no control over cygwin-xfree digest. I maintain only URL and update cygwin-xfree source tree, and binaries. I am forwarding it to cygwin-xfree list. I hope someone in-charge will reply to you. regards Suhaib > -----Original Message----- > From: Jeffrey Juliano [ mailto:juliano@cs.unc.edu ] > Sent: Tuesday, November 09, 1999 10:20 AM > To: ssiddiqi@inspirepharm.com > Subject: [Fwd: cygwin-xfree Digest 9 Nov 1999 08:53:09 > -0000 Issue 59] > > > Hi, > > I'm subscribed to the digest version of the cygwin-xfree > list. below is > a copy of the last email I got from that list. If you > look at the last > two messages, you'll see that the names on the To: and > From: lines have > the wrong names on them. The names have been switched so that the > message looks like it was sent *by* the person it was > actually sent > *to*. > > (well, actually, the *last* message doesn't count. I > mean the 2nd and > 3rd last messages) > > Didn't know who to report this to, so I'm sending to you > hoping you > forward to the appropriate party. > > -jeff > > > cygwin-xfree-digest-help@sourceware.cygnus.com wrote: > > > > cygwin-xfree Digest 9 Nov 1999 08:53:09 -0000 Issue 59 > > > > Topics (messages 286 through 297): > > > > Xlib porting > > 286 by: T????nis Vaga > > 287 by: "Suhaib Siddiqi" > > > > Driver for X11 > > 288 by: "Suhaib Siddiqi" > > 289 by: Mike MacDonald > > 290 by: "Suhaib Siddiqi" > > 291 by: Mike MacDonald > > 292 by: "Suhaib Siddiqi" > > > > FW: DGA > > 293 by: Mike MacDonald > > > > XF86Sup > > 294 by: Mike MacDonald > > 295 by: "Suhaib Siddiqi" > > > > XF86SUP.SYS > > 296 by: Mike MacDonald > > > > DGA, DirectX, XF86Sup.sys style port, etc. > > 297 by: Federico Bianchi > > > > Administrivia: > > > > To subscribe to the digest, e-mail: > > cygwin-xfree-digest-subscribe@sourceware.cygnus.com > > > > To unsubscribe from the digest, e-mail: > > cygwin-xfree-digest-unsubscribe@sourceware.cygnus.com > > > > To post to the list, e-mail: > > cygwin-xfree@sourceware.cygnus.com > > > > > ---------------------------------------------------------- > ------------ > > > > > ---------------------------------------------------------- > -------------- > > > > Subject: RE: Driver for X11 > > Date: Mon, 8 Nov 1999 15:17:32 -0500 > > From: "Suhaib Siddiqi" > > To: "Mike MacDonald" , > > > > > > Hi! > > > > What is the easiest way to port X app to cygwin (under > win95)? Do i really > > need get all these X client and server files? They > about 30M. I remember > > Moonlight Creator uses b19 dll but did'nt need X server > for running. > > So, what files i should get and what not? > > > > tonis > > > > > ---------------------------------------------------------- > -------------- > > > > Subject: RE: Driver for X11 > > Date: Mon, 8 Nov 1999 15:38:02 -0500 > > From: Mike MacDonald > > To: "'cygwin-xfree@sourceware.cygnus.com'" > > > > > > The X-server files are of no use at the moment because > they X-server > > is not functional yet. read the FAQ at > > http://sourceware.cygnus.com/cygwin/xfree . > > > > You need X11 libs which are part of cygwin-xfree > archive and link > > your code to X libs as you do on UNIX. > > > > Suhaib > > > > > -----Original Message----- > > > From: cygwin-xfree-owner@sourceware.cygnus.com > > > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > > > Behalf Of T=F5nis Vaga > > > Sent: Monday, November 08, 1999 6:36 AM > > > To: cygwin-xfree@sourceware.cygnus.com > > > Subject: Xlib porting > > > > > > > > > > > > Hi! > > > > > > What is the easiest way to port X app to cygwin (under > > > win95)? Do i really > > > need get all these X client and server files? They about > > > 30M. I remember > > > Moonlight Creator uses b19 dll but did'nt need X server > > > for running. > > > So, what files i should get and what not? > > > > > > tonis > > > > > > > > > > > > > > > > > ---------------------------------------------------------- > -------------- > > > > Subject: RE: Driver for X11 > > Date: Mon, 8 Nov 1999 15:45:04 -0500 > > From: "Suhaib Siddiqi" > > To: "Mike MacDonald" , > > > > > > > > > > I read some more on this. Most things (video memory for > > > sure) can be gotten > > > using Direct X. I'm not sure about the IO Ports. I > > > have to read the DX > > > docs on that. I am sure there is a way.. None of this > > > should be to hard to > > > do. > > > > > > > Yes, it is true that video memory issue can be handle > with DirectX. > > The XF86SUP.SYS driver is as an example for you and > others, so you > > could come up with your ideas on how to achive those > functionalities > > more > > efficiently on Win32 > > > > > My biggest question is, do we want to load this driver at > > > boot up, as a > > > windows driver, as a cygwin driver, or as part of the X > > > initialization? > > > > > > > On OS/2 the driver loads at the boot time. He > explained it one of > > his messages, which is also posted on Cygwin-Xfree URL. > > > > > I'm thinking that it should be associated with cygwin, > > > and load up with the > > > cygwin.dll - or load up with X.. > > > > No it should not be associated with Cygwin or > Cygwin1.dll otherwise > > you would be sacrifiying performance. We will need to > add needed to > > code in > > xc/programs/Xserver/hw/os-support/cygwin. This code > will call the > > driver when needed. I would send you Holger's code from > > xc/programs/Xserver/hw/os-support/os2, which could server as an > > example on how he achived it. > > > > > > > > I also need to find out what he's patching in X in > > > memory.. Is he patching > > > the source, or the memory locations? I have to look into > > > the X side.. > > > > Will send you his code from X-server which uses this driver as > > example. > > It will help you understand how it is used. > > > > Suhaib > > > > > > > > Any more info you got is cool :) > > > > > > > > > -----Original Message----- > > > From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] > > > Sent: Wednesday, November 03, 1999 11:06 AM > > > To: Mike MacDonald > > > Subject: RE: Cygwin CD > > > > > > > > > > > > Have a look at the http://sourceware.cygnus.com/cygwin/xfree . > > > There is a XF86SUP.SYS driver from OS/2 which we need to port > > > to Windows NT. It should be ported using MSVC or other Win32 > > > compiler, but not Cygwin for peformance reasons. It > has a lot of > > > ASM code > > > in it,. This what actually holding XFree86 port > (X-server) for > > > Cygwin (Windows). I lack the expertise and knowledge of > > > assembly language and devices drivers. > > > > > > If you could get it ported to Win32 using MSVc or > another Win32 > > > compiler > > > you would be of great help and would make X-servers > functional. > > > > > > Suhaib > > > > > > > -----Original Message----- > > > > From: cygwin-owner@sourceware.cygnus.com > > > > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > > > > Mike MacDonald > > > > Sent: Wednesday, November 03, 1999 10:55 AM > > > > To: 'ssiddiqi@nspm.ipass.net'; > 'cygwin@sourceware.cygnus.com' > > > > Subject: RE: Cygwin CD > > > > > > > > > > > > > > > > Is there anything I can do to help with XFree stuff? I'm > > > > kinda new to X, > > > > and Cygwin, and I don't have alot of time to spend on > > > > stuff, but I do have > > > > about 20 years of programming experience including ASM, > > > > and who knows what > > > > else.. (12 years professional - I'm working at GTE now > > > > as a developer).. > > > > > > > > My constraints are that this is not a part of my job > > > > right now, and I don't > > > > use my computer at home anymore - so anything I look at > > > > has to be during > > > > breaks, or when I have time... > > > > > > > > > > > > -- > > > > Want to unsubscribe from this list? > > > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > > > > > > > > > > > > ---------------------------------------------------------- > -------------- > > > > Subject: RE: Driver for X11 > > Date: Mon, 8 Nov 1999 16:03:19 -0500 > > From: Mike MacDonald > > To: "'cygwin-xfree@sourceware.cygnus.com'" > > > > > > Ok, thanx. Another question, I'm hearing something > about the graphics > > engine changing in newer versions of X, is that going > to affect things if we > > just try to mimic what is done with XF86SUP.SYS using > DirectX, or something > > that lets us get direct memory access? > > > > -----Original Message----- > > From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] > > Sent: Monday, November 08, 1999 3:18 PM > > To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com > > Subject: RE: Driver for X11 > > > > > > > > I read some more on this. Most things (video memory for > > > sure) can be gotten > > > using Direct X. I'm not sure about the IO Ports. I > > > have to read the DX > > > docs on that. I am sure there is a way.. None of this > > > should be to hard to > > > do. > > > > > > > Yes, it is true that video memory issue can be handle > with DirectX. > > The XF86SUP.SYS driver is as an example for you and > others, so you > > could come up with your ideas on how to achive those > functionalities > > more > > efficiently on Win32 > > > > > My biggest question is, do we want to load this driver at > > > boot up, as a > > > windows driver, as a cygwin driver, or as part of the X > > > initialization? > > > > > > > On OS/2 the driver loads at the boot time. He > explained it one of > > his messages, which is also posted on Cygwin-Xfree URL. > > > > > I'm thinking that it should be associated with cygwin, > > > and load up with the > > > cygwin.dll - or load up with X.. > > > > No it should not be associated with Cygwin or > Cygwin1.dll otherwise > > you would be sacrifiying performance. We will need to > add needed to > > code in > > xc/programs/Xserver/hw/os-support/cygwin. This code > will call the > > driver when needed. I would send you Holger's code from > > xc/programs/Xserver/hw/os-support/os2, which could server as an > > example on how he achived it. > > > > > > > > I also need to find out what he's patching in X in > > > memory.. Is he patching > > > the source, or the memory locations? I have to look into > > > the X side.. > > > > Will send you his code from X-server which uses this driver as > > example. > > It will help you understand how it is used. > > > > Suhaib > > > > > > > > Any more info you got is cool :) > > > > > > > > > -----Original Message----- > > > From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] > > > Sent: Wednesday, November 03, 1999 11:06 AM > > > To: Mike MacDonald > > > Subject: RE: Cygwin CD > > > > > > > > > > > > Have a look at the http://sourceware.cygnus.com/cygwin/xfree . > > > There is a XF86SUP.SYS driver from OS/2 which we need to port > > > to Windows NT. It should be ported using MSVC or other Win32 > > > compiler, but not Cygwin for peformance reasons. It > has a lot of > > > ASM code > > > in it,. This what actually holding XFree86 port > (X-server) for > > > Cygwin (Windows). I lack the expertise and knowledge of > > > assembly language and devices drivers. > > > > > > If you could get it ported to Win32 using MSVc or > another Win32 > > > compiler > > > you would be of great help and would make X-servers > functional. > > > > > > Suhaib > > > > > > > -----Original Message----- > > > > From: cygwin-owner@sourceware.cygnus.com > > > > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > > > > Mike MacDonald > > > > Sent: Wednesday, November 03, 1999 10:55 AM > > > > To: 'ssiddiqi@nspm.ipass.net'; > 'cygwin@sourceware.cygnus.com' > > > > Subject: RE: Cygwin CD > > > > > > > > > > > > > > > > Is there anything I can do to help with XFree stuff? I'm > > > > kinda new to X, > > > > and Cygwin, and I don't have alot of time to spend on > > > > stuff, but I do have > > > > about 20 years of programming experience including ASM, > > > > and who knows what > > > > else.. (12 years professional - I'm working at GTE now > > > > as a developer).. > > > > > > > > My constraints are that this is not a part of my job > > > > right now, and I don't > > > > use my computer at home anymore - so anything I look at > > > > has to be during > > > > breaks, or when I have time... > > > > > > > > > > > > -- > > > > Want to unsubscribe from this list? > > > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > > > > > > > > > > > > ---------------------------------------------------------- > -------------- > > > > Subject: XF86Sup > > Date: Mon, 8 Nov 1999 16:39:30 -0500 > > From: Mike MacDonald > > To: "'cygwin-xfree@sourceware.cygnus.com'" > > > > > > No, that will not affect any driver. The XF86 4.0 has > 3 mechanisms > > of loaing Xserver, static X-server (which is same as 3.3.x), > > loadable, > > and dlopen loadable. Regardless, each X-server still > needs System > > dependent drivers for accessing mouse, keyboard, and > memomry etc. > > > > Suhaib > > > > > -----Original Message----- > > > From: cygwin-xfree-owner@sourceware.cygnus.com > > > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Mike > > > MacDonald > > > Sent: Monday, November 08, 1999 3:38 PM > > > To: 'cygwin-xfree@sourceware.cygnus.com' > > > Subject: RE: Driver for X11 > > > > > > > > > Ok, thanx. Another question, I'm hearing something about > > > the graphics > > > engine changing in newer versions of X, is that going to > > > affect things if we > > > just try to mimic what is done with XF86SUP.SYS using > > > DirectX, or something > > > that lets us get direct memory access? > > > > > > -----Original Message----- > > > From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] > > > Sent: Monday, November 08, 1999 3:18 PM > > > To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com > > > Subject: RE: Driver for X11 > > > > > > > > > > > > > > > > > > > > I read some more on this. Most things (video memory for > > > > sure) can be gotten > > > > using Direct X. I'm not sure about the IO Ports. I > > > > have to read the DX > > > > docs on that. I am sure there is a way.. None of this > > > > should be to hard to > > > > do. > > > > > > > > > > > > > Yes, it is true that video memory issue can be handle > > > with DirectX. > > > The XF86SUP.SYS driver is as an example for you and > others, so you > > > could come up with your ideas on how to achive those > > > functionalities > > > more > > > efficiently on Win32 > > > > > > > My biggest question is, do we want to load this driver at > > > > boot up, as a > > > > windows driver, as a cygwin driver, or as part of the X > > > > initialization? > > > > > > > > > > On OS/2 the driver loads at the boot time. He > explained it one of > > > his messages, which is also posted on Cygwin-Xfree URL. > > > > > > > I'm thinking that it should be associated with cygwin, > > > > and load up with the > > > > cygwin.dll - or load up with X.. > > > > > > No it should not be associated with Cygwin or Cygwin1.dll > > > otherwise > > > you would be sacrifiying performance. We will need to > > > add needed to > > > code in > > > xc/programs/Xserver/hw/os-support/cygwin. This code > will call the > > > driver when needed. I would send you Holger's code from > > > xc/programs/Xserver/hw/os-support/os2, which could > server as an > > > example on how he achived it. > > > > > > > > > > > I also need to find out what he's patching in X in > > > > memory.. Is he patching > > > > the source, or the memory locations? I have to look into > > > > the X side.. > > > > > > Will send you his code from X-server which uses this driver as > > > example. > > > It will help you understand how it is used. > > > > > > > > > Suhaib > > > > > > > > > > > Any more info you got is cool :) > > > > > > > > > > > > -----Original Message----- > > > > From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] > > > > Sent: Wednesday, November 03, 1999 11:06 AM > > > > To: Mike MacDonald > > > > Subject: RE: Cygwin CD > > > > > > > > > > > > > > > > Have a look at the > http://sourceware.cygnus.com/cygwin/xfree . > > > > There is a XF86SUP.SYS driver from OS/2 which we > need to port > > > > to Windows NT. It should be ported using MSVC or > other Win32 > > > > compiler, but not Cygwin for peformance reasons. It > > > has a lot of > > > > ASM code > > > > in it,. This what actually holding XFree86 port > (X-server) for > > > > Cygwin (Windows). I lack the expertise and knowledge of > > > > assembly language and devices drivers. > > > > > > > > If you could get it ported to Win32 using MSVc or > another Win32 > > > > compiler > > > > you would be of great help and would make X-servers > functional. > > > > > > > > Suhaib > > > > > > > > > -----Original Message----- > > > > > From: cygwin-owner@sourceware.cygnus.com > > > > > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > > > > > Mike MacDonald > > > > > Sent: Wednesday, November 03, 1999 10:55 AM > > > > > To: 'ssiddiqi@nspm.ipass.net'; > 'cygwin@sourceware.cygnus.com' > > > > > Subject: RE: Cygwin CD > > > > > > > > > > > > > > > > > > > > Is there anything I can do to help with XFree stuff? I'm > > > > > kinda new to X, > > > > > and Cygwin, and I don't have alot of time to spend on > > > > > stuff, but I do have > > > > > about 20 years of programming experience including ASM, > > > > > and who knows what > > > > > else.. (12 years professional - I'm working at GTE now > > > > > as a developer).. > > > > > > > > > > My constraints are that this is not a part of my job > > > > > right now, and I don't > > > > > use my computer at home anymore - so anything I look at > > > > > has to be during > > > > > breaks, or when I have time... > > > > > > > > > > > > > > > -- > > > > > Want to unsubscribe from this list? > > > > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > > > > > > > > > > > > > > > > > ---------------------------------------------------------- > -------------- > > > > Subject: RE: XF86Sup > > Date: Mon, 8 Nov 1999 16:43:16 -0500 > > From: "Suhaib Siddiqi" > > To: "Mike MacDonald" , > > > > > > Ok, good. That makes sense. Ok, then I need to look > at as much source as > > possible for the XF86SUP.SYS - The questions still in > my mind are this, do > > we need two drivers, one a windows driver, and the > other a DOS driver for > > the config.sys? Or will just a Windows driver that > works with NT and Win 98 > > be fine? Then, something I prolly gotta figgure out > myself, is can I call > > directx functions from inside of a driver.. Thats > gonna get a little > > complicated.. Something like the driver sits there, > then when X tries to > > communicate with it it makes the DX calls or something.. > > > > A dos driver could just open up video memory, but it > would have to be > > disabled and replaced when windows loads up.. > > > > Basically, I have to dig around and get my hands > dirty.. I think I got some > > emails from someone else who is working on this.. I > would like to hear more > > about what hes doing, but I think I'm up to date. > Theres someone else who > > is supposedly trying to do this that he mentioned.. I > don't want to > > duplicate efforts with him either.. > > > > -----Original Message----- > > From: cygwin-xfree-owner@sourceware.cygnus.com > > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Suhaib > > Siddiqi > > Sent: Monday, November 08, 1999 3:45 PM > > To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com > > Subject: RE: Driver for X11 > > > > No, that will not affect any driver. The XF86 4.0 has > 3 mechanisms > > of loaing Xserver, static X-server (which is same as 3.3.x), > > loadable, > > and dlopen loadable. Regardless, each X-server still > needs System > > dependent drivers for accessing mouse, keyboard, and > memomry etc. > > > > Suhaib > > > > > -----Original Message----- > > > From: cygwin-xfree-owner@sourceware.cygnus.com > > > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Mike > > > MacDonald > > > Sent: Monday, November 08, 1999 3:38 PM > > > To: 'cygwin-xfree@sourceware.cygnus.com' > > > Subject: RE: Driver for X11 > > > > > > > > > Ok, thanx. Another question, I'm hearing something about > > > the graphics > > > engine changing in newer versions of X, is that going to > > > affect things if we > > > just try to mimic what is done with XF86SUP.SYS using > > > DirectX, or something > > > that lets us get direct memory access? > > > > > > -----Original Message----- > > > From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] > > > Sent: Monday, November 08, 1999 3:18 PM > > > To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com > > > Subject: RE: Driver for X11 > > > > > > > > > > > > > > > > > > > > I read some more on this. Most things (video memory for > > > > sure) can be gotten > > > > using Direct X. I'm not sure about the IO Ports. I > > > > have to read the DX > > > > docs on that. I am sure there is a way.. None of this > > > > should be to hard to > > > > do. > > > > > > > > > > > > > Yes, it is true that video memory issue can be handle > > > with DirectX. > > > The XF86SUP.SYS driver is as an example for you and > others, so you > > > could come up with your ideas on how to achive those > > > functionalities > > > more > > > efficiently on Win32 > > > > > > > My biggest question is, do we want to load this driver at > > > > boot up, as a > > > > windows driver, as a cygwin driver, or as part of the X > > > > initialization? > > > > > > > > > > On OS/2 the driver loads at the boot time. He > explained it one of > > > his messages, which is also posted on Cygwin-Xfree URL. > > > > > > > I'm thinking that it should be associated with cygwin, > > > > and load up with the > > > > cygwin.dll - or load up with X.. > > > > > > No it should not be associated with Cygwin or Cygwin1.dll > > > otherwise > > > you would be sacrifiying performance. We will need to > > > add needed to > > > code in > > > xc/programs/Xserver/hw/os-support/cygwin. This code > will call the > > > driver when needed. I would send you Holger's code from > > > xc/programs/Xserver/hw/os-support/os2, which could > server as an > > > example on how he achived it. > > > > > > > > > > > I also need to find out what he's patching in X in > > > > memory.. Is he patching > > > > the source, or the memory locations? I have to look into > > > > the X side.. > > > > > > Will send you his code from X-server which uses this driver as > > > example. > > > It will help you understand how it is used. > > > > > > > > > Suhaib > > > > > > > > > > > Any more info you got is cool :) > > > > > > > > > > > > -----Original Message----- > > > > From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] > > > > Sent: Wednesday, November 03, 1999 11:06 AM > > > > To: Mike MacDonald > > > > Subject: RE: Cygwin CD > > > > > > > > > > > > > > > > Have a look at the > http://sourceware.cygnus.com/cygwin/xfree . > > > > There is a XF86SUP.SYS driver from OS/2 which we > need to port > > > > to Windows NT. It should be ported using MSVC or > other Win32 > > > > compiler, but not Cygwin for peformance reasons. It > > > has a lot of > > > > ASM code > > > > in it,. This what actually holding XFree86 port > (X-server) for > > > > Cygwin (Windows). I lack the expertise and knowledge of > > > > assembly language and devices drivers. > > > > > > > > If you could get it ported to Win32 using MSVc or > another Win32 > > > > compiler > > > > you would be of great help and would make X-servers > functional. > > > > > > > > Suhaib > > > > > > > > > -----Original Message----- > > > > > From: cygwin-owner@sourceware.cygnus.com > > > > > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of > > > > > Mike MacDonald > > > > > Sent: Wednesday, November 03, 1999 10:55 AM > > > > > To: 'ssiddiqi@nspm.ipass.net'; > 'cygwin@sourceware.cygnus.com' > > > > > Subject: RE: Cygwin CD > > > > > > > > > > > > > > > > > > > > Is there anything I can do to help with XFree stuff? I'm > > > > > kinda new to X, > > > > > and Cygwin, and I don't have alot of time to spend on > > > > > stuff, but I do have > > > > > about 20 years of programming experience including ASM, > > > > > and who knows what > > > > > else.. (12 years professional - I'm working at GTE now > > > > > as a developer).. > > > > > > > > > > My constraints are that this is not a part of my job > > > > > right now, and I don't > > > > > use my computer at home anymore - so anything I look at > > > > > has to be during > > > > > breaks, or when I have time... > > > > > > > > > > > > > > > -- > > > > > Want to unsubscribe from this list? > > > > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > > > > > > > > > > > > > > > > > ---------------------------------------------------------- > -------------- > > > > Subject: DGA, DirectX, XF86Sup.sys style port, etc. > > Date: Tue, 9 Nov 1999 09:51:21 +0100 (CET) > > From: Federico Bianchi > > To: Mike MacDonald > > CC: Suhaib Siddiqi , > > Jan Rouvillain , Emanuele > Aliberti , > > XFree86 over CygWin Mailing List > > > > > Name: null > > null Type: unspecified type > (APPLICATION/octet-stream) > > Encoding: BASE64 > > Download Status: Not downloaded with message > From mmacdona@tsi.gte.com Tue Nov 9 07:41:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Tue, 09 Nov 1999 07:41:00 -0000 Subject: XF86SUP.SYS Message-ID: 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. From mmacdona@tsi.gte.com Tue Nov 9 07:48:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Tue, 09 Nov 1999 07:48:00 -0000 Subject: XF86SUP.SYS Message-ID: Well, its been a while, but if I remember right, DX will set up a linear, or pseudolinear, framebuffer for you, and return a pointer to it. This is how most games are written - they use DX to get a framebuffer, and video card access, then they use ASM to do their blts, etc, because it is usually quicker. I'm assuming I can do the same thing here for video memory, and just use DX to pass me back a pointer. What I'm not sure about is accessing the ports on the video card, and how quickly. I'm assuming that there is a method for quickly addressing a video port built into DX, or if you have a full screen mode you might have access to the video card at that point. This is what I don't know. I need to do some experimentation to find out. So basically it would be taking advantage of DX for everything that might require a driver to accomplish. If DX doesn't do this stuff, things start to get sticky.. Should be able to find solutions for it though.. -----Original Message----- From: Jan Rouvillain [ mailto:jro@cotas.dk ] Sent: Tuesday, November 09, 1999 1:54 AM To: 'Mike MacDonald' Subject: RE: XF86SUP.SYS Hi Mike, Interesting point you have. How will you get access to the video card memory? Please answer this e-mail to vesthus@post3.tele.dk Regards Jan Rouvillain > > I don't see why this can't just be implemented as a service > and a library.. > The service would mainly be for pty, and I'm not sure that > its necessary for > that.. Windows doesn't have the Ring 0 requirement that OS/2 > has I don't > think. Plus Direct X eliminates the need for some of it.. > I'll learn more > as I go, but I don't think this needs to be, or should be a > driver on the > Windows platform. > > Honestly, I can't think of anything that couldn't just be > included in a > library.. Tell me if you've heard otherwise, and I have ALOT > more research > to do before I have a solid grasp of what needs to be done, > but I think a > straight port of XF86SUP.SYS as a .a archive will work (My > opinion here is > VERY subject to change :)) I think the only reason he has it > loading in the > config.sys is for the ring 0 requirements that are enforced by OS/2.. > From ssiddiqi@inspirepharm.com Tue Nov 9 07:48:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Tue, 09 Nov 1999 07:48:00 -0000 Subject: XF86SUP.SYS References: Message-ID: 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. > From ssiddiqi@inspirepharm.com Tue Nov 9 07:57:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Tue, 09 Nov 1999 07:57:00 -0000 Subject: XF86SUP.SYS References: Message-ID: Mike, Well, you defnitely know a lot more about drivers. My knowledge in this field is practicaly Zero that is why i had been asking for help from someone experienced in this field. This is the last sticking and perhaps a bit complicated issue. Your 15 years experience with Windows programing and drivers would definitely be a big help for cygwin-xfree ports. I had been collecting several example codes and drivers which could offer some of the features needed by XFree86. I will bundle all these drivers source codes and send them to 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:48 AM > To: 'Jan Rouvillain'; 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: XF86SUP.SYS > > > Well, its been a while, but if I remember right, DX will > set up a linear, or > pseudolinear, framebuffer for you, and return a pointer > to it. This is how > most games are written - they use DX to get a > framebuffer, and video card > access, then they use ASM to do their blts, etc, because > it is usually > quicker. > > I'm assuming I can do the same thing here for video > memory, and just use DX > to pass me back a pointer. What I'm not sure about is > accessing the ports > on the video card, and how quickly. I'm assuming that > there is a method for > quickly addressing a video port built into DX, or if you > have a full screen > mode you might have access to the video card at that > point. This is what I > don't know. I need to do some experimentation to find out. > > So basically it would be taking advantage of DX for > everything that might > require a driver to accomplish. If DX doesn't do this > stuff, things start > to get sticky.. Should be able to find solutions for it though.. > > -----Original Message----- > From: Jan Rouvillain [ mailto:jro@cotas.dk ] > Sent: Tuesday, November 09, 1999 1:54 AM > To: 'Mike MacDonald' > Subject: RE: XF86SUP.SYS > > > Hi Mike, > > > Interesting point you have. How will you get access to > the video card > memory? > > Please answer this e-mail to vesthus@post3.tele.dk > > > Regards > > Jan Rouvillain > > > > > > I don't see why this can't just be implemented as a service > > and a library.. > > The service would mainly be for pty, and I'm not sure that > > its necessary for > > that.. Windows doesn't have the Ring 0 requirement that OS/2 > > has I don't > > think. Plus Direct X eliminates the need for some of it.. > > I'll learn more > > as I go, but I don't think this needs to be, or should be a > > driver on the > > Windows platform. > > > > Honestly, I can't think of anything that couldn't just be > > included in a > > library.. Tell me if you've heard otherwise, and I have ALOT > > more research > > to do before I have a solid grasp of what needs to be done, > > but I think a > > straight port of XF86SUP.SYS as a .a archive will work (My > > opinion here is > > VERY subject to change :)) I think the only reason he has it > > loading in the > > config.sys is for the ring 0 requirements that are > enforced by OS/2.. > > > From mmacdona@tsi.gte.com Tue Nov 9 10:02:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Tue, 09 Nov 1999 10:02:00 -0000 Subject: XF86SUP.SYS Message-ID: Great! Yeah, that driver that gives you fast access to ports, I would really like to see that.. I have to admit that I'm a little new to writing windows drivers, but I've worked with alot of this stuff, and on other types of drivers - including config.sys type device drivers for years.. I really think I can help out, and I know this is very small compared to what you've already accomplished. -----Original Message----- From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] Sent: Tuesday, November 09, 1999 10:53 AM To: Mike MacDonald; 'Jan Rouvillain'; cygwin-xfree@sourceware.cygnus.com Subject: RE: XF86SUP.SYS Mike, Well, you defnitely know a lot more about drivers. My knowledge in this field is practicaly Zero that is why i had been asking for help from someone experienced in this field. This is the last sticking and perhaps a bit complicated issue. Your 15 years experience with Windows programing and drivers would definitely be a big help for cygwin-xfree ports. I had been collecting several example codes and drivers which could offer some of the features needed by XFree86. I will bundle all these drivers source codes and send them to 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:48 AM > To: 'Jan Rouvillain'; 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: XF86SUP.SYS > > > Well, its been a while, but if I remember right, DX will > set up a linear, or > pseudolinear, framebuffer for you, and return a pointer > to it. This is how > most games are written - they use DX to get a > framebuffer, and video card > access, then they use ASM to do their blts, etc, because > it is usually > quicker. > > I'm assuming I can do the same thing here for video > memory, and just use DX > to pass me back a pointer. What I'm not sure about is > accessing the ports > on the video card, and how quickly. I'm assuming that > there is a method for > quickly addressing a video port built into DX, or if you > have a full screen > mode you might have access to the video card at that > point. This is what I > don't know. I need to do some experimentation to find out. > > So basically it would be taking advantage of DX for > everything that might > require a driver to accomplish. If DX doesn't do this > stuff, things start > to get sticky.. Should be able to find solutions for it though.. > > -----Original Message----- > From: Jan Rouvillain [ mailto:jro@cotas.dk ] > Sent: Tuesday, November 09, 1999 1:54 AM > To: 'Mike MacDonald' > Subject: RE: XF86SUP.SYS > > > Hi Mike, > > > Interesting point you have. How will you get access to > the video card > memory? > > Please answer this e-mail to vesthus@post3.tele.dk > > > Regards > > Jan Rouvillain > > > > > > I don't see why this can't just be implemented as a service > > and a library.. > > The service would mainly be for pty, and I'm not sure that > > its necessary for > > that.. Windows doesn't have the Ring 0 requirement that OS/2 > > has I don't > > think. Plus Direct X eliminates the need for some of it.. > > I'll learn more > > as I go, but I don't think this needs to be, or should be a > > driver on the > > Windows platform. > > > > Honestly, I can't think of anything that couldn't just be > > included in a > > library.. Tell me if you've heard otherwise, and I have ALOT > > more research > > to do before I have a solid grasp of what needs to be done, > > but I think a > > straight port of XF86SUP.SYS as a .a archive will work (My > > opinion here is > > VERY subject to change :)) I think the only reason he has it > > loading in the > > config.sys is for the ring 0 requirements that are > enforced by OS/2.. > > > From cgf@cygnus.com Tue Nov 9 12:44:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Tue, 09 Nov 1999 12:44:00 -0000 Subject: X11 and shared libs again References: <199911092038.NAA08481@benson> Message-ID: <19991109154710.D3918@cygnus.com> On Tue, Nov 09, 1999 at 01:38:53PM -0700, Steve Jorgensen wrote: >I've been poking around the X source code for cygwin, trying to figure >out how the X libraries support the externing of Xt widget class >variables. > >I really want to figure out how to create my own shared X library DLL's >for the Khoros library, because one of the main features of our visual >programming language depends on the ability of using dlopen to load new >widget subclasses at run time. > >Anyway, I came to the realization today, that no libXt.dll or >libXmu.dll file exist in the cygwin-xfree-4_0-cygwin-v-1_tar.bz2 X11 >cygwin distribution. This wasn't true in earlier X11 releases, so is >this a problem that needs to be fixed? If this was on purpose, is it >because it's impossible to export the class variables for widgets? > >Also, while looking at the source code and imake rules in the xc-*.tar >files, I found the X code is using image-base in dllwrap to provide a >default address to load each library. Does this effect how the >externing of global variables (so you don't to use that >__declspec(__dllexport) and __declspec(__dllimport)) > >Any help is appreciated. The biggest help I can give you is to point you to the appropriate list. Try posting this message to the cygwin-xfree mailing list where people are more familiar with these types of issues. I've cc'ed the mailing list with this response. cgf From mmacdona@tsi.gte.com Tue Nov 9 15:12:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Tue, 09 Nov 1999 15:12:00 -0000 Subject: Setting up X Sources Message-ID: I'm d/ling the X sources according to your (Suhaib) instructions on your page. Is there anything I should know regarding this? From ssiddiqi@inspirepharm.com Tue Nov 9 17:08:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Tue, 09 Nov 1999 17:08:00 -0000 Subject: Setting up X Sources References: Message-ID: Use binary mount when extracting. umount / mount -b c: / for example, otherwise all the aseembeler code in xc/Xserver/programs/hw/Xfree86 and its sub-directories will fail to compile. Also make sure you have the cpp.exe in your PATH and it should be of the same version as the GCC. That is all. Type make World compile. So far no one else has compiled that source code therefore I do not know if you might face some problems. Check xc/config/cf/cygwin.cf file and if you find after #define ExtraLibraries a lot of libs to link delete them, except -lwsock32. only -lwsock32 is needed to provide some socket functionalities. If you edit any *.cf *.rules or *.c files, pleae use vim or gvim, otherwise compiler might complain about stray symbols, because of binary mount. You can grab a copy of vim or gvim from http://siddiqi.webjump.com . Do report any errors or problems with compilation so we can correct them. 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 6:12 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: Setting up X Sources > > > I'm d/ling the X sources according to your (Suhaib) instructions on your > page. Is there anything I should know regarding this? > From ssiddiqi@inspirepharm.com Tue Nov 9 17:27:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Tue, 09 Nov 1999 17:27:00 -0000 Subject: Setting up X Sources References: Message-ID: Forgot to mention: You need only xc-1, xc-2 and xc-3 archives. xggi is for XGGI server for which John Fortin is writing GGI drivers. You will also need libcrypt-cygwin-xxx.tar.bz2 and install it in H-i586-cygwin32/i586-cygwin32/lib if you are using B20.1 or snapshots otherwise in /cygwin/usr/i686-cygwin/lib if you are using Cygwin v 1.0. Libcrypt is needed only for xdm security features, otherwise you could disable it by change in xc/config/cygwin.cf #define HasLibCrypt YES to NO. 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 6:12 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: Setting up X Sources > > > I'm d/ling the X sources according to your (Suhaib) instructions on your > page. Is there anything I should know regarding this? > From mmacdona@tsi.gte.com Wed Nov 10 10:59:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 10:59:00 -0000 Subject: Compiling XFree :) Message-ID: Well, I finally got most of the bugs worked out of gcc 2.95 running on my machine, copied gcc.exe to cc.exe, and am now compiling (and have been compiling) XFree :) It seems to be going smooth so far.. From ssiddiqi@inspirepharm.com Wed Nov 10 11:30:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Wed, 10 Nov 1999 11:30:00 -0000 Subject: Compiling XFree :) References: Message-ID: nice Gcc bugs or installation issues? Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Wednesday, November 10, 1999 2:00 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: Compiling XFree :) > > > Well, I finally got most of the bugs worked out of gcc > 2.95 running on my > machine, copied gcc.exe to cc.exe, and am now compiling > (and have been > compiling) XFree :) It seems to be going smooth so far.. > From mmacdona@tsi.gte.com Wed Nov 10 11:47:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 11:47:00 -0000 Subject: Compiling XFree :) Message-ID: Installation issues :) I don't know this stuff well enough to find bugs yet :) Everything is working well.. I'm errors where some libs are not compiling, but I think its pretty normal.. -----Original Message----- From: cygwin-xfree-owner@sourceware.cygnus.com [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Suhaib Siddiqi Sent: Wednesday, November 10, 1999 2:26 PM To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com Subject: RE: Compiling XFree :) nice Gcc bugs or installation issues? Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Wednesday, November 10, 1999 2:00 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: Compiling XFree :) > > > Well, I finally got most of the bugs worked out of gcc > 2.95 running on my > machine, copied gcc.exe to cc.exe, and am now compiling > (and have been > compiling) XFree :) It seems to be going smooth so far.. > From mmacdona@tsi.gte.com Wed Nov 10 11:54:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 11:54:00 -0000 Subject: Compiling XFree :) Message-ID: Ok, so I had to start over because I didn't make that symbolic link to cpp.exe in /bin :( Still cool.. nice Gcc bugs or installation issues? Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Wednesday, November 10, 1999 2:00 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: Compiling XFree :) > > > Well, I finally got most of the bugs worked out of gcc > 2.95 running on my > machine, copied gcc.exe to cc.exe, and am now compiling > (and have been > compiling) XFree :) It seems to be going smooth so far.. > From ssiddiqi@inspirepharm.com Wed Nov 10 11:59:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Wed, 10 Nov 1999 11:59:00 -0000 Subject: Compiling XFree :) References: Message-ID: libs are not compling in X? Can you send me example of which lib? and possibly a cut-and-past of error messages. Suhaib > -----Original Message----- > From: Mike MacDonald [ mailto:mmacdona@tsi.gte.com ] > Sent: Wednesday, November 10, 1999 2:47 PM > To: 'Suhaib Siddiqi'; 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: Compiling XFree :) > > > Installation issues :) I don't know this stuff well > enough to find bugs yet > :) > > Everything is working well.. I'm errors where some libs > are not compiling, > but I think its pretty normal.. > > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Suhaib > Siddiqi > Sent: Wednesday, November 10, 1999 2:26 PM > To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com > Subject: RE: Compiling XFree :) > > > > > nice > > Gcc bugs or installation issues? > > Suhaib > > > > -----Original Message----- > > From: cygwin-xfree-owner@sourceware.cygnus.com > > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Mike > > MacDonald > > Sent: Wednesday, November 10, 1999 2:00 PM > > To: 'cygwin-xfree@sourceware.cygnus.com' > > Subject: Compiling XFree :) > > > > > > Well, I finally got most of the bugs worked out of gcc > > 2.95 running on my > > machine, copied gcc.exe to cc.exe, and am now compiling > > (and have been > > compiling) XFree :) It seems to be going smooth so far.. > > > From mmacdona@tsi.gte.com Wed Nov 10 12:34:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 12:34:00 -0000 Subject: Compiling XFree :) Message-ID: Ok, now its looking like its looking for an xc/exports/include and xc/exports/include/X11 dir. All the .h files it seems to be looking for seem to be in the xc/include directory. Should I just copy this dir over to xc/exports/include? and xc/exports/include/X11.. -----Original Message----- From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] Sent: Wednesday, November 10, 1999 2:55 PM To: Mike MacDonald Cc: Cygwin-Xfree@Sourceware.Cygnus.Com Subject: RE: Compiling XFree :) libs are not compling in X? Can you send me example of which lib? and possibly a cut-and-past of error messages. Suhaib > -----Original Message----- > From: Mike MacDonald [ mailto:mmacdona@tsi.gte.com ] > Sent: Wednesday, November 10, 1999 2:47 PM > To: 'Suhaib Siddiqi'; 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: Compiling XFree :) > > > Installation issues :) I don't know this stuff well > enough to find bugs yet > :) > > Everything is working well.. I'm errors where some libs > are not compiling, > but I think its pretty normal.. > > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Suhaib > Siddiqi > Sent: Wednesday, November 10, 1999 2:26 PM > To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com > Subject: RE: Compiling XFree :) > > > > > nice > > Gcc bugs or installation issues? > > Suhaib > > > > -----Original Message----- > > From: cygwin-xfree-owner@sourceware.cygnus.com > > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Mike > > MacDonald > > Sent: Wednesday, November 10, 1999 2:00 PM > > To: 'cygwin-xfree@sourceware.cygnus.com' > > Subject: Compiling XFree :) > > > > > > Well, I finally got most of the bugs worked out of gcc > > 2.95 running on my > > machine, copied gcc.exe to cc.exe, and am now compiling > > (and have been > > compiling) XFree :) It seems to be going smooth so far.. > > > From mmacdona@tsi.gte.com Wed Nov 10 12:42:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 12:42:00 -0000 Subject: .h files Message-ID: Ok, I copied all my headers from /usr/X11R6.4/include over to xc/exports/include, and it seems to be working now.. From mmacdona@tsi.gte.com Wed Nov 10 13:51:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 13:51:00 -0000 Subject: Compiling X Message-ID: Ok, well, makedepend had trouble findinding /include - which gcc finds fine.. I had to mount that directory in /usr/local/lib/gcc-include - I think a spot where makedepend will find it.. From mmacdona@tsi.gte.com Wed Nov 10 13:55:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 13:55:00 -0000 Subject: Compiling X Message-ID: I'm just posting progress right now for anyone else who might have similar problems.. If you see something that will be a big stopper, or something really stupid I'm doing let me know, otherwise, I'm kinda just dumping a log :) From mmacdona@tsi.gte.com Wed Nov 10 14:01:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 14:01:00 -0000 Subject: X Message-ID: depending in programs/Xserver/hw/xfree86/os-support/cygwin... .. .. .. cygwin_io.c, line 34: cannot find include file "sys/mouse.h" I'm going to assume that has to do with what I'm working on? From mmacdona@tsi.gte.com Wed Nov 10 14:15:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 14:15:00 -0000 Subject: Ok, libs are compiling now Message-ID: Ok, X libraries are compiling successfully now.. I'll let it compile overnight, and see whats there/not there tommorrow. Hopefully its good to go, and I can start playing with the os stuff... From ssiddiqi@inspirepharm.com Wed Nov 10 14:22:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Wed, 10 Nov 1999 14:22:00 -0000 Subject: Compiling XFree :) References: Message-ID: The xc/exports directory is created during compilation by config scripts and needed *.h files symlink. You may have now a corrupted compilation. run make clean first then run make World again. Suhaib > -----Original Message----- > From: Mike MacDonald [ mailto:mmacdona@tsi.gte.com ] > Sent: Wednesday, November 10, 1999 3:34 PM > To: 'Suhaib Siddiqi' > Cc: 'Cygwin-Xfree@Sourceware.Cygnus.Com' > Subject: RE: Compiling XFree :) > > > Ok, now its looking like its looking for an xc/exports/include and > xc/exports/include/X11 dir. All the .h files it seems to > be looking for > seem to be in the xc/include directory. Should I just > copy this dir over to > xc/exports/include? and xc/exports/include/X11.. > > -----Original Message----- > From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] > Sent: Wednesday, November 10, 1999 2:55 PM > To: Mike MacDonald > Cc: Cygwin-Xfree@Sourceware.Cygnus.Com > Subject: RE: Compiling XFree :) > > > > > libs are not compling in X? Can you send me example of which lib? > and possibly a cut-and-past of error messages. > > Suhaib > > > > -----Original Message----- > > From: Mike MacDonald [ mailto:mmacdona@tsi.gte.com ] > > Sent: Wednesday, November 10, 1999 2:47 PM > > To: 'Suhaib Siddiqi'; 'cygwin-xfree@sourceware.cygnus.com' > > Subject: RE: Compiling XFree :) > > > > > > Installation issues :) I don't know this stuff well > > enough to find bugs yet > > :) > > > > Everything is working well.. I'm errors where some libs > > are not compiling, > > but I think its pretty normal.. > > > > -----Original Message----- > > From: cygwin-xfree-owner@sourceware.cygnus.com > > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > > Behalf Of Suhaib > > Siddiqi > > Sent: Wednesday, November 10, 1999 2:26 PM > > To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com > > Subject: RE: Compiling XFree :) > > > > > > > > > > nice > > > > Gcc bugs or installation issues? > > > > Suhaib > > > > > > > -----Original Message----- > > > From: cygwin-xfree-owner@sourceware.cygnus.com > > > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > > Behalf Of Mike > > > MacDonald > > > Sent: Wednesday, November 10, 1999 2:00 PM > > > To: 'cygwin-xfree@sourceware.cygnus.com' > > > Subject: Compiling XFree :) > > > > > > > > > Well, I finally got most of the bugs worked out of gcc > > > 2.95 running on my > > > machine, copied gcc.exe to cc.exe, and am now compiling > > > (and have been > > > compiling) XFree :) It seems to be going smooth so far.. > > > > > > From ssiddiqi@inspirepharm.com Wed Nov 10 14:23:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Wed, 10 Nov 1999 14:23:00 -0000 Subject: .h files References: Message-ID: You should need to copy or move around any code or header file. make does itself what a particular OS needs. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Wednesday, November 10, 1999 3:42 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: .h files > > > Ok, I copied all my headers from /usr/X11R6.4/include over to > xc/exports/include, and it seems to be working now.. > From ssiddiqi@inspirepharm.com Wed Nov 10 14:29:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Wed, 10 Nov 1999 14:29:00 -0000 Subject: Compiling X References: Message-ID: makedepend should have no problems. I suggest you follow Mumit's advice on cleaning up your installation. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Wednesday, November 10, 1999 4:51 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: Compiling X > > > Ok, well, makedepend had trouble findinding /include - > which gcc finds > fine.. I had to mount that directory in > /usr/local/lib/gcc-include - I > think a spot where makedepend will find it.. > From ssiddiqi@inspirepharm.com Wed Nov 10 14:32:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Wed, 10 Nov 1999 14:32:00 -0000 Subject: X References: Message-ID: ignore the erors coming from os-suport/cygwin. that code is useless. It was added only for testing and finding out would be needed to patch. Anyhow sys/mouse.h does exists, at least on my cygwin B20.1... unless I got it from an unusual source. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Wednesday, November 10, 1999 5:02 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: X > > > depending in programs/Xserver/hw/xfree86/os-support/cygwin... > .. > .. > .. > cygwin_io.c, line 34: cannot find include file "sys/mouse.h" > > > I'm going to assume that has to do with what I'm working on? > From mmacdona@tsi.gte.com Wed Nov 10 14:52:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 14:52:00 -0000 Subject: Compiling X Message-ID: My gcc is clean.. I just have that include directory mounted in the wrong spot.. No big deal.. I mounted it somewhere that makedepend could see it, and things work great... The only things I've changed so far: ln -s cpp.exe to /bin cp gcc.exe cc.exe and mounting my include dir where makedepend can see it - because I'm to lazy to figure out where its supposed to be.. That doesn't seem to far off from what you have to do to compile it... (Of course that doesn't count all the stuff you must have had to do to get it to compile) Anyway, I followed Mumit's directions, and thats how I got it cleaned up.. Mumit rules! -----Original Message----- From: cygwin-xfree-owner@sourceware.cygnus.com [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Suhaib Siddiqi Sent: Wednesday, November 10, 1999 5:25 PM To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com Subject: RE: Compiling X makedepend should have no problems. I suggest you follow Mumit's advice on cleaning up your installation. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Wednesday, November 10, 1999 4:51 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: Compiling X > > > Ok, well, makedepend had trouble findinding /include - > which gcc finds > fine.. I had to mount that directory in > /usr/local/lib/gcc-include - I > think a spot where makedepend will find it.. > From mmacdona@tsi.gte.com Wed Nov 10 14:58:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 14:58:00 -0000 Subject: libX11.a Message-ID: Is libX11.a important? It keeps saying something about Cannot find libX11.a over and over.. I figured I could just ignore it - everything else seems to be ok... If you took that seriously, relax.. libX11.a compiled fine.. From ssiddiqi@inspirepharm.com Wed Nov 10 14:59:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Wed, 10 Nov 1999 14:59:00 -0000 Subject: Compiling X References: Message-ID: As a note, if you install Cygwin B 20.1 using full.exe and do not move around or mount dirs elsewhere, XFre86 should compile witout troubles. The include dirs and gcc-lib paths are defined in cygwin.cf. The makedepend should proceed without errors or warnings. Suhaib > -----Original Message----- > From: Mike MacDonald [ mailto:mmacdona@tsi.gte.com ] > Sent: Wednesday, November 10, 1999 5:53 PM > To: 'Suhaib Siddiqi' > Cc: 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: Compiling X > > > My gcc is clean.. I just have that include directory > mounted in the wrong > spot.. No big deal.. I mounted it somewhere that > makedepend could see it, > and things work great... > > The only things I've changed so far: > > ln -s cpp.exe to /bin > cp gcc.exe cc.exe > and mounting my include dir where makedepend can see it - > because I'm to > lazy to figure out where its supposed to be.. > > That doesn't seem to far off from what you have to do to > compile it... (Of > course that doesn't count all the stuff you must have had > to do to get it to > compile) > > Anyway, I followed Mumit's directions, and thats how I > got it cleaned up.. > Mumit rules! > > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Suhaib > Siddiqi > Sent: Wednesday, November 10, 1999 5:25 PM > To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com > Subject: RE: Compiling X > > > > > makedepend should have no problems. I suggest you follow Mumit's > advice on cleaning up your installation. > > Suhaib > > > -----Original Message----- > > From: cygwin-xfree-owner@sourceware.cygnus.com > > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Mike > > MacDonald > > Sent: Wednesday, November 10, 1999 4:51 PM > > To: 'cygwin-xfree@sourceware.cygnus.com' > > Subject: Compiling X > > > > > > Ok, well, makedepend had trouble findinding /include - > > which gcc finds > > fine.. I had to mount that directory in > > /usr/local/lib/gcc-include - I > > think a spot where makedepend will find it.. > > > From ssiddiqi@inspirepharm.com Wed Nov 10 15:03:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Wed, 10 Nov 1999 15:03:00 -0000 Subject: libX11.a References: Message-ID: Yes. libX11.a is the bread and soul of X. If it says it could not find it that mens it did not compile it. If it compiled it it should make a symlink in /xc/exports/lib Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Wednesday, November 10, 1999 5:59 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: libX11.a > > > Is libX11.a important? It keeps saying something about > Cannot find libX11.a > over and over.. I figured I could just ignore it - > everything else seems to > be ok... > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you took that seriously, relax.. libX11.a compiled fine.. > From mmacdona@tsi.gte.com Wed Nov 10 15:22:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 15:22:00 -0000 Subject: makedepend Message-ID: One of the reasons makedepend might be working differently might be that I'm running gcc 2.95.2.. I don't know. I'm not 100% sure where makedepend is getting its default include list from, and I really didn't feel up to finding out. It might be a project for another day.. I do know that the gcc installed with full.exe reads search paths differently than 2.95.2.. Thats what kicked my but, that and not knowing I could check and see what those paths were.. gcc that comes with 20.1 worked fine with my old drive mapping.. 2.95 bombed completely.. I changed it around to how it should be, and it works great.. Mainly, I had my lib dir with gcc-lib mapped as /usr/lib. gcc was looking for /bin/../lib/gcc-lib... when I moved the /usr/lib down to /lib gcc found everything fine.. Works great. Just that weird problem with makedepend - because I don't know where its getting its include path from, and /include or /usr/include are not a part of it.. Which is weird because they are default for gcc.. No biggie.. I mapped it to /usr/local/lib/gcc-include - because thats one of the places makedepend was looking - later I will fix my include mount or whatever to the right location so it works without that remount.. From mmacdona@tsi.gte.com Wed Nov 10 15:24:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 15:24:00 -0000 Subject: gcc Message-ID: Of course, their fix of not having /bin in my path and instead having the whole /d/cygnus/.../bin in my path didn't work.. gcc still looks for /bin/../lib/... From mmacdona@tsi.gte.com Wed Nov 10 15:33:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 15:33:00 -0000 Subject: X Message-ID: Ok, its compiled.. I did a quick compare with the binary distribution, and I'm pretty sure I've got all the same libs you got.. From mmacdona@tsi.gte.com Wed Nov 10 15:39:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 15:39:00 -0000 Subject: xlogo Message-ID: I'm able to run xlogo.. I'm working on compiling ncurses right now so I can try xterm.. From mmacdona@tsi.gte.com Wed Nov 10 16:04:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 10 Nov 1999 16:04:00 -0000 Subject: X Message-ID: Ok, well, there are a few little things - like xterm cant find a pty - that prolly have simple solutions, but pretty much it compiled great. I am gonna start digging into the more fun stuff tommorrow.. From ssiddiqi@inspirepharm.com Thu Nov 11 03:45:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Thu, 11 Nov 1999 03:45:00 -0000 Subject: makedepend References: Message-ID: makedepned gets include paths and other OS realted stuff from files in xc/config cygwin.cf, cygwin.rules, xfre86.cf and a few others. gcc-2.95.2 works without problems. I use pgcc-2.95.2, which is same as gcc-2.95.2. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Wednesday, November 10, 1999 6:22 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: makedepend > > > One of the reasons makedepend might be working > differently might be that I'm > running gcc 2.95.2.. I don't know. I'm not 100% sure > where makedepend is > getting its default include list from, and I really > didn't feel up to > finding out. It might be a project for another day.. > > I do know that the gcc installed with full.exe reads search paths > differently than 2.95.2.. Thats what kicked my but, that > and not knowing I > could check and see what those paths were.. gcc that > comes with 20.1 worked > fine with my old drive mapping.. 2.95 bombed > completely.. I changed it > around to how it should be, and it works great.. Mainly, > I had my lib dir > with gcc-lib mapped as /usr/lib. gcc was looking for > /bin/../lib/gcc-lib... > when I moved the /usr/lib down to /lib gcc found > everything fine.. Works > great. Just that weird problem with makedepend - > because I don't know > where its getting its include path from, and /include or > /usr/include are > not a part of it.. Which is weird because they are > default for gcc.. No > biggie.. I mapped it to /usr/local/lib/gcc-include - > because thats one of > the places makedepend was looking - later I will fix my > include mount or > whatever to the right location so it works without that remount.. > From ssiddiqi@inspirepharm.com Thu Nov 11 03:46:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Thu, 11 Nov 1999 03:46:00 -0000 Subject: X References: Message-ID: good ;) > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Wednesday, November 10, 1999 6:33 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: X > > > Ok, its compiled.. I did a quick compare with the binary > distribution, and > I'm pretty sure I've got all the same libs you got.. > From ssiddiqi@inspirepharm.com Thu Nov 11 03:47:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Thu, 11 Nov 1999 03:47:00 -0000 Subject: xlogo References: Message-ID: You can use termcap which comes with Cygwin. change -lncurses to -ltermcap in /xc/config/cygwin.cf > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Wednesday, November 10, 1999 6:40 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: xlogo > > > I'm able to run xlogo.. I'm working on compiling ncurses > right now so I can > try xterm.. > From mmacdona@tsi.gte.com Thu Nov 11 07:10:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Thu, 11 Nov 1999 07:10:00 -0000 Subject: -ltermcap Message-ID: When I try to compile with -ltermcap it gets undefined function _ctype_ From mmacdona@tsi.gte.com Thu Nov 11 07:31:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Thu, 11 Nov 1999 07:31:00 -0000 Subject: -ltermcap Message-ID: Ok, I added a -lcygwin -lg and it worked.. It still says no available ptys though.. No biggie.. It compiles well enough that I can start looking around.. From mmacdona@tsi.gte.com Thu Nov 11 07:38:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Thu, 11 Nov 1999 07:38:00 -0000 Subject: os-support Message-ID: So, all the functions to directly access hardware are in the os-support/cygwin library? The only thing that has to be done is to get all those functions working? I don't have to worry about other parts of X trying to get ports any other way, etc? From ssiddiqi@inspirepharm.com Thu Nov 11 07:47:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Thu, 11 Nov 1999 07:47:00 -0000 Subject: -ltermcap References: Message-ID: That means your libtermcap needs to be recompiled first. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Thursday, November 11, 1999 10:11 AM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: -ltermcap > > > When I try to compile with -ltermcap it gets undefined > function _ctype_ > From ssiddiqi@inspirepharm.com Thu Nov 11 07:50:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Thu, 11 Nov 1999 07:50:00 -0000 Subject: -ltermcap References: Message-ID: You do not need to link against libcygwin That is done automatically. > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Thursday, November 11, 1999 10:31 AM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: -ltermcap > > > Ok, I added a -lcygwin -lg and it worked.. It still says > no available ptys > though.. No biggie.. It compiles well enough that I can > start looking > around.. > From ssiddiqi@inspirepharm.com Thu Nov 11 07:53:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Thu, 11 Nov 1999 07:53:00 -0000 Subject: os-support References: Message-ID: Yes, that is true, somehow. XF86 needs those functions. I simply added those functions as dummy to compile and patch the XF86 code then worry about how to get them working. You might consider looking into other OS related codes too in os-support/xxx and see how they did. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Thursday, November 11, 1999 10:38 AM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: os-support > > > So, all the functions to directly access hardware are in the > os-support/cygwin library? The only thing that has to be > done is to get all > those functions working? I don't have to worry about > other parts of X > trying to get ports any other way, etc? > From mmacdona@tsi.gte.com Thu Nov 11 14:38:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Thu, 11 Nov 1999 14:38:00 -0000 Subject: FW: Returned mail: Host unknown Message-ID: There is a good chance though, still, that I'll have to use DirectX to get the memory pointer.. I don't think that it will be easy to get access to video memory any other way, even with mapmem.. getio on the other hand.. Thats cool!! :) -----Original Message----- From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] Sent: Thursday, November 11, 1999 5:25 PM To: Mike MacDonald Subject: RE: Setting up X Sources I agree with your approach. Take your time and see if you could come up with a solution. Thanks Suhaib > -----Original Message----- > From: Mike MacDonald [ mailto:mmacdona@tsi.gte.com ] > Sent: Thursday, November 11, 1999 5:25 PM > To: 'ssiddiqi@ipass.net' > Subject: RE: Setting up X Sources > > > Well, getio will definately take care of the io problem > if it works.. I > think it will.. MapMem should deal with the memory > mapping.. If it works.. > I think MapMem does IO too, but I think that getio does > it faster. Its > mostly just a matter of stitching them into the > os_support stuff now, and > debugging. Later maybe combining mapmem and getio into > one driver.. Its > the cleanest solution, and enough like what os2 is doing > that most of the > same code should apply.. I think os2 calls drivers a > little different than > windows, but thats the most of it.. > > In other words, getting really close to having something > that might work.. > From ssiddiqi@inspirepharm.com Thu Nov 11 14:42:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Thu, 11 Nov 1999 14:42:00 -0000 Subject: Setting up X References: Message-ID: Your choice. You decide what is best. However with DirectX we need to make sure we use DirectX 3.0, not a higher version otherwise NT 4.0 will be a problem. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Thursday, November 11, 1999 5:38 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: FW: Returned mail: Host unknown > > > There is a good chance though, still, that I'll have to > use DirectX to get > the memory pointer.. I don't think that it will be easy > to get access to > video memory any other way, even with mapmem.. getio on > the other hand.. > Thats cool!! :) > > -----Original Message----- > From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] > Sent: Thursday, November 11, 1999 5:25 PM > To: Mike MacDonald > Subject: RE: Setting up X Sources > > > > > I agree with your approach. Take your time and see if you could > come up > with a solution. Thanks > Suhaib > > > > -----Original Message----- > > From: Mike MacDonald [ mailto:mmacdona@tsi.gte.com ] > > Sent: Thursday, November 11, 1999 5:25 PM > > To: 'ssiddiqi@ipass.net' > > Subject: RE: Setting up X Sources > > > > > > Well, getio will definately take care of the io problem > > if it works.. I > > think it will.. MapMem should deal with the memory > > mapping.. If it works.. > > I think MapMem does IO too, but I think that getio does > > it faster. Its > > mostly just a matter of stitching them into the > > os_support stuff now, and > > debugging. Later maybe combining mapmem and getio into > > one driver.. Its > > the cleanest solution, and enough like what os2 is doing > > that most of the > > same code should apply.. I think os2 calls drivers a > > little different than > > windows, but thats the most of it.. > > > > In other words, getting really close to having something > > that might work.. > > > From mmacdona@tsi.gte.com Thu Nov 11 14:49:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Thu, 11 Nov 1999 14:49:00 -0000 Subject: Setting up X Message-ID: Oh, I'm building this on NT.. I'm mainly afraid of making this NT specific rather than the other way around. Win9x should actually be able to address the ram, and the io ports directly. I know I've done direct screen writes in Win9x. DX is a good way though to ensure compatability, and I'm pretty sure that other than the initialization time there isn't a hit for speed. I don't know how well getio will run under 98. Since a driver isn't required to do the directx stuff, the getio stuff may be an NT only thing.. -----Original Message----- From: cygwin-xfree-owner@sourceware.cygnus.com [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Suhaib Siddiqi Sent: Thursday, November 11, 1999 5:38 PM To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com Subject: Setting up X Your choice. You decide what is best. However with DirectX we need to make sure we use DirectX 3.0, not a higher version otherwise NT 4.0 will be a problem. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Thursday, November 11, 1999 5:38 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: FW: Returned mail: Host unknown > > > There is a good chance though, still, that I'll have to > use DirectX to get > the memory pointer.. I don't think that it will be easy > to get access to > video memory any other way, even with mapmem.. getio on > the other hand.. > Thats cool!! :) > > -----Original Message----- > From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] > Sent: Thursday, November 11, 1999 5:25 PM > To: Mike MacDonald > Subject: RE: Setting up X Sources > > > > > I agree with your approach. Take your time and see if you could > come up > with a solution. Thanks > Suhaib > > > > -----Original Message----- > > From: Mike MacDonald [ mailto:mmacdona@tsi.gte.com ] > > Sent: Thursday, November 11, 1999 5:25 PM > > To: 'ssiddiqi@ipass.net' > > Subject: RE: Setting up X Sources > > > > > > Well, getio will definately take care of the io problem > > if it works.. I > > think it will.. MapMem should deal with the memory > > mapping.. If it works.. > > I think MapMem does IO too, but I think that getio does > > it faster. Its > > mostly just a matter of stitching them into the > > os_support stuff now, and > > debugging. Later maybe combining mapmem and getio into > > one driver.. Its > > the cleanest solution, and enough like what os2 is doing > > that most of the > > same code should apply.. I think os2 calls drivers a > > little different than > > windows, but thats the most of it.. > > > > In other words, getting really close to having something > > that might work.. > > > From ssiddiqi@inspirepharm.com Thu Nov 11 14:54:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Thu, 11 Nov 1999 14:54:00 -0000 Subject: Setting up X References: Message-ID: > Oh, I'm building this on NT.. I'm mainly afraid of > making this NT specific > rather than the other way around. Win9x should actually > be able to address > the ram, and the io ports directly. > > I know I've done direct screen writes in Win9x. > > DX is a good way though to ensure compatability, and I'm > pretty sure that > other than the initialization time there isn't a hit for speed. > > I don't know how well getio will run under 98. > > Since a driver isn't required to do the directx stuff, > the getio stuff may > be an NT only thing.. That is possible. But getting XF86 executables work first for NT would a good start. At some point either we or any other contributr may come up with solution for Win9x. Beside XGGI drivers from John Fortin would definitely run on Win9x. XGGI supposed to be platform independent, though it is not really an XFree86 itselg. It does use XF86 drivers and libs. Suhaib > > > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Suhaib > Siddiqi > Sent: Thursday, November 11, 1999 5:38 PM > To: Mike MacDonald; cygwin-xfree@sourceware.cygnus.com > Subject: Setting up X > > > > > Your choice. You decide what is best. > However with DirectX we need to make sure we use DirectX > 3.0, not a > higher version otherwise NT 4.0 will be a problem. > > Suhaib > > > -----Original Message----- > > From: cygwin-xfree-owner@sourceware.cygnus.com > > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Mike > > MacDonald > > Sent: Thursday, November 11, 1999 5:38 PM > > To: 'cygwin-xfree@sourceware.cygnus.com' > > Subject: FW: Returned mail: Host unknown > > > > > > There is a good chance though, still, that I'll have to > > use DirectX to get > > the memory pointer.. I don't think that it will be easy > > to get access to > > video memory any other way, even with mapmem.. getio on > > the other hand.. > > Thats cool!! :) > > > > -----Original Message----- > > From: Suhaib Siddiqi [ mailto:sssiddiqi@ipass.net ] > > Sent: Thursday, November 11, 1999 5:25 PM > > To: Mike MacDonald > > Subject: RE: Setting up X Sources > > > > > > > > > > I agree with your approach. Take your time and see if you could > > come up > > with a solution. Thanks > > Suhaib > > > > > > > -----Original Message----- > > > From: Mike MacDonald [ mailto:mmacdona@tsi.gte.com ] > > > Sent: Thursday, November 11, 1999 5:25 PM > > > To: 'ssiddiqi@ipass.net' > > > Subject: RE: Setting up X Sources > > > > > > > > > Well, getio will definately take care of the io problem > > > if it works.. I > > > think it will.. MapMem should deal with the memory > > > mapping.. If it works.. > > > I think MapMem does IO too, but I think that getio does > > > it faster. Its > > > mostly just a matter of stitching them into the > > > os_support stuff now, and > > > debugging. Later maybe combining mapmem and getio into > > > one driver.. Its > > > the cleanest solution, and enough like what os2 is doing > > > that most of the > > > same code should apply.. I think os2 calls drivers a > > > little different than > > > windows, but thats the most of it.. > > > > > > In other words, getting really close to having something > > > that might work.. > > > > > > From mmacdona@tsi.gte.com Fri Nov 12 08:32:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Fri, 12 Nov 1999 08:32:00 -0000 Subject: FW: XF86SUP.SYS Message-ID: -----Original Message----- From: Mike MacDonald Sent: Friday, November 12, 1999 11:30 AM To: 'Holger Veit' Subject: XF86SUP.SYS 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. I can use directx to get a pointer to memory, but I would have to use directx to set the video mode I think. 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. Unfortunately that makes it more difficult to display X in a window which would be nice. Unless I just pick the svga server, and fix that to use DirectX.. Or go nuts and make a directx server which would prolly be the best way to go.. I don't know, I think for now I'll either pick a mode and just support 1 mode, or try and go to a fullscreen mode and map the memory.. If you can let me know how X changes video modes, it would be really helpful, thanx! From ssiddiqi@inspirepharm.com Fri Nov 12 09:26:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Fri, 12 Nov 1999 09:26:00 -0000 Subject: XF86SUP.SYS References: Message-ID: Here is a document on XF86 Video Mode. It will help you understand how it does. Please also have a look at the attached "Design" document. It explains basic principles of XF86 design. -------------------------------------------------------------------- ------ XFree86 Video Timings HOWTO Eric S. Raymond Version 3.0, 8 Aug 1997 Abstract How to compose a mode line for your card/monitor combination under XFree86. The XFree86 distribution now includes good facilities for configuring most standard combinations; this document is mainly useful if you are tuning a custom mode line for a high-performance monitor or very unusual hardware. It may also help you in using xvidtune to tweak a standard mode that is not quite right for your monitor. 1. Disclaimer You use the material herein SOLELY AT YOUR OWN RISK. It is possible to harm both your monitor and yourself when driving it outside the manufacturer's specs. Read Overdriving Your Monitor (section 11., page 1) for detailed cau- tions. Any damages to you or your monitor caused by overdriving it are your problem. The most up-to-date version of this HOWTO can be found at the Linux Documen- tation Project web page. Please direct comments, criticism, and suggestions for improvement to esr@snark.thyrsus.com. Please do not send email pleading for a magic solution to your special monitor problem, as doing so will only burn up my time and frustrate you -- everything I know about the subject is already in here. 2. Introduction The XFree86 server allows users to configure their video subsystem and thus encourages best use of existing hardware. This tutorial is intended to help you learn how to generate your own timing numbers to make optimum use of your video card and monitor. We'll present a method for getting something that works, and then show you how you can experiment starting from that base to develop settings that opti- mize for your taste. Starting with XFree86 3.2, XFree86 provides an XF86Setup(1) program that makes it easy to generate a working monitor mode interactively, without mess- ing with video timing number directly. So you shouldn't actually need to calculate a base monitor mode in most cases. Unfortunately, XF86Setup(1) has some limitations; it only knows about standard video modes up to 1280x1024. If you have a very high-performance monitor capable of 1600x1200 or more you will still have to compute your base monitor mode yourself. Recent versions of XFree86 provide a tool called xvidtune(1) which you will probably find quite useful for testing and tuning monitor modes. It begins with a gruesome warning about the possible consequences of mistakes with it. If you pay careful attention to this document and learn what is behind the pretty numbers in xvidtune's boxes, you will become able to use xvidtune effectively and with confidence. If you already have a mode that almost works (in particular, if one of prede- fined VESA modes gives you a stable display but one that's displaced right or left, or too small, or too large) you can go straight to the section on Fix- ing Problems with the Image (section 14., page 1). This will enlighten you on ways to tweak the timing numbers to achieve particular effects. If you have xvidtune(1), you'll be able to test new modes on the fly, without modifying your X configuration files or even rebooting your X server. Other- wise, XFree86 allows you to hot-key between different modes defined in Xcon- fig (see XFree86.man for details). Use this capabilty to save yourself has- sles! When you want to test a new mode, give it a unique mode label and add it to the end of your hot-key list. Leave a known-good mode as the default to fall back on if the test mode doesn't work. 3. How Video Displays Work Knowing how the display works is essential to understanding what numbers to put in the various fields in the file Xconfig. Those values are used in the lowest levels of controlling the display by the XFree86 server. The display generates a picture from a series of dots. The dots are arranged from left to right to form lines. The lines are arranged from top to bottom to form the picture. The dots emit light when they are struck by the elec- tron beam inside the display. To make the beam strike each dot for an equal amount of time, the beam is swept across the display in a constant pattern. The pattern starts at the top left of the screen, goes across the screen to the right in a straight line, and stops temporarily on the right side of the screen. Then the beam is swept back to the left side of the display, but down one line. The new line is swept from left to right just as the first line was. This pattern is repeated until the bottom line on the display has been swept. Then the beam is moved from the bottom right corner of the dis- play to the top left corner, and the pattern is started over again. There is one variation of this scheme known as interlacing: here only every second line is swept during one half-frame and the others are filled in in during a second half-frame. Starting the beam at the top left of the display is called the beginning of a frame. The frame ends when the beam reaches the the top left corner again as it comes from the bottom right corner of the display. A frame is made up of all of the lines the beam traced from the top of the display to the bottom. If the electron beam were on all of the time it was sweeping through the frame, all of the dots on the display would be illuminated. There would be no black border around the edges of the display. At the edges of the display the picture would become distorted because the beam is hard to control there. To reduce the distortion, the dots around the edges of the display are not illuminated by the beam even though the beam may be pointing at them. The viewable area of the display is reduced this way. Another important thing to understand is what becomes of the beam when no spot is being painted on the visible area. The time the beam would have been illuminating the side borders of the display is used for sweeping the beam back from the right edge to the left and moving the beam down to the next line. The time the beam would have been illuminating the top and bottom bor- ders of the display is used for moving the beam from the bottom-right corner of the display to the top-left corner. The adapter card generates the signals which cause the display to turn on the electron beam at each dot to generate a picture. The card also controls when the display moves the beam from the right side to the left and down a line by generating a signal called the horizontal sync (for synchronization) pulse. One horizontal sync pulse occurs at the end of every line. The adapter also generates a vertical sync pulse which signals the display to move the beam to the top-left corner of the display. A vertical sync pulse is generated near the end of every frame. The display requires that there be short time periods both before and after the horizontal and vertical sync pulses so that the position of the electron beam can stabilize. If the beam can't stabilize, the picture will not be steady. In a later section, we'll come back to these basics with definitions, formu- las and examples to help you use them. 4. Basic Things to Know about your Display and Adapter There are some fundamental things you need to know before hacking an Xconfig entry. These are: o your monitor's horizontal and vertical sync frequency options o your video adapter's driving clock frequency, or "dot clock" o your monitor's bandwidth The monitor sync frequencies: The horizontal sync frequency is just the number of times per second the mon- itor can write a horizontal scan line; it is the single most important statistic about your monitor. The vertical sync frequency is the number of times per second the monitor can traverse its beam vertically. Sync frequencies are usually listed on the specifications page of your moni- tor manual. The vertical sync frequency number is typically calibrated in Hz (cycles per second), the horizontal one in KHz (kilocycles per second). The usual ranges are between 50 and 150Hz vertical, and between 31 and 135KHz horizontal. If you have a multisync monitor, these frequencies will be given as ranges. Some monitors, especially lower-end ones, have multiple fixed frequencies. These can be configured too, but your options will be severely limited by the built-in monitor characteristics. Choose the highest frequency pair for best resolution. And be careful --- trying to clock a fixed-frequency monitor at a higher speed than it's designed for can easily damage it. Earlier versions of this guide were pretty cavalier about overdriving multi- sync monitors, pushing them past their nominal highest vertical sync fre- quency in order to get better performance. We have since had more reasons pointed out to us for caution on this score; we'll cover those under Over- driving Your Monitor (section 11., page 1) below. The card driving clock frequency: Your video adapter manual's spec page will usually give you the card's dot clock (that is, the total number of pixels per second it can write to the screen). If you don't have this information, the X server will get it for you. Even if your X locks up your monitor, it will emit a line of clock and other info to standard output. If you redirect this to a file, it should be saved even if you have to reboot to get your console back. (Recent versions of the X servers allsupport a --probeonly option that prints out this infor- mation and exits without actually starting up X or changing the video mode.) Your X startup message should look something like one of the following exam- ples: If you're using XFree86: Xconfig: /usr/X11R6/lib/X11/Xconfig (**) stands for supplied, (--) stands for probed/default values (**) Mouse: type: MouseMan, device: /dev/ttyS1, baudrate: 9600 Warning: The directory "/usr/andrew/X11fonts" does not exist. Entry deleted from font path. (**) FontPath set to "/usr/lib/X11/fonts/misc/,/usr/lib/X11/fonts/75dpi/" (--) S3: card type: 386/486 localbus (--) S3: chipset: 924 --- Chipset -- this is the exact chip type; an early mask of the 86C911 (--) S3: chipset driver: s3_generic (--) S3: videoram: 1024k ----- Size of on-board frame-buffer RAM (**) S3: clocks: 25.00 28.00 40.00 3.00 50.00 77.00 36.00 45.00 (**) S3: clocks: 0.00 0.00 79.00 31.00 94.00 65.00 75.00 71.00 --------------------------------------------- --------- Possible driving frequencies in MHz (--) S3: Maximum allowed dot-clock: 110MHz ------ Bandwidth (**) S3: Mode "1024x768": mode clock = 79.000, clock used = 79.000 (--) S3: Virtual resolution set to 1024x768 (--) S3: Using a banksize of 64k, line width of 1024 (--) S3: Pixmap cache: (--) S3: Using 2 128-pixel 4 64-pixel and 8 32-pixel slots (--) S3: Using 8 pages of 768x255 for font caching If you're using SGCS or X/Inside X: WGA: 86C911 (mem: 1024k clocks: 25 28 40 3 50 77 36 45 0 0 79 31 94 65 75 71) --- ------ ----- ------------------------------- ------------- | | | Possible driving frequencies in MHz | | +-- Size of on-board frame-buffer RAM | +-- Chip type +-- Server type Note: do this with your machine unloaded (if at all possible). Because X is an application, its timing loops can collide with disk activity, rendering the numbers above inaccurate. Do it several times and watch for the numbers to stabilize; if they don't, start killing processes until they do. SVr4 users: the mousemgr process is particularly likely to mess you up. In order to avoid the clock-probe inaccuracy, you should clip out the clock timings and put them in your Xconfig as the value of the Clocks property --- this suppresses the timing loop and gives X an exact list of the clock values it can try. Using the data from the example above: wga Clocks 25 28 40 3 50 77 36 45 0 0 79 31 94 65 75 71 On systems with a highly variable load, this may help you avoid mysterious X startup failures. It's possible for X to come up, get its timings wrong due to system load, and then not be able to find a matching dot clock in its con- fig database --- or find the wrong one! 4.1 The monitor's video bandwidth: If you're running XFree86, your server will probe your card and tell you what your highest-available dot clock is. Otherwise, your highest available dot clock is approximately the monitor's video bandwidth. There's a lot of give here, though --- some monitors can run as much as 30% over their nominal bandwidth. The risks here have to do with exceeding the monitor's rated vertical-sync frequency; we'll discuss them in detail below. Knowing the bandwidth will enable you to make more intelligent choices between possible configurations. It may affect your display's visual quality (especially sharpness for fine details). Your monitor's video bandwidth should be included on the manual's spec page. If it's not, look at the monitor's higest rated resolution. As a rule of thumb, here's how to translate these into bandwidth estimates (and thus into rough upper bounds for the dot clock you can use): 640x480 25 800x600 36 1024x768 65 1024x768 interlaced 45 1280x1024 110 1600x1200 185 BTW, there's nothing magic about this table; these numbers are just the low- est dot clocks per resolution in the standard XFree86 Modes database (except for the last, which I interpolated). The bandwidth of your monitor may actu- ally be higher than the minimum needed for its top resolution, so don't be afraid to try a dot clock a few MHz higher. Also note that bandwidth is seldom an issue for dot clocks under 65MHz or so. With an SVGA card and most hi-res monitors, you can't get anywhere near the limit of your monitor's video bandwidth. The following are examples: Brand Video Bandwidth ---------- --------------- NEC 4D 75Mhz Nano 907a 50Mhz Nano 9080i 60Mhz Mitsubishi HL6615 110Mhz Mitsubishi Diamond Scan 100Mhz IDEK MF-5117 65Mhz IOCOMM Thinksync-17 CM-7126 136Mhz HP D1188A 100Mhz Philips SC-17AS 110Mhz Swan SW617 85Mhz Viewsonic 21PS 185Mhz Even low-end monitors usually aren't terribly bandwidth-constrained for their rated resolutions. The NEC Multisync II makes a good example --- it can't even display 800x600 per its spec. It can only display 800x560. For such low resolutions you don't need high dot clocks or a lot of bandwidth; proba- bly the best you can do is 32Mhz or 36Mhz, both of them are still not too far from the monitor's rated video bandwidth of 30Mhz. At these two driving frequencies, your screen image may not be as sharp as it should be, but definitely of tolerable quality. Of course it would be nicer if NEC Multisync II had a video bandwidth higher than, say, 36Mhz. But this is not critical for common tasks like text editing, as long as the difference is not so significant as to cause severe image distortion (your eyes would tell you right away if this were so). 4.2 What these control: The sync frequency ranges of your monitor, together with your video adapter's dot clock, determine the ultimate resolution that you can use. But it's up to the driver to tap the potential of your hardware. A superior hardware combination without an equally competent device driver is a waste of money. On the other hand, with a versatile device driver but less capable hardware, you can push the hardware's envelope a little. This is the design philosophy of XFree86. 5. Interpreting the Basic Specifications This section explains what the specifications above mean, and some other things you'll need to know. First, some definitions. Next to each in parens is the variable name we'll use for it when doing calculations horizontal sync frequency (HSF) Horizontal scans per second (see above). vertical sync frequency (VSF) Vertical scans per second (see above). Mainly important as the upper limit on your refresh rate. dot clock (DCF) More formally, `driving clock frequency'; The frequency of the crystal or VCO on your adaptor --- the maximum dots-per-second it can emit. video bandwidth (VB) The highest frequency you can feed into your monitor's video input and still expect to see anything discernible. If your adap- tor produces an alternating on/off pattern, its lowest frequency is half the DCF, so in theory bandwidth starts making sense at DCF/2. For tolerately crisp display of fine details in the video image, however, you don't want it much below your highest DCF, and preferably higher. frame length (HFL, VFL) Horizontal frame length (HFL) is the number of dot-clock ticks needed for your monitor's electron gun to scan one horizontal line, including the inactive left and right borders. Vertical frame length (VFL) is the number of scan lines in the entire image, including the inactive top and bottom borders. screen refresh rate (RR) The number of times per second your screen is repainted (this is also called "frame rate"). Higher frequencies are better, as they reduce flicker. 60Hz is good, VESA-standard 72Hz is better. Compute it as RR = DCF / (HFL * VFL) Note that the product in the denominator is not the same as the monitor's visible resolution, but typically somewhat larger. We'll get to the details of this below. The rates for which interlaced modes are usually specified (like 87Hz interlaced) are actually the half-frame rates: an entire screen seems to have about that flicker frequency for typical displays, but every single line is refreshed only half as often. For calculation purposes we reckon an interlaced display at its full-frame (refresh) rate, i.e. 43.5Hz. The quality of an inter- laced mode is better than that of a non-interlaced mode with the same full-frame rate, but definitely worse then the non-inter- laced one corresponding to the half-frame rate. 5.1 About Bandwidth: Monitor makers like to advertise high bandwidth because it constrains the sharpness of intensity and color changes on the screen. A high bandwidth means smaller visible details. Your monitor uses electronic signals to present an image to your eyes. Such signals always come in in wave form once they are converted into analog form from digitized form. They can be considered as combinations of many simpler wave forms each one of which has a fixed frequency, many of them are in the Mhz range, eg, 20Mhz, 40Mhz, or even 70Mhz. Your monitor video bandwidth is, effectively, the highest-frequency analog signal it can handle without dis- tortion. For our purposes, bandwidth is mainly important as an approximate cutoff point for the highest dot clock you can use. 5.2 Sync Frequencies and the Refresh Rate: Each horizontal scan line on the display is just the visible portion of a frame-length scan. At any instant there is actually only one dot active on the screen, but with a fast enough refresh rate your eye's persistence of vision enables you to "see" the whole image. Here are some pictures to help: _______________________ | | The horizontal sync frequency |->->->->->->->->->->-> | is the number of times per | )| second that the monitor's |<-----<-----<-----<--- | electron beam can trace | | a pattern like this | | | | | | |_______________________| _______________________ | ^ | The vertical sync frequency | ^ | | is the number of times per | | v | second that the monitor's | ^ | | electron beam can trace | | | | a pattern like this | ^ | | | | v | | ^ | | |_______|_v_____________| Remember that the actual raster scan is a very tight zigzag pattern; that is, the beam moves left-right and at the same time up-down. Now we can see how the dot clock and frame size relates to refresh rate. By definition, one hertz (hz) is one cycle per second. So, if your horizontal frame length is HFL and your vertical frame length is VFL, then to cover the entire screen takes (HFL * VFL) ticks. Since your card emits DCF ticks per second by definition, then obviously your monitor's electron gun(s) can sweep the screen from left to right and back and from bottom to top and back DCF / (HFL * VFL) times/sec. This is your screen's refresh rate, because it's how many times your screen can be updated (thus refreshed) per second! You need to understand this concept to design a configuration which trades off resolution against flicker in whatever way suits your needs. For those of you who handle visuals better than text, here is one: RR VB | min HSF max HSF | | | R1 R2 | | max VSF -+----|------------/----------/---|------+----- max VSF | |:::::::::::/::::::::::/:::::\ | | \::::::::::/::::::::::/:::::::\ | | |::::::::/::::::::::/:::::::::| | | |:::::::/::::::::::/::::::::::\ | | \::::::/::::::::::/::::::::::::\ | | \::::/::::::::::/::::::::::::::| | | |::/::::::::::/:::::::::::::::| | | \/::::::::::/:::::::::::::::::\| | /\:::::::::/:::::::::::::::::::| | / \:::::::/::::::::::::::::::::|\ | / |:::::/:::::::::::::::::::::| | | / \::::/::::::::::::::::::::::| \ min VSF -+----/-------\--/-----------------------|--\--- min VSF | / \/ | \ +--/----------/\------------------------+----\- DCF R1 R2 \ | \ min HSF | max HSF VB This is a generic monitor mode diagram. The x axis of the diagram shows the clock rate (DCF), the y axis represents the refresh rate (RR). The filled region of the diagram describes the monitor's capabilities: every point within this region is a possible video mode. The lines labeled `R1' and `R2' represent a fixed resolutions (such as 640x480); they are meant to illustrate how one resolution can be realized by many different combinations of dot clock and refresh rate. The R2 line would represent a higher resolution than R1. The top and bottom boundaries of the permitted region are simply horizontal lines representing the limiting values for the vertical sync frequency. The video bandwidth is an upper limit to the clock rate and hence is represented by a vertical line bounding the capability region on the right. Under Plotting Monitor Capabilities (section 15., page 1)) you'll find a pro- gram that will help you plot a diagram like this (but much nicer, with X graphics) for your individual monitor. That section also discusses the interesting part; the derivation of the boundaries resulting from the limits on the horizontal sync frequency. 6. Tradeoffs in Configuring your System Another way to look at the formula we derived above is DCF = RR * HFL * VFL That is, your dot clock is fixed. You can use those dots per second to buy either refresh rate, horizontal resolution, or vertical resolution. If one of those increases, one or both of the others must decrease. Note, though, that your refresh rate cannot be greater than the maximum ver- tical sync frequency of your monitor. Thus, for any given monitor at a given dot clock, there is a minimum product of frame lengths below which you can't force it. In choosing your settings, remember: if you set RR too low, you will get mugged by screen flicker. You probably do not want to pull your refresh rate below 60Hz. This is the flicker rate of fluorescent lights; if you're sensitive to those, you need to hang with 72Hz, the VESA ergonomic standard. Flicker is very eye-fatiguing, though human eyes are adaptable and peoples' tolerance for it varies widely. If you face your monitor at a 90% viewing angle, are using a dark background and a good contrasting color for fore- ground, and stick with low to medium intensity, you *may* be comfortable at as little as 45Hz. The acid test is this: open a xterm with pure white back-ground and black foreground using xterm -bg white -fg black and make it so large as to cover the entire viewable area. Now turn your monitor's intensity to 3/4 of its maximum setting, and turn your face away from the monitor. Try peeking at your monitor sideways (bringing the more sensitive peripheral-vision cells into play). If you don't sense any flicker or if you feel the flickering is tolerable, then that refresh rate is fine with you. Otherwise you better configure a higher refresh rate, because that semi-invisible flicker is going to fatigue your eyes like crazy and give you headaches, even if the screen looks OK to normal vision. For interlaced modes, the amount of flicker depends on more factors such as the current vertical resolution and the actual screen contents. So just experiment. You won't want to go much below about 85Hz half frame rate, though. So let's say you've picked a minimum acceptable refresh rate. In choosing your HFL and VFL, you'll have some room for maneuver. 7. Memory Requirements Available frame-buffer RAM may limit the resolution you can achieve on color or gray-scale displays. It probably isn't a factor on displays that have only two colors, white and black with no shades of gray in between. For 256-color displays, a byte of video memory is required for each visible dot to be shown. This byte contains the information that determines what mix of red, green, and blue is generated for its dot. To get the amount of mem- ory required, multiply the number of visible dots per line by the number of visible lines. For a display with a resolution of 800x600, this would be 800 x 600 = 480,000, which is the number of visible dots on the display. This is also, at one byte per dot, the number of bytes of video memory that are nec- essary on your adapter card. Thus, your memory requirement will typically be (HR * VR)/1024 Kbytes of VRAM, rounded up. If you have more memory than strictly required, you'll have extra for virtual-screen panning. However, if you only have 512K on board, then you can't use this resolution. Even if you have a good monitor, without enough video RAM, you can't take advantage of your monitor's potential. On the other hand, if your SVGA has one meg, but your monitor can display at most 800x600, then high resolution is beyond your reach anyway (see Using Interlaced Modes (section 12., page 1) for a possible remedy). Don't worry if you have more memory than required; XFree86 will make use of it by allowing you to scroll your viewable area (see the Xconfig file docu- mentation on the virtual screen size parameter). Remember also that a card with 512K bytes of memory really doesn't have 512,000 bytes installed, it has 512 x 1024 = 524,288 bytes. If you're running SGCS X (now called X/Inside) using an S3 card, and are willing to live with 16 colors (4 bits per pixel), you can set depth 4 in Xconfig and effectively double the resolution your card can handle. S3 cards, for example, normally do 1024x768x256. You can make them do 1280x1024x16 with depth 4. 8. Computing Frame Sizes Warning: this method was developed for multisync monitors. It will probably work with fixed-frequency monitors as well, but no guarantees! Start by dividing DCF by your highest available HSF to get a horizontal frame length. For example; suppose you have a Sigma Legend SVGA with a 65MHz dot clock, and your monitor has a 55KHz horizontal scan frequency. The quantity (DCF / HSF) is then 1181 (65MHz = 65000KHz; 65000/55 = 1181). Now for our first bit of black magic. You need to round this figure to the nearest multiple of 8. This has to do with the VGA hardware controller used by SVGA and S3 cards; it uses an 8-bit register, left-shifted 3 bits, for what's really an 11-bit quantity. Other card types such as ATI 8514/A may not have this requirement, but we don't know and the correction can't hurt. So round the usable horizontal frame length figure down to 1176. This figure (DCF / HSF rounded to a multiple of 8) is the minimum HFL you can use. You can get longer HFLs (and thus, possibly, more horizontal dots on the screen) by setting the sync pulse to produce a lower HSF. But you'll pay with a slower and more visible flicker rate. As a rule of thumb, 80% of the horizontal frame length is available for hori- zontal resolution, the visible part of the horizontal scan line (this allows, roughly, for borders and sweepback time -- that is, the time required for the beam to move from the right screen edge to the left edge of the next raster line). In this example, that's 944 ticks. Now, to get the normal 4:3 screen aspect ratio, set your vertical resolution to 3/4ths of the horizontal resolution you just calculated. For this exam- ple, that's 708 ticks. To get your actual VFL, multiply that by 1.05 to get 743 ticks. The 4:3 is not technically magic; nothing prevents you from using a non- Golden-Section ratio if that will get the best use out of your screen real estate. It does make figuring frame height and frame width from the diagonal size convenient, you just multiply the diagonal by by 0.8 to get width and 0.6 to get height. So, HFL=1176 and VFL=743. Dividing 65MHz by the product of the two gives us a nice, healthy 74.4Hz refresh rate. Excellent! Better than VESA standard! And you got 944x708 to boot, more than the 800 by 600 you were probably expecting. Not bad at all! You can even improve the refresh rate further, to almost 76 Hz, by using the fact that monitors can often sync horizontally at 2khz or so higher than rated, and by lowering VFL somewhat (that is, taking less than 75% of 944 in the example above). But before you try this "overdriving" maneuver, if you do, make sure that your monitor electron guns can sync up to 76 Hz vertical. (the popular NEC 4D, for instance, cannot. It goes only up to 75 Hz VSF). (See Overdriving Your Monitor (section 11., page 1) for more general discus- sion of this issue. ) So far, most of this is simple arithmetic and basic facts about raster dis- plays. Hardly any black magic at all! 9. Black Magic and Sync Pulses OK, now you've computed HFL/VFL numbers for your chosen dot clock, found the refresh rate acceptable, and checked that you have enough VRAM. Now for the real black magic -- you need to know when and where to place synchronization pulses. The sync pulses actually control the horizontal and vertical scan frequebcies of the monitor. The HSF and VSF you've pulled off the spec sheet are nomi- nal, approximate maximum sync frequencies. The sync pulse in the signal from the adapter card tells the monitor how fast to actually run. Recall the two pictures above? Only part of the time required for raster- scanning a frame is used for displaying viewable image (ie. your resolution). 9.1 Horizontal Sync: By previous definition, it takes HFL ticks to trace the a horizontal scan line. Let's call the visible tick count (your horizontal screen resolution) HR. Then Obviously, HR < HFL by definition. For concreteness, let's assume both start at the same instant as shown below: |___ __ __ __ __ __ __ __ __ __ __ __ __ |_ _ _ _ _ _ _ _ _ _ _ _ | |_______________________|_______________|_____ 0 ^ ^ unit: ticks | ^ ^ | HR | | HFL | |<----->| | |<->| HSP |<->| HGT1 HGT2 Now, we would like to place a sync pulse of length HSP as shown above, ie, between the end of clock ticks for display data and the end of clock ticks for the entire frame. Why so? because if we can achieve this, then your screen image won't shift to the right or to the left. It will be where it supposed to be on the screen, covering squarely the monitor's viewable area. Furthermore, we want about 30 ticks of "guard time" on either side of the sync pulse. This is represented by HGT1 and HGT2. In a typical configura- tion HGT1 != HGT2, but if you're building a configuration from scratch, you want to start your experimentation with them equal (that is, with the sync pulse centered). The symptom of a misplaced sync pulse is that the image is displaced on the screen, with one border excessively wide and the other side of the image wrapped around the screen edge, producing a white edge line and a band of "ghost image" on that side. A way-out-of-place vertical sync pulse can actu- ally cause the image to roll like a TV with a mis-adjusted vertical hold (in fact, it's the same phenomenon at work). If you're lucky, your monitor's sync pulse widths will be documented on its specification page. If not, here's where the real black magic starts... You'll have to do a little trial and error for this part. But most of the time, we can safely assume that a sync pulse is about 3.5 to 4.0 microsecond in length. For concretness again, let's take HSP to be 3.8 microseconds (which btw, is not a bad value to start with when experimenting). Now, using the 65Mhz clock timing above, we know HSP is equivalent to 247 clock ticks (= 65 * 10**6 * 3.8 * 10^-6) [recall M=10^6, micro=10^-6] Some makers like to quote their horizontal framing parameters as timings rather than dot widths. You may see the following terms: active time (HAT) Corresponds to HR, but in milliseconds. HAT * DCF = HR. blanking time (HBT) Corresponds to (HFL - HR), but in milliseconds. HBT * DCF = (HFL - HR). front porch (HFP) This is just HGT1. sync time This is just HSP. back porch (HBP) This is just HGT2. 9.2 Vertical Sync: Going back to the picture above, how do we place the 247 clock ticks as shown in the picture? Using our example, HR is 944 and HFL is 1176. The difference between the two is 1176 - 944=232 < 247! Obviously we have to do some adjustment here. What can we do? The first thing is to raise 1176 to 1184, and lower 944 to 936. Now the dif- ference = 1184-936= 248. Hmm, closer. Next, instead using 3.8, we use 3.5 for calculating HSP; then, we have 65*3.5=227. Looks better. But 248 is not much higher than 227. It's nor- mally necessary to have 30 or so clock ticks between HR and the start of SP, and the same for the end of SP and HFL. AND they have to be multiple of eight! Are we stuck? No. Let's do this, 936 % 8 = 0, (936 + 32) % 8 = 0 too. But 936 + 32 = 968, 968 + 227 = 1195, 1195 + 32 = 1227. Hmm.. this looks not too bad. But it's not a multiple of 8, so let's round it up to 1232. But now we have potential trouble, the sync pulse is no longer placed right in the middle between h and H any more. Happily, using our calculator we find 1232 - 32 = 1200 is also a multiple of 8 and (1232 - 32) - 968 = 232 corresponding using a sync pulse of 3.57 micro second long, still reasonable. In addition, 936/1232 ~ 0.76 or 76%, still not far from 80%, so it should be all right. Furthermore, using the current horizontal frame length, we basically ask our monitor to sync at 52.7khz (= 65Mhz/1232) which is within its capability. No problems. Using rules of thumb we mentioned before, 936*75%=702, This is our new verti- cal resolution. 702 * 1.05 = 737, our new vertical frame length. Screen refresh rate = 65Mhz/(737*1232)=71.6 Hz. This is still excellent. Figuring the vertical sync pulse layout is similar: |___ __ __ __ __ __ __ __ __ __ __ __ __ |_ _ _ _ _ _ _ _ _ _ _ _ | |_______________________|_______________|_____ 0 VR VFL unit: ticks ^ ^ ^ | | | |<->|<----->| VGT VSP We start the sync pulse just past the end of the vertical display data ticks. VGT is the vertical guard time required for the sync pulse. Most monitors are comfortable with a VGT of 0 (no guard time) and we'll use that in this example. A few need two or three ticks of guard time, and it usually doesn't hurt to add that. Returning to the example: since by the defintion of frame length, a vertical tick is the time for tracing a complete HORIZONTAL frame, therefore in our example, it is 1232/65Mhz=18.95us. Experience shows that a vertical sync pulse should be in the range of 50us and 300us. As an example let's use 150us, which translates into 8 vertical clock ticks (150us/18.95us~8). Some makers like to quote their vertical framing parameters as timings rather than dot widths. You may see the following terms: active time (VAT) Corresponds to VR, but in milliseconds. VAT * VSF = VR. blanking time (VBT) Corresponds to (VFL - VR), but in milliseconds. VBT * VSF = (VFL - VR). front porch (VFP) This is just VGT. sync time This is just VSP. back porch (VBP) This is like a second guard time after the vertical sync pulse. It is often zero. 10. Putting it All Together The Xconfig file Table of Video Modes contains lines of numbers, with each line being a complete specification for one mode of X-server operation. The fields are grouped into four sections, the name section, the clock frequency section, the horizontal section, and the vertical section. The name section contains one field, the name of the video mode specified by the rest of the line. This name is referred to on the "Modes" line of the Graphics Driver Setup section of the Xconfig file. The name field may be omitted if the name of a previous line is the same as the current line. The dot clock section contains only the dot clock (what we've called DCF) field of the video mode line. The number in this field specifies what dot clock was used to generate the numbers in the following sections. The horizontal section consists of four fields which specify how each hori- zontal line on the display is to be generated. The first field of the sec- tion contains the number of dots per line which will be illuminated to form the picture (what we've called HR). The second field of the section indi- cates at which dot the horizontal sync pulse will begin. The third field indicates at which dot the horizontal sync pulse will end. The fourth field specifies the toal horzontal frame length (HFL). The vertical section also contains four fields. The first field contains the number of visible lines which will appear on the display (VR). The second field indicates the line number at which the vertical sync pulse will begin. The third field specifies the line number at which the vertical sync pulse will end. The fourth field contains the total vertical frame length (VFL). Example: #Modename clock horizontal timing vertical timing "752x564" 40 752 784 944 1088 564 567 569 611 44.5 752 792 976 1240 564 567 570 600 (Note: stock X11R5 doesn't support fractional dot clocks.) For Xconfig, all of the numbers just mentioned - the number of illuminated dots on the line, the number of dots separating the illuminated dots from the beginning of the sync pulse, the number of dots representing the duration of the pulse, and the number of dots after the end of the sync pulse - are added to produce the number of dots per line. The number of horizontal dots must be evenly divisible by eight. Example horizontal numbers: 800 864 1024 1088 This sample line has the number of illuminated dots (800) followed by the number of the dot when the sync pulse starts (864), followed by the number of the dot when the sync pulse ends (1024), followed by the number of the last dot on the horizontal line (1088). Note again that all of the horizontal numbers (800, 864, 1024, and 1088) are divisible by eight! This is not required of the vertical numbers. The number of lines from the top of the display to the bottom form the frame. The basic timing signal for a frame is the line. A number of lines will con- tain the picture. After the last illuminated line has been displayed, a delay of a number of lines will occur before the vertical sync pulse is gen- erated. Then the sync pulse will last for a few lines, and finally the last lines in the frame, the delay required after the pulse, will be generated. The numbers that specify this mode of operation are entered in a manner simi- lar to the following example. Example vertical numbers: 600 603 609 630 This example indicates that there are 600 visible lines on the display, that the vertical sync pulse starts with the 603rd line and ends with the 609th, and that there are 630 total lines being used. Note that the vertical numbers don't have to be divisible by eight! Let's return to the example we've been working. According to the above, all we need to do from now on is to write our result into Xconfig as follows: DCF HR SH1 SH2 HFL VR SV1 SV2 VFL where SH1 is the start tick of the horizontal sync pulse and SH2 is its end tick; similarly, SV1 is the start tick of the vertical sync pulse and SV2 is its end tick. #name clock horizontal timing vertical timing flag 936x702 65 936 968 1200 1232 702 702 710 737 No special flag necessary; this is a non-interlaced mode. Now we are really done. 11. Overdriving Your Monitor You should absolutely not try exceeding your monitor's scan rates if it's a fixed-frequency type. You can smoke your hardware doing this! There are potentially subtler problems with overdriving a multisync monitor which you should be aware of. Having a pixel clock higher than the monitor's maximum bandwidth is rather harmless, in contrast. (Note: the theoretical limit of discernable features is reached when the pixel clock reaches double the monitor's bandwidth. This is a straightforward application of Nyquist's Theorem: consider the pixels as a spatially distributed series of samples of the drive signals and you'll see why.) It's exceeding the rated maximum sync frequencies that's problematic. Some modern monitors might have protection circuitry that shuts the monitor down at dangerous scan rates, but don't rely on it. In particular there are older multisync monitors (like the Multisync II) which use just one horizontal transformer. These monitors will not have much protection against overdriving them. While you necessarily have high voltage regulation circuitry (which can be absent in fixed frequency monitors), it will not necessarily cover every conceivable frequency range, especially in cheaper models. This not only implies more wear on the circuitry, it can also cause the screen phos- phors to age faster, and cause more than the specified radiation (including X-rays) to be emitted from the monitor. Another importance of the bandwidth is that the monitor's input impedance is specified only for that range, and using higher frequencies can cause reflec- tions probably causing minor screen interferences, and radio disturbance. However, the basic problematic magnitude in question here is the slew rate (the steepness of the video signals) of the video output drivers, and that is usually independent of the actual pixel frequency, but (if your board manu- facturer cares about such problems) related to the maximum pixel frequency of the board. So be careful out there... 12. Using Interlaced Modes (This section is largely due to David Kastrup ) At a fixed dot clock, an interlaced display is going to have considerably less noticable flicker than a non-interlaced display, if the vertical cir- cuitry of your monitor is able to support it stably. It is because of this that interlaced modes were invented in the first place. Interlaced modes got their bad repute because they are inferior to their non- interlaced companions at the same vertical scan frequency, VSF (which is what is usually given in advertisements). But they are definitely superior at the same horizontal scan rate, and that's where the decisive limits of your moni- tor/graphics card usually lie. At a fixed refresh rate (or half frame rate, or VSF) the interlaced display will flicker more: a 90Hz interlaced display will be inferior to a 90Hz non- interlaced display. It will, however, need only half the video bandwidth and half the horizontal scan rate. If you compared it to a non-interlaced mode with the same dot clock and the same scan rates, it would be vastly superior: 45Hz non-interlaced is intolerable. With 90Hz interlaced, I have worked for years with my Multisync 3D (at 1024x768) and am very satisfied. I'd guess you'd need at least a 70Hz non-interlaced display for similar comfort. You have to watch a few points, though: use interlaced modes only at high resolutions, so that the alternately lighted lines are close together. You might want to play with sync pulse widths and positions to get the most sta- ble line positions. If alternating lines are bright and dark, interlace will jump at you. I have one application that chooses such a dot pattern for a menu background (XCept, no other application I know does that, fortunately). I switch to 800x600 for using XCept because it really hurts my eyes other- wise. For the same reason, use at least 100dpi fonts, or other fonts where horizon- tal beams are at least two lines thick (for high resolutions, nothing else will make sense anyhow). And of course, never use an interlaced mode when your hardware would support a non-interlaced one with similar refresh rate. If, however, you find that for some resolution you are pushing either monitor or graphics card to their upper limits, and getting dissatisfactorily flick- ery or outwashed (bandwidth exceeded) display, you might want to try tackling the same resolution using an interlaced mode. Of course this is useless if the VSF of your monitor is already close to its limits. Design of interlaced modes is easy: do it like a non-interlaced mode. Just two more considerations are necessary: you need an odd total number of verti- cal lines (the last number in your mode line), and when you specify the "interlace" flag, the actual vertical frame rate for your monitor doubles. Your monitor needs to support a 90Hz frame rate if the mode you specified looks like a 45Hz mode apart from the "Interlace" flag. As an example, here is my modeline for 1024x768 interlaced: my Multisync 3D will support up to 90Hz vertical and 38kHz horizontal. ModeLine "1024x768" 45 1024 1048 1208 1248 768 768 776 807 Interlace Both limits are pretty much exhausted with this mode. Specifying the same mode, just without the "Interlace" flag, still is almost at the limit of the monitor's horizontal capacity (and strictly speaking, a bit under the lower limit of vertical scan rate), but produces an intolerably flickery display. Basic design rules: if you have designed a mode at less than half of your monitor's vertical capacity, make the vertical total of lines odd and add the "Interlace" flag. The display's quality should vastly improve in most cases. If you have a non-interlaced mode otherwise exhausting your monitor's specs where the vertical scan rate lies about 30% or more under the maximum of your monitor, hand-designing an interlaced mode (probably with somewhat higher resolution) could deliver superior results, but I won't promise it. 13. Questions and Answers Q. The example you gave is not a standard screen size, can I use it? A. Why not? There is NO reason whatsover why you have to use 640x480, 800x600, or even 1024x768. The XFree86 servers let you configure your hard- ware with a lot of freedom. It usually takes two to three tries to come up the right one. The important thing to shoot for is high refresh rate with reasonable viewing area. not high resolution at the price of eye-tearing flicker! Q. It this the only resolution given the 65Mhz dot clock and 55Khz HSF? A. Absolutely not! You are encouraged to follow the general procedure and do some trial-and-error to come up a setting that's really to your liking. Experimenting with this can be lots of fun. Most settings may just give you nasty video hash, but in practice a modern multi-sync monitor is usually not damaged easily. Be sure though, that your monitor can support the frame rates of your mode before using it for longer times. Beware fixed-frequency monitors! This kind of hacking around can damage them rather quickly. Be sure you use valid refresh rates for every experiment on them. Q. You just mentioned two standard resolutions. In Xconfig, there are many standard resolutions available, can you tell me whether there's any point in tinkering with timings? A. Absolutely! Take, for example, the "standard" 640x480 listed in the cur- rent Xconfig. It employes 25Mhz driving frequency, frame lengths are 800 and 525 => refresh rate ~ 59.5Hz. Not too bad. But 28Mhz is a commonly available driving frequency from many SVGA boards. If we use it to drive 640x480, fol- lowing the procedure we discussed above, you would get frame lengths like 812 and 505. Now the refresh rate is raised to 68Hz, a quite significant improvement over the standard one. Q. Can you summarize what we have discussed so far? A. In a nutshell: 1. for any fixed driving frequency, raising max resolution incurs the penalty of lowering refresh rate and thus introducing more flicker. 2. if high resolution is desirable and your monitor supports it, try to get a SVGA card that provides a matching dot clock or DCF. The higher, the better! 14. Fixing Problems with the Image. OK, so you've got your X configuration numbers. You put them in Xconfig with a test mode label. You fire up X, hot-key to the new mode, ... and the image doesn't look right. What do you do? Here's a list of common problems and how to fix them. (Fixing these minor distortions is where xvidtune(1) really shines.) You move the image by changing the sync pulse timing. You scale it by chang- ing the frame length (you need to move the sync pulse to keep it in the same relative position, otherwise scaling will move the image as well). Here are some more specific recipes: The horizontal and vertical positions are independent. That is, moving the image horizontally doesn't affect placement vertically, or vice-versa. How- ever, the same is not quite true of scaling. While changing the horizontal size does nothing to the vertical size or vice versa, the total change in both may be limited. In particular, if your image is too large in both dimensions you will probably have to go to a higher dot clock to fix it. Since this raises the usable resolution, it is seldom a problem! 14.1 The image is displaced to the left or right To fix this, move the horizontal sync pulse. That is, increment or decrement (by a multiple of 8) the middle two numbers of the horizontal timing section that define the leading and trailing edge of the horizontal sync pulse. If the image is shifted left (right border too large, you want to move the image to the right) decrement the numbers. If the image is shifted right (left border too large, you want it to move left) increment the sync pulse. 14.2 The image is displaced up or down To fix this, move the vertical sync pulse. That is, increment or decrement the middle two numbers of the vertical timing section that define the leading and trailing edge of the vertical sync pulse. If the image is shifted up (lower border too large, you want to move the image down) decrement the numbers. If the image is shifted down (top border too large, you want it to move up) increment the numbers. 14.3 The image is too large both horizontally and vertically Switch to a higher card clock speed. If you have multiple modes in your clock file, possibly a lower-speed one is being activated by mistake. 14.4 The image is too wide (too narrow) horizontally To fix this, increase (decrease) the horizontal frame length. That is, change the fourth number in the first timing section. To avoid moving the image, also move the sync pulse (second and third numbers) half as far, to keep it in the same relative position. 14.5 The image is too deep (too shallow) vertically To fix this, increase (decrease) the vertical frame length. That is, change the fourth number in the second timing section. To avoid moving the image, also move the sync pulse (second and third numbers) half as far, to keep it in the same relative position. Any distortion that can't be handled by combining these techniques is proba- bly evidence of something more basically wrong, like a calculation mistake or a faster dot clock than the monitor can handle. Finally, remember that increasing either frame length will decrease your refresh rate, and vice-versa. 15. Plotting Monitor Capabilities To plot a monitor mode diagram, you'll need the gnuplot package (a freeware plotting language for UNIX-like operating systems) and the tool modeplot, a shell/gnuplot script to plot the diagram from your monitor characteristics, entered as command-line options. Here is a copy of modeplot: #!/bin/sh # # modeplot -- generate X mode plot of available monitor modes # # Do `modeplot -?' to see the control options. # # ($Id: video-modes.sgml,v 1.2 1997/08/08 15:07:24 esr Exp $) # Monitor description. Bandwidth in MHz, horizontal frequencies in kHz # and vertical frequencies in Hz. TITLE="Viewsonic 21PS" BANDWIDTH=185 MINHSF=31 MAXHSF=85 MINVSF=50 MAXVSF=160 ASPECT="4/3" vesa=72.5 # VESA-recommended minimum refresh rate while [ "$1" != "" ] do case $1 in -t) TITLE="$2"; shift;; -b) BANDWIDTH="$2"; shift;; -h) MINHSF="$2" MAXHSF="$3"; shift; shift;; -v) MINVSF="$2" MAXVSF="$3"; shift; shift;; -a) ASPECT="$2"; shift;; -g) GNUOPTS="$2"; shift;; -?) cat <" name of monitor defaults to "Viewsonic 21PS" -b bandwidth in MHz defaults to 185 -h min & max HSF (kHz) defaults to 31 85 -v min & max VSF (Hz) defaults to 50 160 -a aspect ratio defaults to 4/3 -g "" pass options to gnuplot The -b, -h and -v options are required, -a, -t, -g optional. You can use -g to pass a device type to gnuplot so that (for example) modeplot's output can be redirected to a printer. See gnuplot(1) for details. The modeplot tool was created by Eric S. Raymond based on analysis and scratch code by Martin Lottermoser This is modeplot $Revision: 1.2 $ EOF exit;; esac shift done gnuplot $GNUOPTS <. Eric S. Raymond reworked, reorganized, and massively rewrote Chin Fang's original in an attempt to understand it. In the process, he merged in most of a different how-to by Bob Crosson . The material on interlaced modes is largely by David Kastrup Martin Lottermoser contributed the idea of using gnuplot to make mode diagrams and did the mathematical analysis behind modeplot. The distributed modeplot was redesigned and generalized by ESR from Martin's original gnuplot code for one case. Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/VidModes.sgml,v 3.14 1997/11/16 10:52:47 dawes Exp $ $XConsortium: VidModes.sgml /main/7 1996/02/21 17:46:17 kaleb $ $XFree86: xc/programs/Xserver/hw/xfree86/doc/VideoModes.doc,v 3.18 1999/04/15 03:35:09 dawes Exp $ > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Friday, November 12, 1999 11:32 AM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: FW: XF86SUP.SYS > > > > > -----Original Message----- > From: Mike MacDonald > Sent: Friday, November 12, 1999 11:30 AM > To: 'Holger Veit' > Subject: XF86SUP.SYS > > > 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. I can use directx to get a pointer to > memory, but I would > have to use directx to set the video mode I think. > > 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. > > Unfortunately that makes it more difficult to display X > in a window which > would be nice. Unless I just pick the svga server, and > fix that to use > DirectX.. Or go nuts and make a directx server which > would prolly be the > best way to go.. I don't know, I think for now I'll > either pick a mode and > just support 1 mode, or try and go to a fullscreen mode > and map the memory.. > If you can let me know how X changes video modes, it > would be really > helpful, thanx! > -------------- next part -------------- XFree86 X server ``New Design'' (DRAFT) The XFree86 Project, Inc Last modified 17 July 1999 NOTE: This is a DRAFT document, and the interfaces described here are subject to change without notice. 1. Preface The broad design principles are: o keep it reasonable o We cannot rewrite the complete server o We don't want to re-invent the wheel o keep it modular o As many things as possible should go into modules o The basic loader binary should be minimal o A clean design with well defined layering is important o DDX specific global variables are a nono o The structure should be flexible enough to allow future extensions o The structure should minimize duplication of common code o keep important features in mind o multiple screens, including multiple instances of drivers o mixing different color depths and visuals on different and ideally even on the same screen o better control of the PCI device used o better config file parser o get rid of all VGA compatibility assumptions Unless we find major deficiencies in the DIX layer, we should avoid making changes there. 2. The XF86Config File The XF86Config file format is similar to the old format, with the following changes: 2.1 Device section The Device sections are similar to what they used to be, and describe hard- ware-specific information for a single video card. Device Some new keywords are added: Driver "drivername" Specifies the name of the driver to be used for the card. This is mandatory. BusID "busslot" Specifies uniquely the location of the card on the bus. The pur- pose is to identify particular cards in a multi-headed configura- tion. The format of the argument is intentionally vague, and may be architecture dependent. For a PCI bus, it is something like "bus:slot:func". A Device section is considered ``active'' if there is a reference to it in an active Screen section. 2.2 Screen section The Screen sections are similar to what they used to be. They no longer have a Driver keyword, but an Identifier keyword is added. (The Driver keyword may be accepted in place of the Identifier keyword for compatibility pur- poses.) The identifier can be used to identify which screen is to be active when multiple Screen sections are present. It is possible to specify the active screen from the command line. A default is chosen in the absence of one being specified. A Screen section is considered ``active'' if there is a reference to it either from the command line, or from an active ServerLayout section. 2.3 InputDevice section The InputDevice section is a new section that describes configuration infor- mation for input devices. It replaces the old Keyboard, Pointer and XInput sections. Like the Device section, it has two mandatory keywords: Identifier and Driver. For compatibility purposes the old Keyboard and Pointer sections are converted by the parser into InputDevice sections as follows: Keyboard Identifier "Implicit Core Keyboard" Driver "keyboard" Pointer Identifier "Implicit Core Pointer" Driver "mouse" An InputDevice section is considered active if there is a reference to it in an active ServerLayout section. An InputDevice section may also be refer- enced implicitly if there is no ServerLayout section, if the -screen command line options is used, or if the ServerLayout section doesn't reference any InputDevice sections. In this case, the first sections with drivers "key- board" and "mouse" are used as the core keyboard and pointer respectively. 2.4 ServerLayout section The ServerLayout section is a new section that is used to identify which Screen sections are to be used in a multi-headed configuration, and the rela- tive layout of those screens. It also identifies which InputDevice sections are to be used. Each ServerLayout section has an identifier, a list of Screen section identifiers, and a list of InputDevice section identifiers. ServerFlags options may also be included in a ServerLayout section, making it possible to override the global values in the ServerFlags section. A ServerLayout section can be made active by being referenced on the command line. In the absence of this, a default will be chosen (the first one found). The screen names may optionally be followed by a number specifying the preferred screen number, and optionally by the names of the four screens adjacent to it. The order of these is top, bottom, left, right. When no screen number is specified, they are numbered according to the order in which they are listed. Here is an example of a ServerLayout section for two screens, with the second located to the right of the first: Section "ServerLayout" Identifier "Main Layout" Screen "Screen 1" 0 "" "" "" "Screen 2" Screen "Screen 2" 1 Screen "Screen 3" EndSection 2.5 Options Options are used more extensively. They may appear in most sections now. Options related to drivers can be present in the Screen, Device and Monitor sections and the Display subsections. The order of precedence is Display, Screen, Monitor, Device. Options have been extended to allow an optional value to be specified in addition to the option name. For more details about options, see the Options (section 10., page 1) section for details. 3. Driver Interface The driver interface consists of a minimal set of entry points that are required based on the external events that the driver must react to. No non- essential structure is imposed on the way they are used beyond that. This is a significant difference compared with the old design. The entry points for drawing operations are already taken care of by the framebuffer code (including, XAA). Extensions and enhancements to frame- buffer code are outside the scope of this document. This approach to the driver interface provides good flexibility, but does increase the complexity of drivers. To help address this, the XFree86 common layer provides a set of ``helper'' functions to take care of things that most drivers need. These helpers help minimise the amount of code duplication between drivers. The use of helper functions by drivers is however optional, though encouraged. The basic philosophy behind the helper functions is that they should be useful to many drivers, that they should balance this against the complexity of their interface. It is inevitable that some drivers may find some helpers unsuitable and need to provide their own code. Events that a driver needs to react to are: ScreenInit An initialisation function is called from the DIX layer for each screen at the start of each server generation. Enter VT The server takes control of the console. Leave VT The server releases control of the console. Mode Switch Change video mode. ViewPort change Change the origin of the physical view port. ScreenSaver state change Screen saver activation/deactivation. CloseScreen A close screen function is called from the DIX layer for each screen at the end of each server generation. In addition to these events, the following functions are required by the XFree86 common layer: Identify Print a driver identifying message. Probe This is how a driver identifies if there is any hardware present that it knows how to drive. PreInit Process information from the XF86Config file, determine the full characteristics of the hardware, and determine if a valid config- uration is present. The VidMode extension also requires: ValidMode Identify if a new mode is usable with the current configuration. The PreInit function (and/or helpers it calls) may also make use of the ValidMode function or something similar. Other extensions may require other entry points. The drivers will inform the common layer of these in such cases. 4. Resource Access Control Introduction Graphics devices are accessed through ranges in I/O or memory space. While most modern graphics devices allow relocation of such ranges many of them still require the use of well established interfaces such as VGA memory and IO ranges or 8514/A IO ranges. With modern buses (like PCI) it is possible for multiple video devices to share access to these resources. The RAC (Resource Access Control) subsystem provides a mechanism for this. 4.1 Terms and Definitions 4.1.1 Bus ``Bus'' is ambiguous as it is used for different things: it may refer to physical incompatible extension connectors in a computer system. The RAC system knows two such systems: The ISA bus and the PCI bus. (On the software level EISA, MCA and VL buses are currently treated like ISA buses). ``Bus'' may also refer to logically different entities on a single bus system which are connected via bridges. A PCI system may have several distinct PCI buses connecting each other by PCI-PCI bridges or to the host CPU by HOST-PCI bridges. Systems that host more than one bus system link these together using bridges. Bridges are a concern to RAC as they might block or pass specific resources. PCI-PCI bridges may be set up to pass VGA resources to the secondary bus. PCI-ISA buses pass any resources not decoded on the primary PCI bus to the ISA bus. This way VGA resources (although exclusive on the ISA bus) can be shared by ISA and PCI cards. Currently HOST-PCI bridges are not yet handled by RAC as they require specific drivers. 4.1.2 Entity The smallest independently addressable unit on a system bus is referred to as an entity. So far we know ISA and PCI entities. PCI entities can be located on the PCI bus by an unique ID consisting of the bus, card and function num- ber. 4.1.3 Resource ``Resource'' refers to a range of memory or I/O addresses an entity can decode. If a device is capable of disabling this decoding the resource is called sharable. For PCI devices a generic method is provided to control resource decoding. Other devices will have to provide a device specific function to control decoding. If the entity is capable of decoding this range at a different location this resource is considered relocatable. Resources which start at a specific address and occupy a single continuous range are called block resources. Alternatively resource addresses can be decoded in a way that they satisfy the conditions: address & mask == base and base & mask == base Resources addressed in such a way are called sparse resources. 4.1.4 Server States The resource access control system knows two server states: the SETUP and the OPERATING state. The SETUP state is entered whenever a mode change takes place or the server exits or does VT switching. During this state all entity resources are under resource access control. During OPERATING state only those entities are controlled which actually have shared resources that con- flict with others. 5. Control Flow in the Server and Mandatory Driver Functions At the start of each server generation, main() (dix/main.c) calls the DDX function InitOutput(). This is the first place that the DDX gets control. InitOutput() is expected to fill in the global screenInfo struct, and one screenInfo.screen[] entry for each screen present. Here is what InitOutput() does: 5.1 Parse the XF86Config file This is done at the start of the first server generation only. The XF86Config file is read in full, and the resulting information stored in data structures. None of the parsed information is processed at this point. The parser data structures are opaque to the video drivers and to most of the common layer code. The entire file is parsed first to remove any section ordering requirements. 5.2 Initial processing of parsed information and command line options This is done at the start of the first server generation only. The initial processing is to determine paths like the ModulePath, etc, and to determine which ServerLayout, Screen and Device sections are active. 5.3 Enable port I/O access Port I/O access is controlled from the XFree86 common layer, and is ``all or nothing''. It is enabled prior to calling driver probes, at the start of subsequent server generations, and when VT switching back to the Xserver. It is disabled at the end of server generations, and when VT switching away from the Xserver. The implementation details of this may vary on different platforms. 5.4 General bus probe This is done at the start of the first server generation only. In the case of ix86 machines, this will be a general PCI probe. The full information obtained here will be available to the drivers. This information persists for the life of the Xserver. In the PCI case, the PCI information for all video cards found is available by calling xf86GetPciVideoInfo(). pciVideoPtr *xf86GetPciVideoInfo(void) returns a pointer to a list of pointers to pciVideoRec entries, of which there is one for each detected PCI video card. The list is terminated with a NULL pointer. If no PCI video cards were detected, the return value is NULL. After the bus probe, the resource broker is initialised. 5.5 Load initial set of modules This is done at the start of the first server generation only. The core server contains a list of mandatory modules. These are loaded first. Currently the only module on this list is the bitmap font module. The next set of modules loaded are those specified explicitly in the Module section of the config file. The final set of initial modules are the driver modules referenced by the active Device and InputDevice sections in the config file. Each of these modules is loaded exactly once. 5.6 Register Video and Input Drivers This is done at the start of the first server generation only. When a driver module is loaded, the loader calls its Setup function. For video drivers, this function calls xf86AddDriver() to register the driver's DriverRec, which contains a small set of essential details and driver entry points required during the early phase of InitOutput(). xf86AddDriver() adds it to the global xf86DriverList[] array. The DriverRec contains the driver's version, a short descriptive message, the Identify() and Probe() function entry points as well as a pointer to the driver's module (as returned from the loader when the driver was loaded) and a reference count which keeps track of how many screens are using the driver. The entry driver entry points are those required prior to the driver allocat- ing and filling in its ScrnInfoRec. For a static server, the xf86DriverList[] array is initialised at build time, and the loading of modules is not done. A similar procedure is used for input drivers. The input driver's Setup function calls xf86AddInputDriver() to register the driver's InputDriverRec, which contains a small set of essential details and driver entry points required during the early phase of InitInput(). xf86AddInputDriver() adds it to the global xf86InputDriverList[] array. For a static server, the xf86InputDriverList[] array is initialised at build time. Both the xf86DriverList[] and xf86InputDriverList[] arrays have been ini- tialised by the end of this stage. Once all the drivers are registered, their ChipIdentify() functions are called. void ChipIdentify(int flags) This is expected to print a message indicating the driver name, a short summary of what it supports, and a list of the chipset names that it supports. It may use the xf86PrintChipsets() helper to do this. void xf86PrintChipsets(const char *drvname, const char *drvmsg, SymTabPtr chips) This function provides an easy way for a driver's ChipI- dentify function to format the identification message. 5.7 Initialise Access Control This is done at the start of the first server generation only. The Resource Access Control (RAC) subsystem is initialised before calling any driver functions that may access hardware. All generic bus information is probed and saved (for restoration later). All (shared resource) video devices are disabled at the generic bus level, and a probe is done to find the ``primary'' video device. These devices remain disabled for the next step. 5.8 Video Driver Probe This is done at the start of the first server generation only. The Chip- Probe() function of each registered video driver is called. Bool ChipProbe(DriverPtr drv, int flags) The purpose of this is to identify all instances of hard- ware supported by the driver. The flags value is cur- rently not used, and should be ignored by the driver. The probe must find the active device sections that match the driver by calling xf86MatchDevice(). The number of matches found limits the maximum number of instances for this driver. If no matches are found, the problem should return FALSE immediately. Devices that cannot be identified by using device-inde- pendent methods should be probed at this stage (keeping in mind that access to all resources that can be disabled in a device-independent way are disabled during this phase). The probe must be a minimal probe. It should just determine if there is a card present that the driver can drive. It should use the least intrusive probe meth- ods possible. It must not do anything that is not essen- tial, like probing for other details such as the amount of memory installed, etc. It is recommended that the xf86MatchPciInstances() helper function be used for iden- tifying matching PCI devices, and similarly the xf86MatchIsaInstances() for ISA (non-PCI) devices (see the RAC (section 9., page 1) section). These helpers also checks and claims the appropriate entity. When not using the helper, that should be done with xf86CheckPciS- lot() and xf86ClaimPciSlot() for PCI devices and xf86ClaimIsaSlot() for ISA devices (see the RAC (section 9., page 1) section). The probe must register all non-relocatable resources at this stage. If a resource conflict is found between exclusive resources the driver will fail immediately. This is usually best done with the xf86ConfigActivePciEn- tity() helper function for PCI and xf86ConfigActiveIsaEn- tity() for ISA (see the RAC (section 9., page 1) sec- tion). It is possible to register some entity specific functions with those helpers. When not using the helpers, the xf86AddEntityToScreen() xf86ClaimFixe- dResources() and xf86SetEntityFuncs() should be used instead (see the RAC (section 9., page 1) section). If a chipset is specified in an active device section which the driver considers relevant (ie it has no driver specified, or the driver specified matches the driver doing the probe), the Probe must return FALSE if the chipset doesn't match one supported by the driver. If there are no active device sections that the driver considers relevant, it must return FALSE. Allocate a ScrnInfoRec for each instance of the hardware found, and fill in the basic information, including the other driver entry points. The xf86AllocateScreen() function must be used to allocate the ScrnInfoRec, and it takes care of initialising fields to defined ``unused'' values. Claim the entities for each instance of the hardware found. This prevents other drivers from claiming the same hardware. Must leave hardware in the same state it found it in, and must not do any hardware initialisation. All detection can be overridden via the config file, and that parsed information is available to the driver at this stage. Returns TRUE if one or more instances are found, and FALSE otherwise. int xf86MatchDevice(const char *drivername, GDevPtr **driversectlist) This function takes the name of the driver and returns via driversectlist a list of device sections that match the driver name. The function return value is the number of matches found. If a fatal error is encountered the return value is -1. The caller should use xfree() to free *driversectlist when it is no longer needed. ScrnInfoPtr xf86AllocateScreen(DriverPtr drv, int flags) This function allocates a new ScrnInfoRec in the xf86Screens[] array. This function is normally called by the video driver ChipProbe() functions. The return value is a pointer to the newly allocated ScrnInfoRec. The scrnIndex, origIndex, module and drv fields are ini- tialised. The reference count in drv is incremented. The storage for any currently allocated ``privates'' pointers is also allocated and the privates field ini- tialised (the privates data is of course not allocated or initialised). This function never returns on failure. If the allocation fails, the server exits with a fatal error. The flags value is not currently used, and should be set to zero. At the completion of this, a list of ScrnInfoRecs have been allocated in the xf86Screens[] array, and the associated entities and fixed resources have been claimed. The following ScrnInfoRec fields must be initialised at this point: driverVersion driverName scrnIndex(*) origIndex(*) drv(*) module(*) name Probe PreInit ScreenInit EnterVT LeaveVT numEntities entityList access (*) These are initialised when the ScrnInfoRec is allocated, and not explic- itly by the driver. The following ScrnInfoRec fields must be initialised if the driver is going to use them: SwitchMode AdjustFrame FreeScreen ValidMode 5.9 Matching Screens This is done at the start of the first server generation only. After the Probe phase is finished, there will be some number of ScrnInfoRecs. These are then matched with the active Screen sections in the XF86Config, and those not having an active Screen section are deleted. If the number of remaining screens is 0, InitOutput() sets screenInfo.numScreens to 0 and returns. At this point the following fields of the ScrnInfoRecs must be initialised: confScreen 5.10 Allocate non-conflicting resources This is done at the start of the first server generation only. Before calling the drivers again, the resource information collected from the Probe phase is processed. This includes checking the extent of PCI resources for the probed devices, and resolving any conflicts in the relocatable PCI resources. It also reports conflicts, checks bus routing issues, and any- thing else that is needed to enable the entities for the next phase. If any drivers registered an EntityInit() function during the Probe phase, then they are called here. 5.11 Sort the Screens and pre-check Monitor Information This is done at the start of the first server generation only. The list of screens is sorted to match the ordering requested in the config file. The list of modes for each active monitor is checked against the monitor's parameters. Invalid modes are pruned. 5.12 PreInit This is done at the start of the first server generation only. For each ScrnInfoRec, enable access to the screens entities and call the ChipPreInit() function. Bool ChipPreInit(ScrnInfoRec screen, int flags) The purpose of this function is to find out all the information required to determine if the configuration is usable, and to initialise those parts of the ScrnInfoRec that can be set once at the beginning of the first server generation. The number of entities registered for the screen should be checked against the expected number (most drivers expect only one). The entity information for each of them should be retrieved (with xf86GetEntityInfo()) and checked for the correct bus type and that none of the sharable resources registered during the Probe phase was rejected. Access to resources for the entities that can be con- trolled in a device-independent way are enabled before this function is called. If the driver needs to access any resources that it has disabled in an EntityInit() function that it registered, then it may enable them here providing that it disables them before this function returns. This includes probing for video memory, clocks, ramdac, and all other HW info that is needed. It includes deter- mining the depth/bpp/visual and related info. It includes validating and determining the set of video modes that will be used (and anything that is required to determine that). This information should be determined in the least intru- sive way possible. The state of the HW must remain unchanged by this function. Although video memory (including MMIO) may be mapped within this function, it must be unmapped before returning. Driver specific information should be stored in a structure hooked into the ScrnInfoRec's driverPrivate field. Any other modules which require persistent data (ie data that persists across server generations) should be initialised in this function, and they should allocate a ``privates'' index to hook their data into by calling xf86AllocateScrnInfo- PrivateIndex(). The ``privates'' data is persistent. Helper functions for some of these things are provided at the XFree86 common level, and the driver can choose to make use of them. All additional resources that the screen needs must be registered here. This should be done with xf86Register- Resources(). If some of the fixed resources registered in the Probe phase are not needed or not decoded by the hardware when in the OPERATING server state, their status should be updated with xf86SetOperatingState(). Modules may be loaded at any point in this function, and all modules that the driver will need must be loaded before the end of this function. The xf86LoadSubModule() function should be used to load modules. A driver may unload a module within this function if it was only needed temporarily, and the UnloadSubModule() function should be used to do that. Otherwise there is no need to explicitly unload modules because the loader takes care of module dependencies and will unload submodules auto- matically if/when the driver module is unloaded. The bulk of the ScrnInfoRec fields should be filled out in this function. ChipPreInit() returns FALSE when the configuration is unusable in some way (unsupported depth, no valid modes, not enough video memory, etc), and TRUE if it is usable. It is expected that if the ChipPreInit() function returns TRUE, then the only reasons that subsequent stages in the driver might fail are lack or resources (like xalloc failures). All other possible reasons for failure should be determined by the ChipPreInit() function. The ScrnInfoRecs for screens where the ChipPreInit() fails are removed. If none remain, InitOutput() sets screenInfo.numScreens to 0 and returns. At this point, further fields of the ScrnInfoRecs would normally be filled in. Most are not strictly mandatory, but many are required by other layers and/or helper functions that the driver may choose to use. The documentation for those layers and helper functions indicates which they require. The following fields of the ScrnInfoRecs should be filled in if the driver is going to use them: monitor display depth pixmapBPP bitsPerPixel weight (>8bpp only) mask (>8bpp only) offset (>8bpp only) rgbBits (8bpp only) gamma defaultVisual maxHValue maxVValue virtualX virtualY displayWidth frameX0 frameY0 frameX1 frameY1 zoomLocked modePool modes currentMode progClock (TRUE if clock is programmable) chipset ramdac clockchip numClocks (if not programmable) clock[] (if not programmable) videoRam biosBase memBase memClk driverPrivate chipID chipRev pointer xf86LoadSubModule(ScrnInfoPtr pScrn, const char *name): Load a module that a driver depends on. This function loads the module name as a sub module of the driver. The return value is a handle identifying the new module. If the load fails, the return value will be NULL. If a driver needs to explicitly unload a module it has loaded in this way, the return value must be saved and passed to UnloadSubModule() when unloading. void UnloadSubModule(pointer module) Unloads the module referenced by module. module should be a pointer returned previously by xf86LoadSubModule(). 5.13 Cleaning up Unused Drivers At this point it is known which screens will be in use, and which drivers are being used. Unreferenced drivers (and modules they may have loaded) are unloaded here. 5.14 Consistency Checks The parameters that must be global to the server, like pixmap formats, bitmap bit order, bitmap scanline unit and image byte order are compared for each of the screens. If a mismatch is found, the server exits with an appropriate message. 5.15 Check of Resource Control is Needed Determine if resource access control is needed. This is the case if more than one screen is used. If necessary the RAC wrapper module is loaded. 5.16 AddScreen (ScreenInit) At this point, the valid screens are known. AddScreen() is called for each of them, passing ChipScreenInit() as the argument. AddScreen() is a DIX function that allocates a new screenInfo.screen[] entry (aka pScreen), and does some basic initialisation of it. It then calls the ChipScreenInit() function, with pScreen as one of its arguments. If ChipScreenInit() returns FALSE, AddScreen() returns -1. Otherwise it returns the index of the screen. AddScreen() should only fail because of programming errors or failure to allocate resources (like memory). All configuration problems should be detected BEFORE this point. Bool ChipScreenInit(int index, ScreenPtr pScreen, int argc, char **argv) This is called at the start of each server generation. Fill in all of pScreen, possibly doing some of this by calling ScreenInit functions from other layers like mi, framebuffers (cfb, etc), and extensions. Decide which operations need to be placed under resource access control. The classes of operations are the frame buffer operations (RAC_FB), the pointer operations (RAC_CURSOR), the viewport change operations (RAC_VIEW- PORT) and the colormap operations (RAC_COLORMAP). Any operation that requires resources which might be disabled during OPERATING state should be set to use RAC. This can be specified separately for memory and IO resources (the racMemFlags and racIoFlags fields of the ScrnInfoRec respectively). Map any video memory or other memory regions. Save the video card state. Enough state must be saved so that the original state can later be restored. Initialise the initial video mode. The ScrnInfoRec's vtSema field should be set to TRUE just prior to changing the video hardware's state. The ChipScreenInit() function (or functions from other layers that it calls) should allocate entries in the ScreenRec's devPrivates area by calling Allo- cateScreenPrivateIndex() if it needs per-generation storage. Since the ScreenRec's devPrivates information is cleared for each server generation, this is the correct place to initialise it. After AddScreen() has successfully returned, the following ScrnInfoRec fields are initialised: pScreen racMemFlags racIoFlags The ChipScreenInit() function should initialise the CloseScreen and Save- Screen fields of pScreen. The old value of pScreen->CloseScreen should be saved as part of the driver's per-screen private data, allowing it to be called from ChipCloseScreen(). This means that the existing CloseScreen() function is wrapped. 5.17 Finalising RAC Initialisation After all the ChipScreenInit() functions have been called, each screen has registered its RAC requirements. This information is used to determine which shared resources are requested by more than one driver and set the access functions accordingly. This is done following these rules: 1. The sharable resources registered by each entity are compared. If a resource is registered by more than one entity the entity will be marked to indicate that it needs to share this resources type (IO or MEM). 2. A resource marked ``disabled'' during OPERATING state will be ignored entirely. 3. A resource marked ``unused'' will only conflict with an overlapping resource of an other entity if the second is actually in use during OPERATING state. 4. If an ``unused'' resource was found to conflict but the entity does not use any other resource of this type the entire resource type will be disabled for that entity. 5.18 Finishing InitOutput() At this point InitOutput() is finished, and all the screens have been setup in their initial video mode. 5.19 Mode Switching When a SwitchMode event is received, ChipSwitchMode() is called (when it exists): Bool ChipSwitchMode(int index, DisplayModePtr mode, int flags) Initialises the new mode for the screen identified by index;. The viewport may need to be adjusted also. 5.20 Changing Viewport When a Change Viewport event is received, ChipAdjustFrame() is called (when it exists): void ChipAdjustFrame(int index, int x, int y, int flags) Changes the viewport for the screen identified by index;. 5.21 VT Switching When a VT switch event is received, xf86VTSwitch() is called. xf86VTSwitch() does the following: On ENTER: o enable port I/O access o save and initialise the bus/resource state o enter the SETUP server state o calls ChipEnterVT() for each screen o enter the OPERATING server state o validate GCs o Restore fb from saved pixmap for each screen o Enable all input devices On LEAVE: o Save fb to pixmap for each screen o validate GCs o enter the SETUP server state o calls ChipLeaveVT() for each screen o disable all input devices o restore bus/resource state o disables port I/O access Bool ChipEnterVT(int index, int flags) This function should map memory regions, initialise the current video mode and initialise the viewport, turn on the HW cursor if appropriate, etc. Should it re-save the video state before initialising the video mode? void ChipLeaveVT(int index, int flags) This function should restore the saved video state and unmap the memory regions. If appropriate it should also turn off the HW cursor, and invalidate any pixmap/font caches. Other layers may wrap the ChipEnterVT() and ChipLeaveVT() functions if they need to take some action when these events are received. 5.22 End of server generation At the end of each server generation, the DIX layer calls ChipCloseScreen() for each screen: Bool ChipCloseScreen(int index, ScreenPtr pScreen) This function should restore the saved video state and unmap the memory regions. It should also free per-screen data structures allocated by the driver. Note that the persistent data held in the ScrnInfoRec's driverPrivate field should not be freed here because it is needed by subsequent server genera- tions. The ScrnInfoRec's vtSema field should be set to FALSE once the video HW state has been restored. Before freeing the per-screen driver data the saved Clos- eScreen value should be restored to pScreen->CloseScreen, and that function should be called after freeing the data. 6. Optional Driver Functions The functions outlined here can be called from the XFree86 common layer, but their presence is optional. 6.1 Mode Validation When a mode validation helper supplied by the XFree86-common layer is being used, it can be useful to provide a function to check for hw specific mode constraints: ModeStatus ChipValidMode(int index, DisplayModePtr mode, Bool verbose, int flags) Check the passed mode for hw-specific constraints, and return the appropriate status value. 6.2 Free screen data When a screen is deleted prior to the completion of the ScreenInit phase the ChipFreeScreen() function is called when defined. void ChipFreeScreen(int scrnindex, int flags) Free any driver-allocated data that may have been allo- cated up to and including an unsuccessful Chip- ScreenInit() call. This would predominantly be data allocated by ChipPreInit() that persists across server generations. It would include the driverPrivate, and any ``privates'' entries that modules may have allocated. 7. Recommended driver functions The functions outlined here are for internal use by the driver only. They are entirely optional, and are never accessed directly from higher layers. The sample function declarations shown here are just examples. The interface (if any) used is up to the driver. 7.1 Save Save the video state. This could be called from ChipScreenInit() and (possi- bly) ChipEnterVT(). void ChipSave(ScrnInfoPtr pScrn) Saves the current state. This will only be saving pre- server states or states before returning to the server. There is only one current saved state per screen and it is stored in private storage in the screen. 7.2 Restore Restore the original video state. This could be called from the ChipLeaveVT() and ChipCloseScreen() functions. void ChipRestore(ScrnInfoPtr pScrn) Restores the saved state from the private storage. Usu- ally only used for restoring text modes. 7.3 Initialise Mode Initialise a video mode. This could be called from the ChipScreenInit(), ChipSwitchMode() and ChipEnterVT() functions. Bool ChipModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode) Programs the hardware for the given video mode. 8. Data and Data Structures 8.1 Command line data Command line options are typically global, and are stored in global vari- ables. These variables are read-only and are available to drivers via a function call interface. Most of these command line values are processed via helper functions to ensure that they are treated consistently by all drivers. The other means of access is provided for cases where the supplied helper functions might not be appropriate. Some of them are: xf86Verbose verbosity level xf86Bpp -bpp from the command line xf86Depth -depth from the command line xf86Weight -weight from the command line xf86Gamma -{r,g,b,}gamma from the command line xf86FlipPixels -flippixels from the command line xf86ProbeOnly -probeonly from the command line defaultColorVisualClass -cc from the command line If we ever do allow for screen-specific command line options, we may need to rethink this. These can be accessed in a read-only manner by drivers with the following functions: int xf86GetVerbosity() Returns the value of xf86Verbose. int xf86GetDepth() Returns the -depth command line setting. If not set on the command line, -1 is returned. rgb xf86GetWeight() Returns the -weight command line setting. If not set on the command line, {0, 0, 0} is returned. Gamma xf86GetGamma() Returns the -gamma or -rgamma, -ggamma, -bgamma command line settings. If not set on the command line, {0.0, 0.0, 0.0} is returned. Bool xf86GetFlipPixels() Returns TRUE if -flippixels is present on the command line, and FALSE otherwise. const char *xf86GetServerName() Returns the name of the X server from the command line. 8.2 Data handling Config file data contains parts that are global, and parts that are Screen specific. All of it is parsed into data structures that neither the drivers or most other parts of the server need to know about. The global data is typically not required by drivers, and as such, most of it is stored in the private xf86InfoRec. The screen-specific data collected from the config file is stored in screen, device, display, monitor-specific data structures that are separate from the ScrnInfoRecs, with the appropriate elements/fields hooked into the ScrnIn- foRecs as required. The screen config data is held in confScreenRec, device data in the GDevRec, monitor data in the MonRec, and display data in the Dis- pRec. The XFree86 common layer's screen specific data (the actual data in use for each screen) is held in the ScrnInfoRecs. As has been outlined above, the ScrnInfoRecs are allocated at probe time, and it is the responsibility of the Drivers' Probe() and PreInit() functions to finish filling them in based on both data provided on the command line and data provided from the Config file. The precedence for this is: command line -> config file -> probed/default data For most things in this category there are helper functions that the drivers can use to ensure that the above precedence is consistently used. As well as containing screen-specific data that the XFree86 common layer (including essential parts of the server infrastructure as well as helper functions) needs to access, it also contains some data that drivers use internally. When considering whether to add a new field to the ScrnInfoRec, consider the balance between the convenience of things that lots of drivers need and the size/obscurity of the ScrnInfoRec. Per-screen driver specific data that cannot be accommodated with the static ScrnInfoRec fields is held in a driver-defined data structure, a pointer to which is assigned to the ScrnInfoRec's driverPrivate field. This is per- screen data that persists across server generations (as does the bulk of the static ScrnInfoRec data). It would typically also include the video card's saved state. Per-screen data for other modules that the driver uses (for example, the XAA module) that is reset for each server generation is hooked into the ScrnIn- foRec through it's privates field. Once it has stabilised, the data structures and variables accessible to video drivers will be documented here. In the meantime, those things defined in the xf86.h and xf86str.h files are visible to video drivers. Things defined in xf86Priv.h and xf86Privstr.h are NOT intended to be visible to video drivers, and it is an error for a driver to include those files. 8.3 Accessing global data Some other global state information that the drivers may access via functions is as follows: Bool xf86ServerIsExiting() Returns TRUE if the server is at the end of a generation and is in the process of exiting, and FALSE otherwise. Bool xf86ServerIsResetting() Returns TRUE if the server is at the end of a generation and is in the process of resetting, and FALSE otherwise. Bool xf86ServerIsInitialising() Returns TRUE if the server is at the beginning of a gen- eration and is in the process of initialising, and FALSE otherwise. Bool xf86ServerIsOnlyProbing() Returns TRUE if the -probeonly command line flag was specified, and FALSE otherwise. Bool xf86CaughtSignal() Returns TRUE if the server has caught a signal, and FALSE otherwise. 8.4 Allocating private data A driver and any module it uses may allocate per-screen private storage in either the ScreenRec (DIX level) or ScrnInfoRec (XFree86 common layer level). ScreenRec storage persists only for a single server generation, and ScrnIn- foRec storage persists across generations for the lifetime of the server. The ScreenRec devPrivates data must be reallocated/initialised at the start of each new generation. This is normally done from the ChipScreenInit() function, and Init functions for other modules that it calls. Data allocated in this way should be freed by the driver's ChipCloseScreen() functions, and Close functions for other modules that it calls. A new devPrivates entry is allocated by calling the AllocateScreenPrivateIndex() function. int AllocateScreenPrivateIndex() This function allocates a new element in the devPrivates field of all currently existing ScreenRecs. The return value is the index of this new element in the devPrivates array. The devPrivates field is of type DevUnion: typedef union _DevUnion { pointer ptr; long val; unsigned long uval; pointer (*fptr)(void); } DevUnion; which allows the element to be used for any of the above types. It is commonly used as a pointer to data that the caller allocates after the new index has been allocated. This function will return -1 when there is an error allo- cating the new index. The ScrnInfoRec privates data persists for the life of the server, so only needs to be allocated once. This should be done from the ChipPreInit() func- tion, and Init functions for other modules that it calls. Data allocated in this way should be freed by the driver's ChipFreeScreen() functions, and Free functions for other modules that it calls. A new privates entry is allocated by calling the xf86AllocateScrnInfoPrivateIndex() function. int xf86AllocateScrnInfoPrivateIndex() This function allocates a new element in the privates field of all currently existing ScrnInfoRecs. The return value is the index of this new element in the privates array. The privates field is of type DevUnion: typedef union _DevUnion { pointer ptr; long val; unsigned long uval; pointer (*fptr)(void); } DevUnion; which allows the element to be used for any of the above types. It is commonly used as a pointer to data that the caller allocates after the new index has been allocated. This function will not return when there is an error allocating the new index. When there is an error it will cause the server to exit with a fatal error. The similar function for allocation privates in the ScreenRec (Allo- cateScreenPrivateIndex()) differs in this respect by returning -1 when the allocation fails. 9. Keeping Track of Bus Resources 9.1 Theory of Operation The XFree86 common layer has knowledge of generic access control mechanisms for devices on certain bus systems (currently the PCI bus) as well as of methods to enable or disable access to the buses itself. Furthermore it can access information on resources decoded by these devices and if necessary modify it. When first starting the Xserver collects all this information, saves it for restoration, checks it for consistency, and if necessary, corrects it. Finally it disables all resources on a generic level prior to calling any driver function. When the Probe() function of each driver is called the device sections are matched against the devices found in the system. The driver may probe devices at this stage that cannot be identified by using device independent methods. Access to all resources that can be controlled in a device indepen- dent way is disabled. The Probe() function should register all non-relocat- able resources at this stage. If a resource conflict is found between exclu- sive resources the driver will fail immediately. Optionally the driver might specify an EntityInit(), EntityLeave() and EntityEnter() function. EntityInit() can be used to disable any shared resources that are not con- trolled by the generic access control functions. It is called prior to the PreInit phase regardless if an entity is active or not. When calling the EntityInit(), EntityEnter() and EntityLeave() functions the common level will disable access to all other entities on a generic level. Since the common level has no knowledge of device specific methods to disable access to resources it cannot be guaranteed that certain resources are not decoded by any other entity until the EntityInit() or EntityEnter() phase is finished. Device drivers should therefore register all those resources which they are going to disable. If these resources are never to be used by any driver function they may be flagged ResInit so that they can be removed from the resource list after processing all EntityInit() functions. EntityEnter() should disable decoding of all resources which are not registered as exclu- sive and which are not handled by the generic access control in the common level. The difference to EntityInit() is that the latter one is only called once during lifetime of the server. It can therefore be used to set up vari- ables prior to disabling resources. EntityLeave() should restore the origi- nal state when exiting the server or switching to a different VT. It also needs to disable device specific access functions if they need to be disabled on server exit or VT switch. The default state is to enable them before giv- ing up the VT. In PreInit() phase each driver should check if any sharable resources it has registered during Probe() has been denied and take appropriate action which could simply be to fail. If it needs to access resources it has disabled during EntitySetup() it can do so provided it has registered these and will disable them before returning from PreInit(). This also applies to all other driver functions. Several functions are provided to request resource ranges, register these, correct PCI config space and add replacements for the generic access functions. Resources may be marked ``disabled'' or ``unused'' during OPERATING stage. Although these steps could also be performed in ScreenInit(), this is not desirable. Following PreInit() phase the common level determines if resource access con- trol is needed. This is the case if more than one screen is used. If neces- sary the RAC wrapper module is loaded. In ScreenInit() the drivers can decide which operations need to be placed under RAC. Available are the frame buffer operations, the pointer operations and the colormap operations. Any operation that requires resources which might be disabled during OPERATING state should be set to use RAC. This can be specified separately for memory and IO resources. When ScreenInit() phase is done the common level will determine which shared resources are requested by more than one driver and set the access functions accordingly. This is done following these rules: 1. The sharable resources registered by each entity are compared. If a resource is registered by more than one entity the entity will be marked to need to share this resources type (IO or MEM). 2. A resource marked ``disabled'' during OPERATING state will be ignored entirely. 3. A resource marked ``unused'' will only conflicts with an overlapping resource of an other entity if the second is actually in use during OPERATING state. 4. If an ``unused'' resource was found to conflict however the entity does not use any other resource of this type the entire resource type will be disabled for that entity. The driver has the choice among different ways to control access to certain resources: 1. It can rely on the generic access functions. This is probably the most common case. Here the driver only needs to register any resource it is going to use. 2. It can replace the generic access functions by driver specific ones. This will mostly be used in cases where no generic access functions are available. In this case the driver has to make sure these resources are disabled when entering the PreInit() stage. Since the replacement functions are registered in PreInit() the driver will have to enable these resources itself if it needs to access them during this state. The driver can specify if the replacement functions can control memory and/or I/O resources separately. 3. The driver can enable resources itself when it needs them. Each driver function enabling them needs to disable them before it will return. This should be used if a resource which can be controlled in a device dependent way is only required during SETUP state. This way it can be marked ``unused'' during OPERATING state. A resource which is decoded during OPERATING state however never accessed by the driver should be marked unused. Since access switching latencies are an issue during Xserver operation, the common level attempts to minimize the number of entities that need to be placed under RAC control. When a wrapped operation is called, the EnableAc- cess() function is called before control is passed on. EnableAccess() checks if a screen is under access control. If not it just establishes bus routing and returns. If the screen needs to be under access control, EnableAccess() determines which resource types (MEM, IO) are required. Then it tests if this access is already established. If so it simply returns. If not it dis- ables the currently established access, fixes bus routing and enables access to all entities registered for this screen. Whenever a mode switch or a VT-switch is performed the common level will return to SETUP state. 9.2 Resource Types Resource have certain properties. When registering resources each range is accompanied by a flag consisting of the ORed flags of the different proper- ties the resource has. Each resource range may be classified according to o its physical properties i.e., if it addresses memory (ResMem) or I/O space (ResIo), o if it addresses a block (ResBlock) or sparse (ResSparse) range, o its access properties. There are two known access properties: o ResExclusive for resources which may not be shared with any other device and o ResShared for resources which can be disabled and therefore can be shared. If it is necessary to test a resource against any type a generic access type ResAny is provided. If this is set the resource will conflict with any resource of a different entity intersecting its range. Further it can be specified that a resource is decoded however never used during any stage (ResUnused) or during OPERATING state (ResUnusedOpr). A resource only visi- ble during the init functions (ie. EntityInit(), EntityEnter() and EntityLeave() should be registered with the flag ResInit. A resource that might conflict with background resource ranges may be flagged with ResBios. This might be useful when registering resources ranges that were assigned by the system Bios. Several predefined resource lists are available for VGA and 8514/A resources in common/xf86Resources.h. 9.3 Available Functions The functions provided for resource management are listed in their order of use in the driver. 9.3.1 Probe Phase In this phase each driver detects those resources it is able to drive, cre- ates an entity record for each of them, registers non-relocatable resources and allocates screens and adds the resources to screens. Two helper functions are provided for matching device sections in the XF86Config file to the devices: int xf86MatchPciInstances(const char *driverName, int vendorID, SymTabPtr chipsets, PciChipsets *PCIchipsets, GDevPtr *devList, int numDevs, GDevPtr *devList, int numDevs, DriverPtr drvp, int **foundEntities) This function finds matches between PCI cards that a driver supports and config file device sections. It is intended for use in the ChipProbe() function of drivers for PCI cards. Only probed PCI devices with a vendor ID matching vendorID are considered. devList and numDevs are typically those found from calling xf86MatchDevice(), and represent the active config file device sections rel- evant to the driver. PCIchipsets is a table that pro- vides a mapping between the PCI device IDs, the driver's internal chipset tokens and a list of fixed resources. When a device section doesn't have a BusID entry it can only match the primary video device. Secondary devices are only matched with device sections that have a match- ing BusID entry. Once the preliminary matches have been found, a final match is confirmed by checking if the chipset override, ChipID override or probed PCI chipset type match one of those given in the chipsets and PCIchipsets lists. The PCIchipsets list includes a list of the PCI device IDs supported by the driver. The list should be terminated with an entry with PCI ID -1". The chipsets list is a table mapping the driver's internal chipset tokens to names, and should be terminated with a NULL entry. Only those entries with a corresponding entry in the PCI- chipsets list are considered. The order of precedence is: config file chipset, config file ChipID, probed PCI device ID. In cases where a driver handles PCI chipsets with more than one vendor ID, it may set vendorID to 0, and OR each devID in the list with (the vendor ID << 16). Entity index numbers for confirmed matches are returned as an array via foundEntities. The PCI information, chipset token and device section for each match are found in the EntityInfoRec referenced by the indices. The function return value is the number of confirmed matches. A return value of -1 indicates an internal error. The returned foundEntities array should be freed by the driver with xfree() when it is no longer needed in cases where the return value is greater than zero. int xf86MatchIsaInstances(const char *driverName, SymTabPtr chipsets, IsaChipsets *ISAchipsets, DriverPtr drvp, FindIsaDevProc FindIsaDevice, GDevPtr *devList, int numDevs, int **foundEntities) This function finds matches between ISA cards that a driver supports and config file device sections. It is intended for use in the ChipProbe() function of drivers for ISA cards. devList and numDevs are typically those found from calling xf86MatchDevice(), and represent the active config file device sections relevant to the driver. ISAchipsets is a table that provides a mapping between the driver's internal chipset tokens and the resource classes. FindIsaDevice is a driver-provided function that probes the hardware and returns the chipset token corresponding to what was detected, and -1 if noth- ing was detected. If the config file device section contains a chipset entry, then it is checked against the chipsets list. When no chipset entry is present, the FindIsaDevice func- tion is called instead. Entity index numbers for confirmed matches are returned as an array via foundEntities. The chipset token and device section for each match are found in the EntityIn- foRec referenced by the indices. The function return value is the number of confirmed matches. A return value of -1 indicates an internal error. The returned foundEntities array should be freed by the driver with xfree() when it is no longer needed in cases where the return value is greater than zero. These two helper functions make use of several core functions that are avail- able at the driver level: Bool xf86ParsePciBusString(const char *busID, int *bus, int *device, int *func) Takes a BusID string, and if it is in the correct format, returns the PCI bus, device, func values that it indi- cates. The format of the string is expected to be "PCI:bus:device:func" where each of `bus', `device' and `func' are decimal integers. The ":func" part may be omitted, and the func value assumed to be zero, but this isn't encouraged. The "PCI" prefix may also be omitted. The prefix "AGP" is currently equivalent to the "PCI" prefix. If the string isn't a valid PCI BusID, the return value is FALSE. Bool xf86ComparePciBusString(const char *busID, int bus, int device, int func) Compares a BusID string with PCI bus, device, func val- ues. If they match TRUE is returned, and FALSE if they don't. Bool xf86ParseIsaBusString(const char *busID) Compares a BusID string with the ISA bus ID string ("ISA" or "ISA:"). If they match TRUE is returned, and FALSE if they don't. Bool xf86CheckPciSlot(int bus, int device, int func) Checks if the PCI slot bus:device:func has been claimed. If so, it returns FALSE, and otherwise TRUE. int xf86ClaimPciSlot(int bus, int device, int func, DriverPtr drvp, int chipset, GDevPtr dev, Bool active) This function is used to claim a PCI slot, allocate the associated entity record and initialise their data struc- tures. The return value is the index of the newly allo- cated entity record, or -1 if the claim fails. This function should always succeed if xf86CheckPciSlot() returned TRUE for the same PCI slot. Bool xf86IsPrimaryPci(void) This function returns TRUE if the primary card is a PCI device, and FALSE otherwise. int xf86ClaimIsaSlot(DriverPtr drvp, int chipset, GDevPtr dev, Bool active) This allocates an entity record entity and initialise the data structures. The return value is the index of the newly allocated entity record. Bool xf86IsPrimaryIsa(void) This function returns TRUE if the primary card is an ISA (non-PCI) device, and FALSE otherwise. Two helper functions are provided to aid configuring entities: Bool xf86ConfigActivePciEntity(ScrnInfoPtr pScrn, int entityIndex, PciChipsets *p_chip, resList res, EntityProc init, EntityProc enter, EntityProc leave, pointer private) Bool xf86ConfigActiveIsaEntity(ScrnInfoPtr pScrn, int entityIndex, IsaChipsets *i_chip, resList res, EntityProc init, EntityProc enter, EntityProc leave, pointer private) These functions are used to register the non-relocatable resources for an entity, and the optional entity-specific Init, Enter and Leave functions. Usually the list of fixed resources is obtained from the Isa/PciChipsets lists. However an additional list of resources may be passed. Generally this is not required. The return value is TRUE when successful. The init, enter, leave functions are defined as follows: typedef void (*EntityProc)(int entityIndex, pointer private) They are passed the entity index and a pointer to a pri- vate scratch area. This are can be set up during Probe() and its address can be passed to xf86ConfigActiveIsaEn- tity() xf86ConfigActivePciEntity() as the last argument. These two helper functions make use of several core functions that are avail- able at the driver level: void xf86ClaimFixedResources(resList list, int entityIndex) This function registers the non-relocatable resources which cannot be disabled and which therefore would cause the server to fail immediately if they were found to con- flict. It also records non-relocatable but sharable resources for processing after the Probe() phase. Bool xf86SetEntityFuncs(int entityIndex, EntityProc init, EntityProc enter, EntityProc leave, pointer) This function registers with an entity the init, enter, leave functions along with the pointer to their private area. void xf86AddEntityToScreen(ScrnInfoPtr pScrn, int entityIndex) This function associates the entity referenced by enti- tyIndex with the screen. 9.3.2 PreInit Phase During this phase the remaining resource should be registered. PreInit() should call xf86GetEntityInfo() To obtain a pointer to an EntityInfoRec for each entity it is able to drive and check if any resource are listed in its resources field. If resources registered in the Probe phase have been rejected in the post-Probe phase (resources == NULL), then the driver should decide if it can continue without using these or if it should fail. EntityInfoPtr xf86GetEntityInfo(int entityIndex) This function returns a pointer to the EntityInfoRec ref- erenced by entityIndex. The returned EntityInfoRec should be freed with xfree() when no longer needed. Several functions are provided to simplify resource registration: Bool xf86IsEntityPrimary(int entityIndex) This function returns TRUE if the entity referenced by entityIndex is the display device that primary display device (i.e., the one initialised at boot time and used in text mode). Bool xf86IsScreenPrimary(int scrnIndex) This function returns TRUE if the primary entity is reg- istered with the screen referenced by scrnIndex. pciVideoPtr xf86GetPciInfoForEntity(int entityIndex) This function returns a pointer to the pciVideoRec for the specified entity. If the entity is not a PCI device, NULL is returned. The primary function for registration of resources is: resPtr xf86RegisterResources(int entityIndex, resList list, int access) This function tries to register the resources in list. If list is NULL it tries to determine the resources auto- matically. This only works for entities that provide a generic way to read out the resource ranges they decode. So far this is only the case for PCI devices. By default the PCI resources are registered as shared (ResShared) if the driver wants to set a different access type it can do so by specifying the access flags in the third argument. A value of 0 means to use the default settings. If for any reason the resource broker is not able to register some of the requested resources the function will return a pointer to a list of the failed ones. In this case the driver may be able to move the resource to different locations. In case of PCI bus entities this is done by passing the list of failed resources to xf86ReallocateP- ciResources(). When the registration succeeds, the return value is NULL. resPtr xf86ReallocatePciResources(int entityIndex, resPtr pRes) This function takes a list of PCI resources that need to be reallocated and returns a list of the reallocated resource. This list needs to be passed to xf86Register- Resources() again to be registered with the broker. If the reallocation fails, NULL is returned. Two functions are provided to obtain a resource range of a given type: resRange xf86GetBlock(long type, memType size, memType window_start, memType window_end, memType align_mask, resPtr avoid) This function tries to find a block range of size size and type type in a window bound by window_start and win- dow_end with the alignment specified in align_mask. Optionally a list of resource ranges which should be avoided within the window can be supplied. On failure a zero-length range of type ResEnd will be returned. resRange xf86GetSparse(long type, memType fixed_bits, memType decode_mask, memType address_mask, resPtr avoid) This function is like the previous one, but attempts to find a sparse range instead of a block range. Here three values have to be specified: the address_mask which marks all bits of the mask part of the address, the decode_mask which masks out the bits which are hardcoded and are therefore not available for relocation and the values of the fixed bits. The function tries to find a base that satisfies the given condition. If the function fails it will return a zero range of type ResEnd. Optionally it might be passed a list of resource ranges to avoid. Some PCI devices are broken in the sense that they return invalid size infor- mation for a certain resource. In this case the driver can supply the cor- rect size and make sure that the resource range allocated for the card is large enough to hold the address range decoded by the card. The function xf86FixPciResource() can be used to do this: Bool xf86FixPciResource(int entityIndex, unsigned int prt, CARD32 alignment, long type) This function fixes a PCI resource allocation. The prt parameter contains the number of the PCI base register that needs to be fixed (0-5, and 6 for the BIOS base reg- ister). The size is specified by the alignment. Since PCI resources need to span an integral range of the size 2^n the alignment also specifies the number of addresses that will be decoded. If the driver specifies a type mask it can override the default type for PCI resources which is ResShared. The resource broker needs to know that to find a matching resource range. This function should be called before calling xf86RegisterResources(). The return value is TRUE when the function succeeds. Bool xf86CheckPciMemBase(pciVideoPtr pPci, memType base) This function checks that the memory base address speci- fied matches one of the PCI base address register values for the given PCI device. This is mostly used to check that an externally provided base address (e.g., from a config file) matches an actual value allocated to a device. The driver may replace the generic access control functions for an entity by it's own ones. This is done with the xf86SetAccessFuncs(): void xf86SetAccessFuncs(EntityInfoPtr pEnt, xf86AccessPtr p_io, xf86AccessPtr p_mem, xf86AccessPtr p_io_mem, xf86AccessPtr *ppAccessOld) The driver can pass three functions: one for I/O access, one for memory access and one for combined memory and I/O access. If the memory access and combined access func- tions are identical the common level assumes that the memory access cannot be controlled independently of I/O access, if the I/O access function and the combined access functions are the same it is assumed that I/O can not be controlled independently. If memory and I/O have to be controlled together all three values should be the same. If a non NULL value is passed as fifth argument it is interpreted as an address where to store the old access record. If the fifth argument is NULL it will be assumed that the generic access should be enabled before replacing the access functions. Otherwise it will be disabled. The driver may enable them itself using the returned values. It should do this from his replacement access functions as the generic access may be disabled by the common level on certain occasions. If replacement functions are specified they must control all resources of the specific type registered for the entity. To find out if specific resource range is conflicting with another resource the xf86ChkConflict() function may be used: memType xf86ChkConflict(resRange *rgp, int entityIndex) This function checks if the resource range rgp of for the specified entity conflicts with with another resource. If it a conflict is found, the address of the start of the conflict is returned. The return value is zero when there is no conflict. The OPERATING state properties of previously registered fixed resources can be set with the xf86SetOperatingState() function: resPtr xf86SetOperatingState(resList list, int entityIndex, int mask) This function is used to set the status of a resource during OPERATING state. list holds a list to which mask is to be applied. The parameter mask may have the value ResUnusedOpr and ResDisableOpr. The first one should be used if a resource isn't used by the driver during OPER- ATING state although it is decoded by the device, while the latter one indicates that the resource is not decoded during OPERATING state. Note that the resource ranges have to match those specified during registration. If a range has been specified starting at A and ending at B and suppose C us a value satisfying A < C < B one may not specify the resource range (A,B) by splitting it into two ranges (A,C) and (C,B). The following two functions are provided for special cases: void xf86RemoveEntityFromScreen(ScrnInfoPtr pScrn, int entityIndex) This function may be used to remove an entity from a screen. This only makes sense if a screen has more than one entity assigned or the screen is to be deleted. No test is made if the screen has any entities left. void xf86DeallocateResourcesForEntity(int entityIndex, long type) This function deallocates all resources of a given type registered for a certain entity from the resource broker list. 9.3.3 ScreenInit Phase All that is required in this phase is to setup the RAC flags. Note that it is also permissible to set these flags up in the PreInit phase. The RAC flags are held in the racIoFlags and racMemFlags fields of the ScrnInfoRec for each screen. They specify which graphics operations might require the use of shared resources. This can be specified separately for memory and I/O resources. The available flags are defined in rac/xf86RAC.h. They are: RAC_FB for framebuffer operations (including hw acceleration) RAC_CURSOR for Cursor operations (??? I'm not sure if we need this for SW cur- sor it depends on which level the sw cursor is drawn) RAC_COLORMAP for colormap operations RAC_VIEWPORT for the call to ChipAdjustFrame() The flags are ORed together. 10. Config file ``Option'' entries Option entries are permitted in most sections and subsections of the config file. There are two forms of option entries: Option "option-name" A boolean option. Option "option-name" "option-value" An option with an arbitrary value. The option entries are handled by the parser, and a list of the parsed options is included with each of the appropriate data structures that the drivers have access to. The data structures used to hold the option informa- tion are opaque to the driver, and a driver must not access the option data directly. Instead, the common layer provides a set of functions that may be used to access, check and manipulate the option data. First, the low level option handling functions. In most cases drivers would not need to use these directly. pointer xf86FindOption(pointer options, const char *name) Takes a list of options and an option name, and returns a handle for the first option entry in the list matching the name. Returns NULL if no match is found. char *xf86FindOptionValue(pointer options, const char *name) Takes a list of options and an option name, and returns the value associated with the first option entry in the list matching the name. If the matching option has no value, an empty string ("") is returned. Returns NULL if no match is found. void xf86MarkOptionUsed(pointer option) Takes a handle for an option, and marks that option as used. void xf86MarkOptionUsedByName(pointer options, const char *name) Takes a list of options and an option name and marks the first option entry in the list matching the name as used. Next, the higher level functions that most drivers would use. void xf86CollectOptions(ScrnInfoPtr pScrn, pointer extraOpts) Collect the options from each of the config file sections used by the screen (pScrn) and return the merged list as pScrn->options. This function requires that pScrn->conf- Screen, pScrn->display, pScrn->monitor, pScrn->numEnti- ties, and pScrn->entityList are initialised. extraOpts may optionally be set to an additional list of options to be combined with the others. The order of precedence for options is extraOpts, display, confScreen, monitor, device. void xf86ProcessOptions(int scrnIndex, pointer options, OptionInfoPtr optinfo) Processes a list of options according to the information in the array of OptionInfoRecs (optinfo). The resulting information is stored in the value fields of the appro- priate optinfo entries. The found fields are set to TRUE when an option with a value of the correct type if found, and FALSE otherwise. The type field is used to determine the expected value type for each option. Each option in the list of options for which there is a name match (but not necessarily a value type match) is marked as used. Warning messages are printed when option values don't match the types specified in the optinfo data. NOTE: If this function is called before a driver's screen number is known (e.g., from the ChipProbe() function) a scrnIndex value of -1 should be used. The OptionInfoRec is defined as follows: typedef struct { double freq; int units; } OptFrequency; typedef union { unsigned long num; char * str; double realnum; Bool bool; OptFrequency freq; } ValueUnion; typedef enum { OPTV_NONE = 0, OPTV_INTEGER, OPTV_STRING, /* a non-empty string */ OPTV_ANYSTR, /* Any string, including an empty one */ OPTV_REAL, OPTV_BOOLEAN, OPTV_FREQ } OptionValueType; typedef enum { OPTUNITS_HZ = 1, OPTUNITS_KHZ, OPTUNITS_MHZ } OptFreqUnits; typedef struct { int token; const char* name; OptionValueType type; ValueUnion value; Bool found; } OptionInfoRec, *OptionInfoPtr; OPTV_FREQ can be used for options values that are fre- quencies. These values are a floating point number with an optional unit name appended. The unit name can be one of "Hz", "kHz", "k", "MHz", "M". The multiplier associ- ated with the unit is stored in freq.units, and the scaled frequency is stored in freq.freq. When no unit is specified, freq.units is set to 0, and freq.freq is unscaled. Typical usage is to setup a static array of OptionIn- foRecs with the token, name, and type fields initialised. The value and found fields get set by xf86ProcessOp- tions(). For cases where the value parsing is more com- plex, the driver should specify OPTV_STRING, and parse the string itself. An example of using this option han- dling is included in the Sample Driver (section 20., page 1) section. void xf86ShowUnusedOptions(int scrnIndex, pointer options) Prints out warning messages for each option in the list of options that isn't marked as used. This is intended to show options that the driver hasn't recognised. It would normally be called near the end of the Chip- ScreenInit() function, but only when serverGeneration == 1. OptionInfoPtr xf86TokenToOptinfo(OptionInfoPtr table, int token) Returns a pointer to the OptionInfoRec in table with a token field matching token. Returns NULL if no match is found. Bool xf86IsOptionSet(OptionInfoPtr table, int token) Returns the found field of the OptionInfoRec in table with a token field matching token. This can be used for options of all types. Note that for options of type OPTV_BOOLEAN, it isn't sufficient to check this to deter- mine the value of the option. Returns FALSE if no match is found. char *xf86GetOptValString(OptionInfoPtr table, int token) Returns the value.str field of the OptionInfoRec in table with a token field matching token. Returns NULL if no match is found. Bool xf86GetOptValInteger(OptionInfoPtr table, int token, int *value) Returns via *value the value.num field of the OptionIn- foRec in table with a token field matching token. *value is only changed when a match is found so it can be safely initialised with a default prior to calling this func- tion. The function return value is as for xf86IsOption- Set(). Bool xf86GetOptValULong(OptionInfoPtr table, int token, unsigned long *value) Like xf86GetOptValInteger(), except the value is treated as an unsigned long. Bool xf86GetOptValReal(OptionInfoPtr table, int token, double *value) Like xf86GetOptValInteger(), except that value.realnum is used. Bool xf86GetOptValFreq(OptionInfoPtr table, int token, OptFreqUnits expectedUnits, double *value) Like xf86GetOptValInteger(), except that the value.freq data is returned. The frequency value is scaled to the units indicated by expectedUnits. The scaling is exact when the units were specified explicitly in the option's value. Otherwise, the expectedUnits field is used as a hint when doing the scaling. In this case, values larger than 1000 are assumed to have be specified in the next smallest units. For example, if the Option value is "10000" and expectedUnits is OPTUNITS_MHZ, the value returned is 10. Bool xf86GetOptValBool(OptionInfoPtr table, int token, Bool *value) This function is used to check boolean options (OPTV_BOOLEAN). If the function return value is FALSE, it means the option wasn't set. Otherwise *value is set to the boolean value indicated by the option's value. No option value is interpreted as TRUE. Option values mean- ing TRUE are "1", "yes", "on", "true", and option values meaning FALSE are "0", "no", "off", "false". Option names both with the "no" prefix in their names, and with that prefix removed are also checked and handled in the obvious way. *value is not changed when the option isn't present. It should normally be set to a default value before calling this function. Bool xf86ReturnOptValBool(OptionInfoPtr table, int token, Bool def) This function is used to check boolean options (OPTV_BOOLEAN). If the option is set, its value is returned. If the options is not set, the default value specified by def is returned. The option interpretation is the same as for xf86GetOptValBool(). int xf86NameCmp(const char *s1, const char *s2) This function should be used when comparing strings from the config file with expected values. It works like str- cmp(), but is not case sensitive and space, tab, and `_' characters are ignored in the comparison. The use of this function isn't restricted to parsing option values. It may be used anywhere where this functionality required. 11. Modules, Drivers, Include Files and Interface Issues NOTE: this section is incomplete. 11.1 Include files The following include files are typically required by video drivers: All drivers should include these: "xf86.h" "xf86_OSproc.h" "xf86_ansic.h" "xf86Resources.h" Wherever inb/outb (and related things) are used the following should be included: "compiler.h" Drivers that need to access PCI vendor/device definitions need this: "xf86PciInfo.h" Drivers that need to access the PCI config space need this: "xf86Pci.h" Drivers that initialise a SW cursor need this: "mipointer.h" All drivers implementing backing store need this: "mibstore.h" All drivers using the mi colourmap code need this: "micmap.h" If a driver uses the vgahw module, it needs this: "vgaHW.h" Drivers supporting VGA or Hercules monochrome screens need: "xf1bpp.h" Drivers supporting VGA or EGC 16-colour screens need: "xf4bpp.h" Drivers using cfb need: #define PSZ 8 #include "cfb.h" #undef PSZ Drivers supporting bpp 16, 24 or 32 with cfb need one or more of: "cfb16.h" "cfb24.h" "cfb32.h" If a driver uses XAA, it needs these: "xaa.h" "xaalocal.h" If a driver uses the fb manager, it needs this: "xf86fbman.h" Non-driver modules should include "xf86_ansic.h" to get the correct wrapping of ANSI C/libc functions. All modules must NOT include any system include files, or the following: "xf86Priv.h" "xf86Privstr.h" "xf86_libc.h" "xf86_OSlib.h" "Xos.h" or any other include files with ``priv'' in their name. 12. Offscreen Memory Manager Management of offscreen video memory may be handled by the XFree86 frame- buffer manager. Once the offscreen memory manager is running, drivers or extensions may allocate, free or resize areas of offscreen video memory using the following functions (definitions taken from xf86fbman.h): typedef struct _FBArea { ScreenPtr pScreen; BoxRec box; int granularity; void (*MoveAreaCallback)(struct _FBArea*, struct _FBArea*) void (*RemoveAreaCallback)(struct _FBArea*) DevUnion devPrivate; } FBArea, *FBAreaPtr; typedef void (*MoveAreaCallbackProcPtr)(FBAreaPtr from, FBAreaPtr to) typedef void (*RemoveAreaCallbackProcPtr)(FBAreaPtr) FBAreaPtr xf86AllocateOffscreenArea ( ScreenPtr pScreen, int width, int height, int granularity, MoveAreaCallbackProcPtr MoveAreaCallback, RemoveAreaCallbackProcPtr RemoveAreaCallback, pointer privData ) void xf86FreeOffscreenArea (FBAreaPtr area) Bool xf86ResizeOffscreenArea ( FBAreaPtr area int w, int h ) The function: Bool xf86FBManagerRunning(ScreenPtr pScreen) can be used by an extension to check if the driver has initialized the memory manager. The manager is not available if this returns FALSE and the func- tions above will all fail. xf86AllocateOffscreenArea() can be used to request a rectangle of dimensions width x height (in pixels) from unused offscreen memory. granularity speci- fies that the leftmost edge of the rectangle must lie on some multiple of granularity pixels. A granularity of zero means the same thing as a granu- larity of one - no alignment preference. A MoveAreaCallback can be provided to notify the requester when the offscreen area is moved. If no MoveArea- Callback is supplied then the area is considered to be immovable. The priv- Data field will be stored in the manager's internal structure for that allo- cated area and will be returned to the requester in the FBArea passed via the MoveAreaCallback. An optional RemoveAreaCallback is provided. If the driver provides this it indicates that the area should be allocated with a lower priority. Such an area may be removed when a higher priority request (one that doesn't have a RemoveAreaCallback) is made. When this function is called, the driver will have an opportunity to do whatever cleanup it needs to do to deal with the loss of the area, but it must finish its cleanup before the function exits since the offscreen memory manager will free the area immediately after. xf86AllocateOffscreenArea() returns NULL if it was unable to allocate the requested area. When no longer needed, areas should be freed with xf86Free- OffscreenArea(). xf86ResizeOffscreenArea() resizes an existing FBArea. xf86ResizeOff- screenArea() returns TRUE if the resize was successful. If xf86ResizeOff- screenArea() returns FALSE, the original FBArea is left unmodified. Resizing an area maintains the area's original granularity, devPrivate, and MoveArea- Callback. xf86ResizeOffscreenArea() has considerably less overhead than freeing the old area then reallocating the new size, so it should be used whenever possible. The function: Bool xf86QueryLargestOffscreenArea( ScreenPtr pScreen, int *width, int *height, int granularity, int preferences, int priority ) is provided to query the width and height of the largest single FBArea allo- catable given a particular priority. preferences can be one of the following to indicate whether width, height or area should be considered when determin- ing which is the largest single FBArea available. FAVOR_AREA_THEN_WIDTH FAVOR_AREA_THEN_HEIGHT FAVOR_WIDTH_THEN_AREA FAVOR_HEIGHT_THEN_AREA priority is one of the following: PRIORITY_LOW Return the largest block available without stealing any- one else's space. This corresponds to the priority of allocating a FBArea when a RemoveAreaCallback is pro- vided. PRIORITY_NORMAL Return the largest block available if it is acceptable to steal a lower priority area from someone. This corre- sponds to the priority of allocating a FBArea without providing a RemoveAreaCallback. PRIORITY_EXTREME Return the largest block available if all FBAreas that aren't locked down were expunged from memory first. This corresponds to any allocation made directly after a call to xf86PurgeUnlockedOffscreenAreas(). The function: Bool xf86PurgeUnlockedOffscreenAreas(ScreenPtr pScreen) is provided as an extreme method to free up offscreen memory. This will remove all removable FBArea allocations. Initialization of the XFree86 framebuffer manager is done via Bool xf86InitFBManager(ScreenPtr pScreen, BoxPtr FullBox) FullBox represents the area of the framebuffer that the manager is allowed to manage. This is typically a box with a width of pScrn->displayWidth and a height of as many lines as can be fit within the total video memory, however, the driver can reserve areas at the extremities by passing a smaller area to the manager. xf86InitFBManager() must be called before XAA is initialized since XAA uses the manager for it's pixmap cache. An alternative function is provided to allow the driver to initialize the framebuffer manager with a Region rather than a box. Bool xf86InitFBManagerRegion(ScreenPtr pScreen, RegionPtr FullRegion) xf86InitFBManagerRegion(), unlike xf86InitFBManager(), does not remove the area used for the visible screen so that area should not be included in the region passed to the function. xf86InitFBManagerRegion() is useful when non- contiguous areas are available to be managed, and is required when multiple framebuffers are stored in video memory (as in the case where an overlay of a different depth is stored as a second framebuffer in offscreen memory). 13. Colormap Handling A generic colormap handling layer is provided within the XFree86 common layer. This layer takes care of most of the details, and only requires a function from the driver that loads the hardware palette when required. To use the colormap layer, a driver calls the xf86HandleColormaps() function. Bool xf86HandleColormaps(ScreenPtr pScreen, int maxColors, int sigRGBbits, LoadPaletteFuncPtr loadPalette, SetOverscanFuncPtr setOverscan, unsigned int flags) This function must be called after the default colormap has been initialised. The pScrn->gamma field must also be initialised, preferably by calling xf86SetGamma(). maxColors is the number of entries in the palette. sigRGBbits is the number of significant bits in each colour component. This would normally be the same as pScrn->rgbBits. loadPalette is a driver-provided func- tion for loading a colormap into the hardware, and is described below. setOverscan is an optional function that may be provided when the overscan color is an index from the standard LUT and when it needs to be adjusted to keep it as close to black as possible. The setOverscan function programs the overscan index. It shouldn't nor- mally be used for depths other than 8. setOverscan should be set to NULL when it isn't needed. flags may be set to the following (which may be ORed together): CMAP_PALETTED_TRUECOLOR the TrueColor visual is paletted and is just a special case of DirectColor. This flag is only valid for bpp > 8. CMAP_RELOAD_ON_MODE_SWITCH reload the colormap automatically after mode switches. This is useful for when the driver is resetting the hardware during mode switches and corrupting or erasing the hardware palette. The colormap layer always reloads the palette after VT enters so it is not necessary for the driver to save and restore the palette when switching VTs. The driver must, however, still save the initial palette during server start up and restore it during server exit. void LoadPalette(ScrnInfoPtr pScrn, int numColors, int *indices, LOCO *colors, VisualPtr pVisual) LoadPalette() is a driver-provide function for loading a colormap into hardware. colors is the array of RGB val- ues that represent the full colormap. indices is a list of index values into the colors array. These indices indicate the entries that need to be updated. numColors is the number of the indices to be updated. void SetOverscan(ScrnInfoPtr pScrn, int overscan) SetOverscan() is a driver-provided function for program- ming the overscan index. As described above, it is nor- mally only appropriate for LUT modes where all colormap entries are available for the display, but where one of them is also used for the overscan (typically 8bpp for VGA compatible LUTs). It isn't required in cases where the overscan area is never visible. 14. DPMS Extension Support code for the DPMS extension is included in the XFree86 common layer. This code provides an interface between the main extension code, and a means for drivers to initialise DPMS when they support it. One function is avail- able to drivers to do this initialisation, and it is always available, even when the DPMS extension is not supported by the core server (in which case it returns a failure result). Bool xf86DPMSInit(ScreenPtr pScreen, DPMSSetProcPtr set, int flags) This function registers a driver's DPMS level programming function set. It also checks pScrn->options for the "dpms" option, and when present marks DPMS as being enabled for that screen. The set function is called whenever the DPMS level changes, and is used to program the requested level. flags is currently not used, and should be 0. If the initialisation fails for any reason, including when there is no DPMS support in the core server, the function returns FALSE. Drivers that implement DPMS support must provide the following function, that gets called when the DPMS level is changed: void ChipDPMSSet(ScrnInfoPtr pScrn, int level, int flags) Program the DPMS level specified by level. Valid values of level are DPMSModeOn, DPMSModeStandby, DPMSModeSus- pend, DPMSModeOff. These values are defined in "exten- sions/dpms.h". 15. DGA Extension Drivers can support the XFree86 Direct Graphics Architecture (DGA) by filling out a structure of function pointers and a list of modes and passing them to DGAInit. Bool DGAInit(ScreenPtr pScreen, DGAFunctionPtr funcs, DGAModePtr modes, int num) /** The DGAModeRec **/ typedef struct { int num; DisplayModePtr mode; int flags; int imageWidth; int imageHeight; int pixmapWidth; int pixmapHeight; int bytesPerScanline; int byteOrder; int depth; int bitsPerPixel; unsigned long red_mask; unsigned long green_mask; unsigned long blue_mask; int viewportWidth; int viewportHeight; int xViewportStep; int yViewportStep; int maxViewportX; int maxViewportY; int viewportFlags; int offset; unsigned char *address; int reserved1; int reserved2; } DGAModeRec, *DGAModePtr; num Can be ignored. The DGA DDX will assign these numbers. mode A pointer to the DisplayModeRec for this mode. flags The following flags are defined and may be OR'd together: DGA_CONCURRENT_ACCESS Indicates that the driver supports concurrent graphics accelerator and linear framebuffer access. DGA_FILL_RECT DGA_BLIT_RECT DGA_BLIT_RECT_TRANS Indicates that the driver supports the FillRect, BlitRect or BlitTran- sRect functions in this mode. DGA_PIXMAP_AVAILABLE Indicates that Xlib may be used on the framebuffer. This flag will usu- ally be set unless the driver wishes to prohibit this for some reason. DGA_INTERLACED DGA_DOUBLESCAN Indicates that these are interlaced or double scan modes. imageWidth imageHeight These are the dimensions of the linear frame- buffer accessible by the client. pixmapWidth pixmapHeight These are the dimensions of the area of the framebuffer accessible by the graphics acceler- ator. bytesPerScanline Pitch of the framebuffer in bytes. byteOrder Usually the same as pScrn->imageByteOrder. depth The depth of the framebuffer in this mode. bitsPerPixel The number of bits per pixel in this mode. red_mask green_mask blue_mask The RGB masks for this mode, if applicable. viewportWidth viewportHeight Dimensions of the visible part of the frame- buffer. Usually mode->HDisplay and mode->VDis- play. xViewportStep yViewportStep The granularity of x and y viewport positions that the driver supports in this mode. maxViewportX maxViewportY The maximum viewport position supported by the driver in this mode. viewportFlags The following may be OR'd together: DGA_FLIP_IMMEDIATE The driver supports immediate view- port changes. DGA_FLIP_RETRACE The driver supports viewport changes at retrace. offset The offset into the linear framebuffer that corresponds to pixel (0,0) for this mode. /** The DGAFunctionRec **/ typedef struct { Bool (*OpenFramebuffer)( ScrnInfoPtr pScrn, char **name, unsigned char **mem, int *size, int *offset, int *extra ); void (*CloseFramebuffer)(ScrnInfoPtr pScrn); Bool (*SetMode)(ScrnInfoPtr pScrn, DGAModePtr pMode); void (*SetViewport)(ScrnInfoPtr pScrn, int x, int y, int flags); int (*GetViewport)(ScrnInfoPtr pScrn); void (*Flush)(ScrnInfoPtr); void (*FillRect)( ScrnInfoPtr pScrn, int x, int y, int w, int h, unsigned long color ); void (*BlitRect)( ScrnInfoPtr pScrn, int srcx, int srcy, int w, int h, int dstx, int dsty ); void (*BlitTransRect)( ScrnInfoPtr pScrn, int srcx, int srcy, int w, int h, int dstx, int dsty, unsigned long color ); } DGAFunctionRec, *DGAFunctionPtr; Bool OpenFramebuffer (pScrn, name, mem, size, offset, extra) OpenFramebuffer() should pass the client everything it needs to know to be able to open the framebuffer. These parameters are OS specific and their meanings are to be interpreted by an OS specific client library. name The name of the device to open or NULL if there is no special device to open. A NULL name tells the client that it should open whatever device one would usually open to access physi- cal memory. mem The physical address of the start of the frame- buffer. size The size of the framebuffer in bytes. offset Any offset into the device, if applicable. flags Any additional information that the client may need. Currently, only the DGA_NEED_ROOT flag is defined. void CloseFramebuffer (pScrn) CloseFramebuffer() merely informs the driver (if it even cares) that client no longer needs to access the frame- buffer directly. This function is optional. Bool SetMode (pScrn, pMode) SetMode() tells the driver to initialize the mode passed to it. If pMode is NULL, then the driver should restore the original pre-DGA mode. void SetViewport (pScrn, x, y, flags) SetViewport() tells the driver to make the upper left- hand corner of the visible screen correspond to coordi- nate (x,y) on the framebuffer. Flags currently defined are: DGA_FLIP_IMMEDIATE The viewport change should occur immediately. DGA_FLIP_RETRACE The viewport change should occur at the verti- cal retrace, but this function should return sooner if possible. The (x,y) locations will be passed as the client speci- fied them, however, the driver is expected to round these locations down to the next supported location as speci- fied by the xViewportStep and yViewportStep for the cur- rent mode. int GetViewport (pScrn) GetViewport() gets the current page flip status. Set bits in the returned int correspond to viewport change requests still pending. For instance, set bit zero if the last SetViewport request is still pending, bit one if the one before that is still pending, etc. void Flush (pScrn) This function should ensure that any graphics accelerator operations have finished. This function should not return until the graphics accelerator is idle. void FillRect (pScrn, x, y, w, h, color) This optional function should fill a rectangle w ? h located at (x,y) in the given color. void BlitRect (pScrn, srcx, srcy, w, h, dstx, dsty) This optional function should copy an area w ? h located at (srcx,srcy) to location (dstx,dsty). This function will need to handle copy directions as appropriate. void BlitTransRect (pScrn, srcx, srcy, w, h, dstx, dsty, color) This optional function is the same as BlitRect except that pixels in the source corresponding to the color key color should be skipped. 16. The XFree86 X Video Extension (Xv) Device Dependent Layer XFree86 offers the X Video Extension which allows clients to treat video as any another primitive and ``Put'' video into drawables. By default, the extension reports no video adaptors as being available since the DDX layer has not been initialized. The driver can initialize the DDX layer by filling out one or more XF86VideoAdaptorRecs as described later in this document and passing a list of XF86VideoAdaptorPtr pointers to the following function: Bool xf86XVScreenInit( ScreenPtr pScreen, XF86VideoAdaptorPtr *adaptPtrs, int num) After doing this, the extension will report video adaptors as being avail- able, providing the data in their respective XF86VideoAdaptorRecs was valid. xf86XVScreenInit() copies data from the structure passed to it so the driver may free it after the initialization. At the moment, the DDX only supports rendering into Window drawables. Pixmap rendering will be supported after a sufficient survey of suitable hardware is completed. The XF86VideoAdaptorRec: typedef struct { unsigned char type; int flags; char *name; int nEncodings; XF86VideoEncodingPtr pEncodings; int nFormats; XF86VideoFormatPtr pFormats; int nPorts; XF86AttributeListPtr pAttributes; DevUnion *pPortPrivates; PutVideoFuncPtr PutVideo; PutStillFuncPtr PutStill; GetVideoFuncPtr GetVideo; GetStillFuncPtr GetStill; StopVideoFuncPtr StopVideo; SetPortAttributeFuncPtr SetPortAttribute; GetPortAttributeFuncPtr GetPortAttribute; QueryBestSizeFuncPtr QueryBestSize; } XF86VideoAdaptorRec, *XF86VideoAdaptorPtr; Each adaptor will have its own XF86VideoAdaptorRec. The fields are as follows: type This can be XvInputMask, XvOutputMask or both OR'd together. This refers to the target drawable and is sim- ilar to a Window's class. XvInputMask indicates that the adaptor can put video into a drawable. XvOutputMask indicates that the adaptor can get video from a drawable. flags Currently, the following flags are defined: VIDEO_NO_CLIPPING This indicates that the video adaptor does not support clipping. The driver will never receive Get/Put requests where less than the entire area determined by drw_x, drw_y, drw_w and drw_h is visible. VIDEO_INVERT_CLIPLIST This indicates that the video driver requires the clip list to contain the regions which are obscured rather than the regions which are are visible. VIDEO_EXPOSE This flag applies to GetStill and GetVideo only, it indicates the clip list shall contain obscured regions. Note the source region will still be clipped against the screen bounds. This flag is meant for showing all the contents of the [root] window, if the administrator has no hesitations regarding security. name The name of the adaptor. nEncodings pEncodings The number of encodings the adaptor is capable of and pointer to the XF86VideoEncodingRec array. The XF86VideoEncodingRec is described later on. nFormats pFormats The number of formats the adaptor is capable of and pointer to the XF86VideoFormatRec array. The XF86Video- FormatRec is described later on. nPorts pPortPrivates The number of ports is the number of separate data streams which the adaptor can handle simultaneously. If you have more than one port, the adaptor is expected to be able to render into more than one window at a time. pPortPrivates is an array of pointers or ints - one for each port. A port's private data will be passed to the driver any time the port is requested to do something like put the video or stop the video. In the case where there may be many ports, this enables the driver to know which port the request is intended for. Most commonly, this will contain a pointer to the data structure con- taining information about the port. pAttributes There is an array of XF86AttributeListRecs with an entry for each port. PutVideo PutStill GetVideo GetStill StopVideo SetPortAttribute Get- PortAttribute QueryBestSize These functions define the DDX->driver interface. In each case, the pointer data is passed to the driver. This is the port private for that port as described above. All fields are required except under the follow- ing conditions: 1. PutVideo and PutStill are not required when the adaptor type does not contain XvInputMask. 2. GetVideo and GetStill are not required when the adaptor type does not contain XvOutputMask. These functions should return Success if the operation was completed successfully. They can return XvBadAlloc otherwise. Xv DDX will not call a Get/Put function while video is active, rather issue a StopVideo call first. Earlier versions of Xv DDX had a ReclipVideo function, obsolete now. The clip region will be passed directly by the functions below. If the VIDEO_NO_CLIPPING flag is set, the RegionPtr should be ignored by the driver. ClipBoxes is an X-Y banded region identical to those used throughout the server. The clipBoxes represent the visi- ble portions of area determined by drw_x, drw_y, drw_w and drw_h in the Get/Put function. The boxes are in screen coordinates, are guaranteed not to overlap and an empty region will be passed only to GetVideo, once. This to notify the driver the primitive is totally obscured now. A StopVideo call will immediately follow neverthe- less. In the case where the VIDEO_INVERT_CLIPLIST flag is set, clipBoxes will indicate the areas of the primi- tive which are obscured rather than the areas visible. The Region must not be altered by the driver and will be deleted when the function returns. typedef int (* PutVideoFuncPtr)( ScrnInfoPtr pScrn, short vid_x, short vid_y, short drw_x, short drw_y, short vid_w, short vid_h, short drw_w, short drw_h, RegionPtr clipBoxes, pointer data ) This indicates that the driver should take a subsection vid_w ? vid_h at location (vid_x,vid_y) from the video stream and direct it into the rectangle rw_w ? drw_h at location (drw_x,drw_y) on the screen, scaling as neces- sary. Due to the large variations in capabilities of the various hardware expected to be used with this extension, it is not expected that all hardware will be able to do this exactly as described. In that case the driver should just do ``the best it can,'' scaling as closely to the target rectangle as it can without rendering outside of it. In the worst case, the driver can opt to just not turn on the video. typedef int (* PutStillFuncPtr)( ScrnInfoPtr pScrn, short vid_x, short vid_y, short drw_x, short drw_y, short vid_w, short vid_h, short drw_w, short drw_h, RegionPtr clipBoxes, pointer data ) This is same as PutVideo except that the driver should place only one frame from the stream on the screen. typedef int (* GetVideoFuncPtr)( ScrnInfoPtr pScrn, short vid_x, short vid_y, short drw_x, short drw_y, short vid_w, short vid_h, short drw_w, short drw_h, RegionPtr clipBoxes, pointer data ) This is same as PutVideo except that the driver gets video from the screen and outputs it. The driver should do the best it can to get the requested dimensions cor- rect without reading from an area larger than requested. typedef int (* GetStillFuncPtr)( ScrnInfoPtr pScrn, short vid_x, short vid_y, short drw_x, short drw_y, short vid_w, short vid_h, short drw_w, short drw_h, RegionPtr clipBoxes, pointer data ) This is the same as GetVideo except that the driver should place only one frame from the screen into the out- put stream. typedef void (* StopVideoFuncPtr)(ScrnInfoPtr pScrn, pointer data, Bool cleanup) This indicates the the driver should stop displaying the video. This is used to stop both input and output video. The cleanup field indicates that the video is being stopped because the client requested it to stop or because the server is exiting the current VT. In that case the driver should deallocate any offscreen memory areas (if there are any) being used to put the video to the screen. If cleanup is not set, the video is being stopped temporarily due to clipping or moving of the win- dow, etc... and video will likely be restarted soon so the driver should not deallocate any offscreen areas associated with that port. typedef int (* SetPortAttributeFuncPtr)(ScrnInfoPtr pScrn, Atom attribute,INT32 value, pointer data) typedef int (* GetPortAttributeFuncPtr)(ScrnInfoPtr pScrn, Atom attribute,INT32 *value, pointer data) A port may have particular attributes such as hue, satu- ration, brightness or contrast. Xv clients set and get these attribute values by sending attribute strings (Atoms) to the server. Such requests end up at these driver functions. It is recommended that the driver pro- vide at least the following attributes mentioned in the Xv client library docs: XV_ENCODING XV_HUE XV_SATURATION XV_BRIGHTNESS XV_CONTRAST but the driver may recognize as many atoms as it wishes. If a requested attribute is unknown by the driver it should return BadMatch. XV_ENCODING is the attribute intended to let the client specify which video encoding the particular port should be using (see the description of XF86VideoEncodingRec below). If the requested encod- ing is unsupported, the driver should return XvBadEncod- ing. Success should be returned otherwise. typedef void (* QueryBestSizeFuncPtr)(ScrnInfoPtr pScrn, Bool motion, short vid_w, short vid_h, short drw_w, short drw_h, unsigned int *p_w, unsigned int *p_h, pointer data) QueryBestSize provides the client with a way to query what the destination dimensions would end up being if they were to request that an area vid_w ? vid_h from the video stream be scaled to rectangle of drw_w ? drw_h on the screen. Since it is not expected that all hardware will be able to get the target dimensions exactly, it is important that the driver provide this function. The returned dimensions must be less than or equal to the requested dimension. The XF86VideoEncodingRec: typedef struct { int id; char *name; unsigned short width, height; XvRationalRec rate; } XF86VideoEncodingRec, *XF86VideoEncodingPtr; The XF86VideoEncodingRec specifies what encodings the adaptor can support. Most of this data is just informational and for the client's benefit, and is what will be reported by XvQueryEncodings. The id field is expected to be a unique identifier to allow the client to request a certain encoding via the XV_ENCODING attribute string. The XF86VideoFormatRec: typedef struct { char depth; short class; } XF86VideoFormatRec, *XF86VideoFormatPtr; This specifies what visuals the video is viewable in. depth is the depth of the visual (not bpp). class is the visual class such as TrueColor, DirectColor or PseudoColor. Initialization of an adap- tor will fail if none of the visuals on that screen are supported. The XF86AttributeListRec: typedef struct { int number; int *flags; char **names; } XF86AttributeListRec, *XF86AttributeListPtr; Each port will have one of these indicating the number of attributes for that port, an array of names of the attributes and an array of flags associated with each attribute. Both arrays are number in size. Currently defined flags are XvGettable and XvSet- table which may be OR'd together indicating that attribute is ``gettable'' or ``settable'' by the client. Both arrays can be nulled if number is zero. While the Xv DDX copies most data from these structures and stores it internally, including adaptor and encoding names, the attribute names are not copied, but only their pointers. Because of this, the strings pointed to by names[] must exist as long as Xv is initialized. 17. The Loader This section describes the interfaces to the module loader. The loader interfaces can be divided into two groups: those that are only available to the XFree86 common layer, and those that are also available to modules. 17.1 Loader Overview The loader is capable of loading modules in a range of object formats, and knowledge of these formats is built in to the loader. Knowledge of new object formats can be added to the loader in a straightforward manner. This makes it possible to provide OS-independent modules (for a given CPU archi- tecture type). In addition to this, the loader can load modules via the OS- provided dlopen(3) service where available. Such modules are not platform independent, and the semantics of dlopen() on most systems results in signif- icant limitations in the use of modules of this type. Support for dlopen() modules in the loader is primarily for experimental and development purposes. Symbols exported by the loader (on behalf of the core X server) to modules are determined at compile time. Only those symbols explicitly exported are available to modules. All external symbols of loaded modules are exported to other modules, and to the core X server. The loader can be requested to check for unresolved symbols at any time, and the action to be taken for unresolved symbols can be controlled by the caller of the loader. Typically the caller identifies which symbols can safely remain unresolved and which cannot. 17.2 Semi-private Loader Interface The following is the semi-private loader interface that is available to the XFree86 common layer. void LoaderInit(void) The LoaderInit() function initialises the loader, and it must be called once before calling any other loader func- tions. This function initialises the tables of exported symbols, and anything else that might need to be ini- tialised. void LoaderSetPath(const char *path) The LoaderSetPath() function initialises a default module search path. This must be called if calls to other func- tions are to be made without explicitly specifying a mod- ule search path. The search path path must be a string of one or more comma separated absolute paths. Modules are expected to be located below these paths, possibly in subdirectories of these paths. pointer LoadModule(const char *module, const char *path, const char **subdirlist, const char **patternlist, pointer options, const XF86ModReqInfo * modreq, int *errmaj, int *errmin) The LoadModule() function loads the module called module. The return value is a module handle, and may be used in future calls to the loader that require a reference to a loaded module. The module name module is normally the module's canonical name, which doesn't contain any direc- tory path information, or any object/library file pre- fixes of suffixes. Currently a full pathname and/or filename is also accepted. This might change. The other parameters are: path An optional comma-separated list of module search paths. When NULL, the default search path is used. subdirlist An optional NULL terminated list of subdirecto- ries to search. When NULL, the default built- in list is used (refer to stdSubdirs in load- mod.c). The default list is also substituted for entries in subdirlist with the value DEFAULT_LIST. This makes is possible to aug- ment the default list instead of replacing it. Subdir elements must be relative, and must not contain "..". If any violate this requirement, the load fails. patternlist An optional NULL terminated list of POSIX regu- lar expressions used to connect module file- names with canonical module names. Each regex should contain exactly one subexpression that corresponds to the canonical module name. When NULL, the default built-in list is used (refer to stdPatterns in loadmod.c). The default list is also substituted for entries in patternlist with the value DEFAULT_LIST. This makes it possible to augment the default list instead of replacing it. options An optional parameter that is passed to the newly loaded module's SetupProc function (if it has one). This argument is normally a NULL terminated list of Options, and must be inter- preted that way by modules loaded directly by the XFree86 common layer. However, it may be used for application-specific parameter passing in other situations. When loading ``external'' modules (modules that don't have the the standard entry point, for example a special shared library) the options parameter can be set to EXTERN_MODULE to tell the loader not to reject the module when it doesn't find the standard entry point. modreq An optional XF86ModReqInfo* containing ver- sion/ABI/vendor information to requirements to check the newly loaded module against. The main purpose of this is to allow the loader to verify that a module of the correct type/ver- sion before running its SetupProc function. The XF86ModReqInfo struct is defined as fol- lows: typedef struct { CARD8 majorversion; /* MAJOR_UNSPEC */ CARD8 minorversion; /* MINOR_UNSPEC */ CARD16 patchlevel; /* PATCH_UNSPEC */ const char * abiclass; /* ABI_CLASS_NONE */ CARD32 abiversion; /* ABI_VERS_UNSPEC */ const char * moduleclass; /* MOD_CLASS_NONE */ } XF86ModReqInfo; The information here is compared against the equivalent information in the module's XF86Mod- uleVersionInfo record (which is described below). The values in comments above indicate ``don't care'' settings for each of the fields. The comparisons made are as follows: majorversion Must match the module's majorversion exactly. minorversion The module's minor version must be no less than this value. This compari- son is only made if majorversion is specified and matches. patchlevel The module's patchlevel must be no less than this value. This compari- son is only made if minorversion is specified and matches. abiclass String must match the module's abi- class string. abiversion Must be consistent with the module's abiversion (major equal, minor no older). moduleclass String must match the module's mod- uleclass string. errmaj An optional pointer to a variable holding the major part or the error code. When provided, it *errmaj is filled in when LoadModule() fails. errmin Like errmaj, but for the minor part of the error code. void UnloadModule(pointer mod) This function unloads the module referred to by the han- dle mod. All child modules are also unloaded recur- sively. This function must not be used to directly unload modules that are child modules (i.e., those that have been loaded with LoadSubModule()). 17.3 Module Requirements Modules must provide information about themselves to the loader, and may optionally provide entry points for "setup" and "teardown" functions (those two functions are referred to here as SetupProc and TearDownProc). The module information is contained in the XF86ModuleVersionInfo struct, which is defined as follows: typedef struct { const char * modname; /* name of module, e.g. "foo" */ const char * vendor; /* vendor specific string */ CARD32 _modinfo1_; /* constant MODINFOSTRING1/2 to find */ CARD32 _modinfo2_; /* infoarea with a binary editor/sign tool */ CARD32 xf86version; /* contains XF86_VERSION_CURRENT */ CARD8 majorversion; /* module-specific major version */ CARD8 minorversion; /* module-specific minor version */ CARD16 patchlevel; /* module-specific patch level */ const char * abiclass; /* ABI class that the module uses */ CARD32 abiversion; /* ABI version */ const char * moduleclass; /* module class */ CARD32 checksum[4]; /* contains a digital signature of the */ /* version info structure */ } XF86ModuleVersionInfo; The fields are used as follows: modname The module's name. This field is currently only for informational purposes, but the loader may be modified in future to require it to match the module's canonical name. vendor The module vendor. This field is for informational pur- poses only. _modinfo1_ This field holds the first part of a signature that can be used to locate this structure in the binary. It should always be initialised to MODINFOSTRING1. _modinfo2_ This field holds the second part of a signature that can be used to locate this structure in the binary. It should always be initialised to MODINFOSTRING2. xf86version The XFree86 version against which the module was com- piled. This is mostly for informational/diagnostic pur- poses. It should be initialised to XF86_VERSION_CURRENT, which is defined in xf86Version.h. majorversion The module-specific major version. For modules where this version is used for more than simply informational purposes, the major version should only change (be incre- mented) when ABI incompatibilities are introduced, or ABI components are removed. minorversion The module-specific minor version. For modules where this version is used for more than simply informational purposes, the minor version should only change (be incre- mented) when ABI additions are made in a backward compat- ible way. It should be reset to zero when the major ver- sion is increased. patchlevel The module-specific patch level. The patch level should increase with new revisions of the module where there are no ABI changes, and it should be reset to zero when the minor version is increased. abiclass The ABI class that the module requires. The class is specified as a string for easy extensibility. It should indicate which (if any) of the X server's built-in ABI classes that the module relies on, or a third-party ABI if appropriate. Built-in ABI classes currently defined are: ABI_CLASS_NONE no class ABI_CLASS_ANSIC only requires the ANSI C interfaces ABI_CLASS_VIDEODRV requires the video driver ABI ABI_CLASS_XINPUT requires the XInput driver ABI ABI_CLASS_EXTENSION requires the extension module ABI ABI_CLASS_FONT requires the font module ABI abiversion The version of abiclass that the module requires. The version consists of major and minor components. The major version must match and the minor version must be no newer than that provided by the server or parent module. Version identifiers for the built-in classes currently defined are: ABI_ANSIC_VERSION ABI_VIDEODRV_VERSION ABI_XINPUT_VERSION ABI_EXTENSION_VERSION ABI_FONT_VERSION moduleclass This is similar to the abiclass field, except that it defines the type of module rather than the ABI it requires. For example, although all video drivers require the video driver ABI, not all modules that require the video driver ABI are video drivers. This distinction can be made with the moduleclass. Currently pre-defined module classes are: MOD_CLASS_NONE MOD_CLASS_VIDEODRV MOD_CLASS_XINPUT MOD_CLASS_FONT MOD_CLASS_EXTENSION checksum Not currently used. The module version information, and the optional SetupProc and TearDownProc entry points are found by the loader by locating a data object in the module called "modnameModuleData", where "modname" is the canonical name of the mod- ule. Modules must contain such a data object, and it must be declared with global scope, be compile-time initialised, and is of the following type: typedef struct { XF86ModuleVersionInfo * vers; ModuleSetupProc setup; ModuleTearDownProc teardown; } XF86ModuleData; The vers parameter must be initialised to a pointer to a correctly ini- tialised XF86ModuleVersionInfo struct. The other two parameter are optional, and should be initialised to NULL when not required. The other parameters are defined as typedef pointer (*ModuleSetupProc)(pointer, pointer, int *, int *) typedef void (*ModuleTearDownProc)(pointer) pointer SetupProc(pointer module, pointer options, int *errmaj, int *errmin) When defined, this function is called by the loader after successfully loading a module. module is a handle for the newly loaded module, and maybe used by the SetupProc if it calls other loader functions that require a refer- ence to it. The remaining arguments are those that were passed to the LoadModule() (or LoadSubModule()), and are described above. When the SetupProc is successful it must return a non-NULL value. The loader checks this, and if it is NULL it unloads the module and reports the failure to the caller of LoadModule(). If the SetupProc does things that need to be undone when the module is unloaded, it should define a TearDownProc, and return a pointer that the TearDownProc can use to undo what has been done. When a module is loaded multiple times, the SetupProc is called once for each time it is loaded. void TearDownProc(pointer tearDownData) When defined, this function is called when the loader unloads a module. The tearDownData parameter is the return value of the SetupProc() that was called when the module was loaded. The purpose of this function is to clean up before the module is unloaded (for example, by freeing allocated resources). 17.4 Public Loader Interface The following is the Loader interface that is available to any part of the server, and may also be used from within modules. pointer LoadSubModule(pointer parent, const char *module, const char **subdirlist, const char **patternlist, pointer options, const XF86ModReqInfo * modreq, int *errmaj, int *errmin) This function is like the LoadModule() function described above, except that the module loaded is registered as a child of the calling module. The parent parameter is the calling module's handle. Modules loaded with this func- tion are automatically unloaded when the parent module is unloaded. The other difference is that the path parame- ter may not be specified. The module search path used for modules loaded with this function is the default search path as initialised with LoaderSetPath(). void UnloadSubModule(pointer module) This function unloads the module with handle module. If that module itself has children, they are also unloaded. It is like LoadModule(), except that it is safe to use for unloading child modules. pointer LoaderSymbol(const char *symbol) This function returns the address of the symbol with name symbol. This may be used to locate a module entry point with a known name. char **LoaderlistDirs(const char **subdirlist, const char **patternlist) This function returns a NULL terminated list of canonical modules names for modules found in the default module search path. The subdirlist and patternlist parameters are as described above, and can be used to control the locations and names that are searched. If no modules are found, the return value is NULL. The returned list should be freed by calling LoaderFreeDirList() when it is no longer needed. void LoaderFreeDirList(char **list) This function frees a module list created by Loaderlist- Dirs(). void LoaderReqSymLists(const char **list0, ...) This function allows the registration of required symbols with the loader. It is normally used by a caller of LoadSubModule(). If any symbols registered in this way are found to be unresolved when LoaderCheckUnresolved() is called then LoaderCheckUnresolved() will report a failure. The function takes one or more NULL terminated lists of symbols. The end of the argument list is indi- cated by a NULL argument. void LoaderReqSymbols(const char *sym0, ...) This function is like LoaderReqSymLists() except that its arguments are symbols rather than lists of symbols. This function is more convenient when single functions are to be registered, especially when the single function might depend on runtime factors. The end of the argument list is indicated by a NULL argument. void LoaderRefSymLists(const char **list0, ...) This function allows the registration of possibly unre- solved symbols with the loader. When LoaderCheckUnre- solved() is run it won't generate warnings for symbols registered in this way unless they were also registered as required symbols. void LoaderRefSymbols(const char *sym0, ...) This function is like LoaderRefSymLists() except that its arguments are symbols rather than lists of symbols. This function is more convenient when single functions are to be registered, especially when the single function might depend on runtime factors. The end of the argument list is indicated by a NULL argument. int LoaderCheckUnresolved(int delayflag) This function checks for unresolved symbols. It gener- ates warnings for unresolved symbols that have not been registered with LoaderRefSymLists(), and maps them to a dummy function. This behaviour may change in future. If unresolved symbols are found that have been registered with LoaderReqSymLists() or LoaderReqSymbols() then this function returns a non-zero value. If none of these sym- bols are unresolved the return value is zero, indicating success. The delayflag parameter should normally be set to LD_RESOLV_IFDONE. LoaderErrorMsg(const char *name, const char *modname, int errmaj, int errmin) This function prints an error message that includes the text ``Failed to load module'', the module name modname, a message specific to the errmaj value, and the value if errmin. If name is non-NULL, it is printed as an identi- fying prefix to the message (followed by a `:'). 17.5 Special Registration Functions The loader contains some functions for registering some classes of modules. These may be moved out of the loader at some point. void LoadExtension(ExtensionModule *ext) This registers the entry points for the extension identi- fied by ext. The ExtensionModule struct is defined as: typedef struct { InitExtension initFunc; char * name; Bool *disablePtr; InitExtension setupFunc; } ExtensionModule; void LoadFont(FontModule *font) This registers the entry points for the font rasteriser module identified by font. The FontModule struct is defined as: typedef struct { InitFont initFunc; char * name; pointer module; } FontModule; 18. Helper Functions This section describe ``helper'' functions that video driver might find use- ful. While video drivers are not required to use any of these to be consid- ered ``compliant'', the use of appropriate helpers is strongly encouraged to improve the consistency of driver behaviour. 18.1 Functions for printing messages ErrorF(const char *format, ...) This is the basic function for writing to the error log (typically stderr and/or a log file). Video drivers should usually avoid using this directly in favour of the more specialised functions described below. This func- tion is useful for printing messages while debugging a driver. FatalError(const char *format, ...) This prints a message and causes the Xserver to abort. It should rarely be used within a video driver, as most error conditions should be flagged by the return values of the driver functions. This allows the higher layers to decide how to proceed. In rare cases, this can be used within a driver if a fatal unexpected condition is found. xf86ErrorF(const char *format, ...) This is like ErrorF(), except that the message is only printed when the Xserver's verbosity level is set to the default (1) or higher. It means that the messages are not printed when the server is started with the -quiet flag. Typically this function would only be used for continuing messages started with one of the more spe- cialised functions described below. xf86ErrorFVerb(int verb, const char *format, ...) Like xf86ErrorF(), except the minimum verbosity level for which the message is to be printed is given explicitly. Passing a verb value of zero means the message is always printed. A value higher than 1 can be used for informa- tion would normally not be needed, but which might be useful when diagnosing problems. xf86Msg(MessageType type, const char *format, ...) This is like xf86ErrorF(), except that the message is prefixed with a marker determined by the value of type. The marker is used to indicate the type of message (warn- ing, error, probed value, config value, etc). Note the xf86Verbose value is ignored for messages of type X_ERROR. The marker values are: X_PROBED Value was probed. X_CONFIG Value was given in the config file. X_DEFAULT Value is a default. X_CMDLINE Value was given on the command line. X_NOTICE Notice. X_ERROR Error message. X_WARNING Warning message. X_INFO Informational message. X_NONE No prefix. xf86MsgVerb(MessageType type, int verb, const char *format, ...) Like xf86Msg(), but with the verbosity level given explicitly. xf86DrvMsg(int scrnIndex, MessageType type, const char *format, ...) This is like xf86Msg() except that the driver's name (the name field of the ScrnInfoRec) followed by the scrnIndex in parentheses is printed following the prefix. This should be used by video drivers in most cases as it clearly indicates which driver/screen the message is for. If scrnIndex is negative, this function behaves exactly like xf86Msg(). NOTE: This function can only be used after the ScrnIn- foRec and its name field have been allocated. That means that it can not be used before the END of the ChipProbe() function. Prior to that, use xf86Msg(), providing the driver's name explicitly. No screen number can be sup- plied at that point. xf86DrvMsgVerb(int scrnIndex, MessageType type, int verb, const char *format, ...) Like xf86DrvMsg(), but with the verbosity level given explicitly. 18.2 Functions for setting values based on command line and config file Bool xf86SetDepthBpp(ScrnInfoPtr scrp, int depth, int bpp, int fbbpp, int depth24flags) This function sets the depth, pixmapBPP and bitsPerPixel fields of the ScrnInfoRec. It also determines the defaults for display-wide attributes and pixmap formats the screen will support, and finds the Display subsection that matches the depth/bpp. This function should nor- mally be called very early from the ChipPreInit() func- tion. It requires that the confScreen field of the ScrnInfoRec be initialised prior to calling it. This is done by the XFree86 common layer prior to calling ChipPreInit(). The parameters passed are: depth driver's preferred default depth if no other is given. If zero, use the overall server default. bpp Same, but for the pixmap bpp. fbbpp Same, but for the framebuffer bpp. depth24flags Flags that indicate the level of 24/32bpp sup- port and whether conversion between different framebuffer and pixmap formats is supported. The flags for this argument are defined as fol- lows, and multiple flags may be ORed together: NoDepth24Support No depth 24 formats supported Support24bppFb 24bpp framebuffer supported Support32bppFb 32bpp framebuffer supported SupportConvert24to32 Can convert 24bpp pixmap to 32bpp fb SupportConvert32to24 Can convert 32bpp pixmap to 24bpp fb ForceConvert24to32 Force 24bpp pixmap to 32bpp fb con- version ForceConvert32to24 Force 32bpp pixmap to 24bpp fb con- version It uses the command line, config file, and default values in the correct order of precedence to determine the depth and bpp values. It is up to the driver to check the results to see that it supports them. If not the Chip- PreInit() function should return FALSE. If only one of depth/bpp is given, the other is set to a reasonable (and consistent) default. If a driver finds that the initial depth24flags it uses later results in a fb format that requires more video memory than is available it may call this function a sec- ond time with a different depth24flags setting. On success, the return value is TRUE. On failure it prints an error message and returns FALSE. The following fields of the ScrnInfoRec are initialised by this function: depth, bitsPerPixel, display, imageByteOrder, bitmapScanlinePad, bitmapScanlineUnit, bitmap- BitOrder, numFormats, formats, fbFormat. void xf86PrintDepthBpp(scrnInfoPtr scrp) This function can be used to print out the depth and bpp settings. It should be called after the final call to xf86SetDepthBpp(). Bool xf86SetWeight(ScrnInfoPtr scrp, rgb weight, rgb mask) This function sets the weight, mask, offset and rgbBits fields of the ScrnInfoRec. It would normally be called fairly early in the ChipPreInit() function for depths > 8bpp. It requires that the depth and display fields of the ScrnInfoRec be initialised prior to calling it. The parameters passed are: weight driver's preferred default weight if no other is given. If zero, use the overall server default. mask Same, but for mask. It uses the command line, config file, and default values in the correct order of precedence to determine the weight value. It derives the mask and offset values from the weight and the defaults. It is up to the driver to check the results to see that it supports them. If not the ChipPreInit() function should return FALSE. On success, this function prints a message showing the weight values selected, and returns TRUE. On failure it prints an error message and returns FALSE. The following fields of the ScrnInfoRec are initialised by this function: weight, mask, offset. Bool xf86SetDefaultVisual(ScrnInfoPtr scrp, int visual) This function sets the defaultVisual field of the ScrnIn- foRec. It would normally be called fairly early from the ChipPreInit() function. It requires that the depth and display fields of the ScrnInfoRec be initialised prior to calling it. The parameters passed are: visual driver's preferred default visual if no other is given. If -1, use the overall server default. It uses the command line, config file, and default values in the correct order of precedence to determine the default visual value. It is up to the driver to check the result to see that it supports it. If not the Chip- PreInit() function should return FALSE. On success, this function prints a message showing the default visual selected, and returns TRUE. On failure it prints an error message and returns FALSE. Bool xf86SetGamma(ScrnInfoPtr scrp, Gamma gamma) This function sets the gamma field of the ScrnInfoRec. It would normally be called fairly early from the Chip- PreInit() function in cases where the driver supports gamma correction. It requires that the monitor field of the ScrnInfoRec be initialised prior to calling it. The parameters passed are: gamma driver's preferred default gamma if no other is given. If zero (< 0.01), use the overall server default. It uses the command line, config file, and default values in the correct order of precedence to determine the gamma value. It is up to the driver to check the results to see that it supports them. If not the ChipPreInit() function should return FALSE. On success, this function prints a message showing the gamma value selected, and returns TRUE. On failure it prints an error message and returns FALSE. void xf86SetDpi(ScrnInfoPtr pScrn, int x, int y) This function sets the xDpi and yDpi fields of the Scrn- InfoRec. The driver can specify preferred defaults by setting x and y to non-zero values. The -dpi command line option overrides all other settings. Otherwise, if the DisplaySize entry is present in the screen's Monitor config file section, it is used together with the virtual size to calculate the dpi values. This function should be called after all the mode resolution has been done. void xf86SetBlackWhitePixels(ScrnInfoPtr pScrn) This functions sets the blackPixel and whitePixel fields of the ScrnInfoRec according to whether or not the -flip- Pixels command line options is present. const char *xf86GetVisualName(int visual) Returns a printable string with the visual name matching the numerical visual class provided. If the value is outside the range of valid visual classes, NULL is returned. 18.3 Primary Mode functions The primary mode helper functions are those which would normally be used by a driver, unless it has unusual requirements which cannot be catered for the by the helpers. int xf86ValidateModes(ScrnInfoPtr scrp, DisplayModePtr availModes, char **modeNames, ClockRangePtr clockRanges, int *linePitches, int minPitch, int maxPitch, int pitchInc, int minHeight, int maxHeight, int virtualX, int virtualY, unsigned long apertureSize, LookupModeFlags strategy) This function basically selects the set of modes to use based on those available and the various constraints. It also sets some other related parameters. It is normally called near the end of the ChipPreInit() function. The parameters passed to the function are: availModes List of modes available for the monitor. modeNames List of mode names that the screen is request- ing. clockRanges A list of clock ranges allowed by the driver. Each range includes whether interlaced or mul- tiscan modes are supported for that range. See below for more on clockRanges. linePitches List of supported line pitches supported by the driver. This is optional and should be NULL when not used. minPitch Minimum line pitch supported by the driver. This must be supplied when linePitches is NULL, and is ignored otherwise. maxPitch Maximum line pitch supported by the driver. This is required when minPitch is required. pitchInc Granularity of horizontal pitch values as sup- ported by the chipset. This is expressed in bits. This must be supplied. minHeight minimum virtual height allowed. If zero, no limit is imposed. maxHeight maximum virtual height allowed. If zero, no limit is imposed. virtualX If greater than zero, this is the virtual width value that will be used. Otherwise, the vir- tual width is chosen to be the smallest that can accommodate the modes selected. virtualY If greater than zero, this is the virtual height value that will be used. Otherwise, the virtual height is chosen to be the smallest that can accommodate the modes selected. apertureSize The size (in bytes) of the aperture used to access video memory. strategy The strategy to use when choosing from multiple modes with the same name. The options are: LOOKUP_DEFAULT ??? LOOKUP_BEST_REFRESH mode with best refresh rate LOOKUP_CLOSEST_CLOCK mode with closest matching clock LOOKUP_LIST_ORDER first usable mode in list LOOKUP_CLKDIV2 Allow halved clocks LOOKUP_CLKDIV2 can be combined (OR'ed) with one of the others. This function requires that the following fields of the ScrnInfoRec are initialised prior to calling it: clock[] List of discrete clocks (when non-pro- grammable). numClocks Number of discrete clocks (when non-pro- grammable). progClock Whether the clock is programmable or not. formats pixmap formats for screen numFormats number of pixmap formats for screen videoRam total video memory size (in bytes) maxHValue Maximum horizontal timing value allowed maxVValue Maximum vertical timing value allowed This function fills in the following ScrnInfoRec fields: modePool A subset of the modes available to the monitor which are compatible with the driver. modes One mode entry for each of the requested modes, with the status field of each filled in to indicate if the mode has been accepted or not. This list of modes is a circular list. virtualX The resulting virtual width. virtualY The resulting virtual height. displayWidth The resulting line pitch. virtualFrom Where the virtual size was determined from. The first stage of this function checks that the virtualX and virtualY values supplied (if greater than zero) are consistent with the line pitch and maxHeight limitations. If not, an error message is printed, and the return value is -1. The second stage sets up the mode pool, eliminating imme- diately any modes that exceed the driver's line pitch limits, and also the virtual width and height limits (if greater than zero). For each mode removed an informa- tional message is printed at verbosity level 2. If the mode pool ends up being empty, an error message is printed, and the return value is -1. The final stage is to lookup each mode, and fill in the remaining parameters. If an error condition is encoun- tered, a message is printed, and the return value is -1. Otherwise, the return value is the number of valid modes found (0 if none are found). A message is only printed by this function when a funda- mental problem is found. It is intended that this func- tion may be called more than once if there is more than one set of constraints that the driver can work within. If this function returns -1, the ChipPreInit() function should return FALSE. clockRanges is a linked list of clock ranges allowed by the driver. If a mode doesn't fit in any of the defined clockRanges, it is rejected. The first clockRange that matches all requirements is used. clockRanges contains the following fields: minClock maxClock The lower and upper mode clock bounds for which the rest of the clockRange parameters apply. Since these are the mode clocks, they are not scaled with the ClockMulFactor and ClockDivFac- tor. It is up to the driver to adjust these values if they depend on the clock scaling fac- tors. clockIndex (not used yet) -1 for programmable clocks interlaceAllowed TRUE if interlacing is allowed for this range doubleScanAllowed TRUE if doublescan is allowed for this range ClockMulFactor ClockDivFactor Scaling factors that are applied to the mode clocks ONLY before selecting a clock index (when there is no programmable clock) or a Syn- thClock value. This is useful for drivers that support pixel multiplexing or that need to scale the clocks because of hardware restric- tions (like sending 24bpp data to an 8 bit RAM- DAC using a tripled clock). Note that these parameters describe what must be done to the mode clock to achieve the data transport clock between graphics controller and RAMDAC. For example for 2:1 pixel multiplex- ing, two pixels are sent to the RAMDAC on each clock. This allows the RAMDAC clock to be half of the actual pixel clock. Hence, ClockMulFac- tor=1 and ClockDivFactor=2. This means that the clock used for clock selection (ie, deter- mining the correct clock index from the list of discrete clocks) or for the SynthClock field in case of a programmable clock is: (mode->Clock * ClockMulFactor) / ClockDivFactor. PrivFlags This field is copied into the mode->PrivFlags field when this clockRange is selected by xf86ValidateModes(). It allows the driver to find out what clock range was selected, so it knows it needs to set up pixel multiplexing or any other range-dependent feature. This field is purely driver-defined: it may contain flag bits, an index or anything else (as long as it is an INT). Note that the mode->SynthClock field is always filled in by xf86ValidateModes(): it will contain the ``data trans- port clock'', which is the clock that will have to be programmed in the chip when it has a programmable clock, or the clock that will be picked from the clocks list when it is not a programmable one. Thus: mode->SynthClock = (mode->Clock * ClockMulFactor) / ClockDivFactor void xf86PruneDriverModes(ScrnInfoPtr scrp) This function deletes modes in the modes field of the ScrnInfoRec that have been marked as invalid. This is normally run after having run xf86ValidateModes() for the last time. For each mode that is deleted, a warning mes- sage is printed out indicating the reason for it being deleted. void xf86SetCrtcForModes(ScrnInfoPtr scrp, int adjustFlags) This function fills in the Crtc* fields for all the modes in the modes field of the ScrnInfoRec. The adjustFlags parameter determines how the vertical CRTC values are scaled for interlaced modes. They are halved if it is INTERLACE_HALVE_V. The vertical CRTC values are doubled for doublescan modes, and are further multiplied by the VScan value. This function is normally called after calling xf86PruneDriverModes(). NOTE: The Crtc* fields are not initialised anywhere else, so the driver must either call this function or ini- tialise them itself. void xf86PrintModes(ScrnInfoPtr scrp) This function prints out the virtual size setting, and the line pitch being used. It also prints out one line for each mode being used, including its pixel clock, hor- izontal sync rate, refresh rate, and whether it is inter- laced or multiscan. This function is normally called after calling xf86SetCrtcForModes(). 18.4 Secondary Mode functions The secondary mode helper functions are functions which are normally used by the primary mode helper functions, and which are not normally called directly by a driver. If a driver has unusual requirements and needs to do its own mode validation, it might be able to make use of some of these secondary mode helper functions. int xf86GetNearestClock(ScrnInfoPtr scrp, int freq, Bool allowDiv2, int *divider) This function returns the index of the closest clock to the frequency freq given (in kHz). It assumes that the number of clocks is greater than zero. It requires that the numClocks and clock fields of the ScrnInfoRec are initialised. The allowDiv2 field determines if the clocks can be halved. The *divider return value indi- cates whether clock division is used when determining the clock returned. This function is only for non-programmable clocks. const char *xf86ModeStatusToString(ModeStatus status) This function converts the status value to a descriptive printable string. ModeStatus xf86LookupMode(ScrnInfoPtr scrp, DisplayModePtr modep, ClockRangePtr clockRanges, LookupModeFlags strategy) This function takes a pointer to a mode with the name filled in, and looks for a mode in the modePool list which matches. The parameters of the matching mode are filled in to *modep. The clockRanges and strategy param- eters are as for the xf86ValidateModes() function above. This function requires the modePool, clock[], numClocks and progClock fields of the ScrnInfoRec to be initialised before being called. The return value is MODE_OK if a mode was found. Other- wise it indicates why a matching mode could not be found. ModeStatus xf86InitialCheckModeForDriver(ScrnInfoPtr scrp, DisplayModePtr mode, int maxPitch, int virtualX, int virtualY) This function checks the passed mode against some basic driver constraints. Apart from the ones passed explic- itly, the maxHValue and maxVValue fields of the ScrnIn- foRec are also used. If the ValidMode field of the Scrn- InfoRec is set, that function is also called to check the mode. If the mode is consistent with the constraints, the return value is MODE_OK. Otherwise the return value indicates which constraint wasn't met. void xf86DeleteMode(DisplayModePtr *modeList, DisplayModePtr mode) This function deletes the mode given from the modeList. It never prints any messages, so it is up to the caller to print a message if required. 18.5 Functions for handling strings and tokens Tables associating strings and numerical tokens combined with the following functions provide a compact way of handling strings from the config file, and for converting tokens into printable strings. The table data structure is: typedef struct { int token; const char * name; } SymTabRec, *SymTabPtr; A table is an initialised array of SymTabRec. The tokens must be non-nega- tive integers. Multiple names may be mapped to a single token. The table is terminated with an element with a token value of -1 and NULL for the name. const char *xf86TokenToString(SymTabPtr table, int token) This function returns the first string in table that matches token. If no match is found, NULL is returned (NOTE, older versions of this function would return the string "unknown" when no match is found). int xf86StringToToken(SymTabPtr table, const char *string) This function returns the first token in table that matches string. The xf86NameCmp() function is used to determine the match. If no match is found, -1 is returned. 18.6 Functions for finding which config file entries to use These functions can be used to select the appropriate config file entries that match the detected hardware. They are described above in the Probe (section 5.8, page 1) and Available Functions (section 9.3, page 1) sections. 18.7 Probing discrete clocks on old hardware The xf86GetClocks() function may be used to assist in finding the discrete pixel clock values on older hardware. void xf86GetClocks(ScrnInfoPtr pScrn, int num, Bool (*ClockFunc)(ScrnInfoPtr, int), void (*ProtectRegs)(ScrnInfoPtr, Bool), void (*BlankScreen)(ScrnInfoPtr, Bool), int vertsyncreg, int maskval, int knownclkindex, int knownclkvalue) This function uses a comparative sampling method to mea- sure the discrete pixel clock values. The number of dis- crete clocks to measure is given by num. clockFunc is a function that selects the n'th clock. It should also save or restore any state affected by programming the clocks when the index passed is CLK_REG_SAVE or CLK_REG_RESTORE. ProtectRegs is a function that does whatever is required to protect the hardware state while selecting a new clock. BlankScreen is a function that blanks the screen. vertsyncreg and maskval are the reg- ister and bitmask to check for the presence of vertical sync pulses. knownclkindex and knownclkvalue are the index and value of a known clock. These are the known references on which the comparative measurements are based. The number of clocks probed is set in pScrn->num- Clocks, and the probed clocks are set in the pScrn->clock[] array. All of the clock values are in units of kHz. void xf86ShowClocks(ScrnInfoPtr scrp, MessageType from) Print out the pixel clocks scrp->clock[]. from indicates whether the clocks were probed or from the config file. 19. The vgahw module The vgahw modules provides an interface for saving, restoring and programming the standard VGA registers, and for handling VGA colourmaps. 19.1 Data Structures The public data structures used by the vgahw module are vgaRegRec and vgaH- WRec. They are defined in vgaHW.h. 19.2 General vgahw Functions Bool vgaHWGetHWRec(ScrnInfoPtr pScrn) This function allocates a vgaHWRec structure, and hooks it into the ScrnInfoRec's privates. Like all information hooked into the privates, it is persistent, and only needs to be allocated once per screen. This function should normally be called from the driver's ChipPreInit() function. The vgaHWRec is zero-allocated, and the fol- lowing fields are explicitly initialised: ModeReg.DAC[] initialised with a default colourmap ModeReg.Attribute[0x11] initialised with the default overscan index ShowOverscan initialised according to the "ShowOverscan" option paletteEnabled initialised to FALSE cmapSaved initialised to FALSE pScrn initialised to pScrn In addition to the above, vgaHWSetStdFuncs() is called to initialise the register access function fields with the standard VGA set of functions. Once allocated, a pointer to the vgaHWRec can be obtained from the ScrnInfoPtr with the VGAHWPTR(pScrn) macro. void vgaHWFreeHWRec(ScrnInfoPtr pScrn) This function frees a vgaHWRec structure. It should be called from a driver's ChipFreeScreen() function. Bool vgaHWSetRegCounts(ScrnInfoPtr pScrn, int numCRTC, int numSequencer, int numGraphics, int numAttribute) This function allows the number of CRTC, Sequencer, Graphics and Attribute registers to be changed. This makes it possible for extended registers to be saved and restored with vgaHWSave() and vgaHWRestore(). This func- tion should be called after a vgaHWRec has been allocated with vgaHWGetHWRec(). The default values are defined in vgaHW.h as follows: #define VGA_NUM_CRTC 25 #define VGA_NUM_SEQ 5 #define VGA_NUM_GFX 9 #define VGA_NUM_ATTR 21 Bool vgaHWCopyReg(vgaRegPtr dst, vgaRegPtr src) This function copies the contents of the VGA saved regis- ters in src to dst. Note that it isn't possible to sim- ply do this with memcpy() (or similar). This function returns TRUE unless there is a problem allocating space for the CRTC and related fields in dst. void vgaHWSetStdFuncs(vgaHWPtr hwp) This function initialises the register access function fields of hwp with the standard VGA set of functions. This is called by vgaHWGetHWRec(), so there is usually no need to call this explicitly. The register access func- tions are described below. void vgaHWSetMmioFuncs(vgaHWPtr hwp, CARD8 *base, int offset) This function initialised the register access function fields of hwp with a generic MMIO set of functions. hwp->MMIOBase is initialised with base, which must be the virtual address that the start of MMIO area is mapped to. hwp->MMIOOffset is initialised with offset, which must be calculated in such a way that when the standard VGA I/O port value is added to it the correct offset into the MMIO area results. That means that these functions are only suitable when the VGA I/O ports are made available in a direct mapping to the MMIO space. If that is not the case, the driver will need to provide its own regis- ter access functions. The register access functions are described below. Bool vgaHWMapMem(ScrnInfoPtr pScrn) This function maps the VGA memory window. It requires that the vgaHWRec be allocated. If a driver requires non-default MapPhys or MapSize settings (the physical location and size of the VGA memory window) then those fields of the vgaHWRec must be initialised before calling this function. Otherwise, this function initialiases the default values of 0xA0000 for MapPhys and (64 * 1024) for MapSize. This function must be called before attempting to save or restore the VGA state. If the driver doesn't call it explicitly, the vgaHWSave() and vgaHWRestore() functions may call it if they need to access the VGA mem- ory (in which case they will also call vgaHWUnmapMem() to unmap the VGA memory before exiting). void vgaHWUnmapMem(ScrnInfoPtr pScrn) This function unmaps the VGA memory window. It must only be called after the memory has been mapped. The Base field of the vgaHWRec field is set to NULL to indicate that the memory is no longer mapped. void vgaHWGetIOBase(vgaHWPtr hwp) This function initialises the IOBase field of the vgaH- WRec. This function must be called before using any other functions that access the video hardware. A macro VGAHW_GET_IOBASE() is also available in vgaHW.h that returns the I/O base, and this may be used when the vgahw module is not loaded (for example, in the Chip- Probe() function). void vgaHWUnlock(vgaHWPtr hwp) This function unlocks the VGA CRTC[0-7] registers, and must be called before attempting to write to those regis- ters. A macro VGAHW_UNLOCK(base) is also available in vgaHW.h that does the same thing, and this may be used when the vgahw module is not loaded (for example, in the Chip- Probe() function). void vgaHWLock(vgaHWPtr hwp) This function locks the VGA CRTC[0-7] registers. A macro VGAHW_LOCK(base) is also available in vgaHW.h that does the same thing, and this may be used when the vgahw module is not loaded (for example, in the Chip- Probe() function). void vgaHWSave(ScrnInfoPtr pScrn, vgaRegPtr save, int flags) This function saves the VGA state. The state is written to the vgaRegRec pointed to by save. flags is set to one or more of the following flags ORed together: VGA_SR_MODE the mode setting registers are saved VGA_SR_FONTS the text mode font/text data is saved VGA_SR_CMAP the colourmap (LUT) is saved VGA_SR_ALL all of the above are saved The vgaHWRec and its IOBase fields must be initialised before this function is called. If VGA_SR_FONTS is set in flags, the VGA memory window must be mapped. If it isn't then vgaHWMapMem() will be called to map it, and vgaHWUnmapMem() will be called to unmap it afterwards. vgaHWSave() uses the three functions below in the order vgaHWSaveColormap(), vgaHWSaveMode(), vgaHWSaveFonts() to carry out the different save phases. It is undecided at this stage whether they will be part of the vgahw mod- ule's public interface or not. void vgaHWSaveMode(ScrnInfoPtr pScrn, vgaRegPtr save) This functions saves the VGA mode registers. They are saved to the vgaRegRec pointed to by save. The registers saved are: MiscOut CRTC[0-0x18] Attribute[0-0x14] Graphics[0-8] Sequencer[0-4] void vgaHWSaveFonts(ScrnInfoPtr pScrn, vgaRegPtr save) This functions saves the text mode font and text data held in the video memory. If called while in a graphics mode, no save is done. The VGA memory window must be mapped with vgaHWMapMem() before to calling this func- tion. On some platforms, one or more of the font/text plane saves may be no-ops. This is the case when the plat- form's VC driver already takes care of this. void vgaHWSaveColormap(ScrnInfoPtr pScrn, vgaRegPtr save) This function saves the VGA colourmap (LUT). Before sav- ing it, it attempts to verify that the colourmap is read- able. In rare cases where it isn't readable, a default colourmap is saved instead. void vgaHWRestore(ScrnInfoPtr pScrn, vgaRegPtr restore, int flags) This function programs the VGA state. The state pro- grammed is that contained in the vgaRegRec pointed to by restore. flags is the same as described above for the vgaHWSave() function. The vgaHWRec and its IOBase fields must be initialised before this function is called. If VGA_SR_FONTS is set in flags, the VGA memory window must be mapped. If it isn't then vgaHWMapMem() will be called to map it, and vgaHWUnmapMem() will be called to unmap it afterwards. vgaHWRestore() uses the three functions below in the order vgaHWRestoreFonts(), vgaHWRestoreMode(), vgaHWRe- storeColormap() to carry out the different restore phases. It is undecided at this stage whether they will be part of the vgahw module's public interface or not. void vgaHWRestoreMode(ScrnInfoPtr pScrn, vgaRegPtr restore) This functions restores the VGA mode registers. They are restore from the data in the vgaRegRec pointed to by restore. The registers restored are: MiscOut CRTC[0-0x18] Attribute[0-0x14] Graphics[0-8] Sequencer[0-4] void vgaHWRestoreFonts(ScrnInfoPtr pScrn, vgaRegPtr restore) This functions restores the text mode font and text data to the video memory. The VGA memory window must be mapped with vgaHWMapMem() before to calling this func- tion. On some platforms, one or more of the font/text plane restores may be no-ops. This is the case when the plat- form's VC driver already takes care of this. void vgaHWRestoreColormap(ScrnInfoPtr pScrn, vgaRegPtr restore) This function restores the VGA colourmap (LUT). void vgaHWInit(ScrnInfoPtr pScrn, DisplayModePtr mode) This function fills in the vgaHWRec's ModeReg field with the values appropriate for programming the given video mode. It requires that the ScrnInfoRec's depth field is initialised, which determines how the registers are pro- grammed. void vgaHWSeqReset(vgaHWPtr hwp, Bool start) Do a VGA sequencer reset. If start is TRUE, the reset is started. If start is FALSE, the reset is ended. void vgaHWProtect(ScrnInfoPtr pScrn, Bool on) This function protects VGA registers and memory from cor- ruption during loads. It is typically called with on set to TRUE before programming, and with on set to FALSE after programming. Bool vgaHWSaveScreen(ScreenPtr pScreen, Bool on) This function blanks and unblanks the screen. It is blanked when on is FALSE, and unblanked when on is TRUE. void vgaHWBlankScreen(ScrnInfoPtr pScrn, Bool on) This function blanks and unblanks the screen. It is blanked when on is FALSE, and unblanked when on is TRUE. This function is provided for use in cases where the ScrnInfoRec can't be derived from the ScreenRec, like probing for clocks. 19.3 VGA Colormap Functions The vgahw modules uses the standard colormap support (see the Colormap Han- dling (section 13., page 1) section. This is initialised with the following function: Bool vgaHWHandleColormaps(ScreenPtr pScreen) 19.4 VGA Register Access Functions The vgahw module abstracts access to the standard VGA registers by using a set of functions held in the vgaHWRec. When the vgaHWRec is created these function pointers are initialised with the set of standard VGA I/O register access functions. In addition to these, the vgahw module includes a basic set of MMIO register access functions, and the vgaHWRec function pointers can be initialised to these by calling the vgaHWSetMmioFuncs() function described above. Some drivers/platforms may require a different set of functions for VGA access. The access functions are described here. void writeCrtc(vgaHWPtr hwp, CARD8 index, CARD8 value) Write value to CRTC register index. CARD8 readCrtc(vgaHWPtr hwp, CARD8 index) Return the value read from CRTC register index. void writeGr(vgaHWPtr hwp, CARD8 index, CARD8 value) Write value to Graphics Controller register index. CARD8 readGR(vgaHWPtr hwp, CARD8 index) Return the value read from Graphics Controller register index. void writeSeq(vgaHWPtr hwp, CARD8 index, CARD8, value) Write value to Sequencer register index. CARD8 readSeq(vgaHWPtr hwp, CARD8 index) Return the value read from Sequencer register index. void writeAttr(vgaHWPtr hwp, CARD8 index, CARD8, value) Write value to Attribute Controller register index. When writing out the index value this function should set bit 5 (0x20) according to the setting of hwp->paletteEnabled in order to preserve the palette access state. It should be cleared when hwp->paletteEnabled is TRUE and set when it is FALSE. CARD8 readAttr(vgaHWPtr hwp, CARD8 index) Return the value read from Attribute Controller register index. When writing out the index value this function should set bit 5 (0x20) according to the setting of hwp->paletteEnabled in order to preserve the palette access state. It should be cleared when hwp->paletteEn- abled is TRUE and set when it is FALSE. void writeMiscOut(vgaHWPtr hwp, CARD8 value) Write `value' to the Miscellaneous Output register. CARD8 readMiscOut(vgwHWPtr hwp) Return the value read from the Miscellaneous Output reg- ister. void enablePalette(vgaHWPtr hwp) Clear the palette address source bit in the Attribute Controller index register and set hwp->paletteEnabled to TRUE. void disablePalette(vgaHWPtr hwp) Set the palette address source bit in the Attribute Con- troller index register and set hwp->paletteEnabled to FALSE. void writeDacMask(vgaHWPtr hwp, CARD8 value) Write value to the DAC Mask register. CARD8 readDacMask(vgaHWptr hwp) Return the value read from the DAC Mask register. void writeDacReadAddress(vgaHWPtr hwp, CARD8 value) Write value to the DAC Read Address register. void writeDacWriteAddress(vgaHWPtr hwp, CARD8 value) Write value to the DAC Write Address register. void writeDacData(vgaHWPtr hwp, CARD8 value) Write value to the DAC Data register. CARD8 readDacData(vgaHWptr hwp) Return the value read from the DAC Data register. 20. Some notes about writing a driver NOTE: some parts of this are not up to date The following is an outline for writing a basic unaccelerated driver for a PCI video card with a linear mapped framebuffer, and which has a VGA core. It is includes some general information that is relevant to most drivers (even those which don't fit that basic description). The information here is based on the initial conversion of the Matrox Millen- nium driver to the ``new design''. For a fleshing out and sample implementa- tion of some of the bits outlined here, refer to that driver. Note that this is an example only. The approach used here will not be appropriate for all drivers. Each driver must reserve a unique driver name, and a string that is used to prefix all of its externally visible symbols. This is to avoid name space clashes when loading multiple drivers. The examples here are for the ``ZZZ'' driver, which uses the ``ZZZ'' or ``zzz'' prefix for its externally visible symbols. 20.1 Include files All drivers normally include the following headers: "xf86.h" "xf86_OSproc.h" "xf86_ansic.h" "xf86Resources.h" Wherever inb/outb (and related things) are used the following should be included: "compiler.h" Drivers that need to access PCI vendor/device definitions need this: "xf86PciInfo.h" Drivers that need to access the PCI config space need this: "xf86Pci.h" Drivers using the mi banking wrapper need: "mibank.h" Drivers that initialise a SW cursor need this: "mipointer.h" All drivers implementing backing store need this: "mibstore.h" All drivers using the mi colourmap code need this: "micmap.h" If a driver uses the vgahw module, it needs this: "vgaHW.h" Drivers supporting VGA or Hercules monochrome screens need: "xf1bpp.h" Drivers supporting VGA or EGC 16-colour screens need: "xf4bpp.h" Drivers using cfb need: #define PSZ 8 #include "cfb.h" #undef PSZ Drivers supporting bpp 16, 24 or 32 with cfb need one or more of: "cfb16.h" "cfb24.h" "cfb32.h" The driver's own header file: "zzz.h" Drivers must NOT include the following: "xf86Priv.h" "xf86Privstr.h" "xf86_libc.h" "xf86_OSlib.h" "Xos.h" any OS header 20.2 Data structures and initialisation o The following macros should be defined: #define VERSION #define ZZZ_NAME "ZZZ" /* the name used to prefix messages */ #define ZZZ_DRIVER_NAME "zzz" /* the driver name as used in config file */ #define ZZZ_MAJOR_VERSION #define ZZZ_MINOR_VERSION #define ZZZ_PATCHLEVEL XXX Probably want to remove one of these version. NOTE: ZZZ_DRIVER_NAME should match the name of the driver module without things like the "lib" prefix, the "_drv" suffix or filename extensions. o A DriverRec must be defined, which includes the functions required at the pre-probe phase. The name of this DriverRec must be an upper-case version of ZZZ_DRIVER_NAME (for the purposes of static linking). DriverRec ZZZ = { VERSION, "unaccelerated driver for ZZZ Zzzzzy cards", ZZZIdentify, ZZZProbe, NULL, 0 }; o Define list of supported chips and their matching ID: static SymTabRec ZZZChipsets[] = { { PCI_CHIP_ZZZ1234, "zzz1234a" }, { PCI_CHIP_ZZZ5678, "zzz5678a" }, { -1, NULL } }; The token field may be any integer value that the driver may use to uniquely identify the supported chipsets. For drivers that support only PCI devices using the PCI device IDs might be a natural choice, but this isn't mandatory. For drivers that support both PCI and other devices (like ISA), some other ID should probably used. When other IDs are used as the tokens it is recommended that the names be defined as an enum type. o If the driver uses the xf86MatchPciInstances() helper (recommended for drivers that support PCI cards) a list that maps PCI IDs to chip IDs and fixed resources must be defined: static PciChipsets ZZZPciChipsets[] = { { PCI_CHIP_ZZZ1234, PCI_CHIP_ZZZ1234, RES_SHARED_VGA }, { PCI_CHIP_ZZZ5678, PCI_CHIP_ZZZ5678, RES_SHARED_VGA }, { -1, -1, RES_UNDEFINED } } o Define the XF86ModuleVersionInfo struct for the driver. This is required for the dynamically loaded version: #ifdef XFree86LOADER static XF86ModuleVersionInfo zzzVersRec = { "zzz", MODULEVENDORSTRING, MODINFOSTRING1, MODINFOSTRING2, XF86_VERSION_CURRENT, ZZZ_MAJOR_VERSION, ZZZ_MINOR_VERSION, ZZZ_PATCHLEVEL, ABI_CLASS_VIDEODRV, ABI_VIDEODRV_VERSION, MOD_CLASS_VIDEODRV, {0,0,0,0} }; #endif o Define a data structure to hold the driver's screen-specific data. This must be used instead of global variables. This would be defined in the "zzz.h" file, something like: typedef struct { type1 field1; type2 field2; int fooHack; Bool pciRetry; Bool noAccel; Bool hwCursor; CloseScreenProcPtr CloseScreen; ... } ZZZRec, *ZZZPtr; o Define the list of config file Options that the driver accepts. For consistency between drivers those in the list of ``standard'' options should be used where appropriate before inventing new options. typedef enum { OPTION_FOO_HACK, OPTION_PCI_RETRY, OPTION_HW_CURSOR, OPTION_NOACCEL } ZZZOpts; static OptionInfoRec ZZZOptions[] = { { OPTION_FOO_HACK, "FooHack", OPTV_INTEGER, {0}, FALSE }, { OPTION_PCI_RETRY, "PciRetry", OPTV_BOOLEAN, {0}, FALSE }, { OPTION_HW_CURSOR, "HWcursor", OPTV_BOOLEAN, {0}, FALSE }, { OPTION_NOACCEL, "NoAccel", OPTV_BOOLEAN, {0}, FALSE }, { -1, NULL, OPTV_NONE, {0}, FALSE } }; 20.3 Functions 20.3.1 SetupProc For dynamically loaded modules, a ModuleData variable is required. It is should be the name of the driver prepended to "ModuleData". A Setup() func- tion is also required, which calls xf86AddDriver() to add the driver to the main list of drivers. #ifdef XFree86LOADER static MODULESETUPPROTO(mgaSetup); XF86ModuleData zzzModuleData = { &zzzVersRec, zzzSetup, NULL }; static pointer zzzSetup(pointer module, pointer opts, int *errmaj, int *errmin) { static Bool setupDone = FALSE; /* This module should be loaded only once, but check to be sure. */ if (!setupDone) { /* * Modules that this driver always requires may be loaded * here by calling LoadSubModule(). */ setupDone = TRUE; xf86AddDriver(&MGA, module, 0); /* * The return value must be non-NULL on success even though * there is no TearDownProc. */ return (pointer)1; } else { if (errmaj) *errmaj = LDR_ONCEONLY; return NULL; } } #endif 20.3.2 GetRec, FreeRec A function is usually required to allocate the driver's screen-specific data structure and hook it into the ScrnInfoRec's driverPrivate field. The Scrn- InfoRec's driverPrivate is initialised to NULL, so it is easy to check if the initialisation has already been done. After allocating it, initialise the fields. By using xnfcalloc() to do the allocation it is zeroed, and if the allocation fails the server exits. static Bool ZZZGetRec(ScrnInfoPtr pScrn) { if (pScrn->driverPrivate != NULL) return TRUE; pScrn->driverPrivate = xnfcalloc(sizeof(ZZZRec), 1); /* Initialise as required */ ... return TRUE; } Define a macro in "zzz.h" which gets a pointer to the ZZZRec when given pScrn: #define ZZZPTR(p) ((ZZZPtr)((p)->driverPrivate)) Define a function to free the above, setting it to NULL once it has been freed: static void ZZZFreeRec(ScrnInfoPtr pScrn) { if (pScrn->driverPrivate == NULL) return; xfree(pScrn->driverPrivate); pScrn->driverPrivate = NULL; } 20.3.3 Identify Define the Identify() function. It is run before the Probe, and typically prints out an identifying message, which might include the chipsets it sup- ports. This function is mandatory: static void ZZZIdentify(int flags) { xf86PrintChipsets(ZZZ_NAME, "driver for ZZZ Tech chipsets", ZZZChipsets); } 20.3.4 Probe Define the Probe() function. The purpose of this is to find all instances of the hardware that the driver supports, and for the ones not already claimed by another driver, claim the slot, and allocate a ScrnInfoRec. This should be a minimal probe, and it should under no circumstances leave the state of the hardware changed. Because a device is found, don't assume that it will be used. Don't do any initialisations other than the required ScrnInfoRec initialisations. Don't allocate any new data structures. This function is mandatory. NOTE: The xf86DrvMsg() functions cannot be used from the Probe. static Bool ZZZProbe(DriverPtr drv, int flags) { Bool foundScreen = FALSE; int numDevSections, numUsed; GDevPtr *devSections; int *usedChips; int i; /* * Find the config file Device sections that match this * driver, and return if there are none. */ if ((numDevSections = xf86MatchDevice(ZZZ_DRIVER_NAME, &devSections)) <= 0) { return FALSE; } /* * Since this is a PCI card, "probing" just amounts to checking * the PCI data that the server has already collected. If there * is none, return. * * Although the config file is allowed to override things, it * is reasonable to not allow it to override the detection * of no PCI video cards. * * The provided xf86MatchPciInstances() helper takes care of * the details. */ /* test if PCI bus present */ if (xf86GetPciVideoInfo()) { numUsed = xf86MatchPciInstances(ZZZ_NAME, PCI_VENDOR_ZZZ, ZZZChipsets, ZZZPciChipsets, devSections, numDevSections, drv, &usedChips); for (i = 0; i < numUsed; i++) { ScrnInfoPtr pScrn; /* Allocate a ScrnInfoRec */ pScrn = xf86AllocateScreen(drv, 0); pScrn->driverVersion = VERSION; pScrn->driverName = ZZZ_DRIVER_NAME; pScrn->name = ZZZ_NAME; pScrn->Probe = ZZZProbe; pScrn->PreInit = ZZZPreInit; pScrn->ScreenInit = ZZZScreenInit; pScrn->SwitchMode = ZZZSwitchMode; pScrn->AdjustFrame = ZZZAdjustFrame; pScrn->EnterVT = ZZZEnterVT; pScrn->LeaveVT = ZZZLeaveVT; pScrn->FreeScreen = ZZZFreeScreen; pScrn->ValidMode = ZZZValidMode; foundScreen = TRUE; /* add screen to entity */ xf86ConfigActivePciEntity(pScrn, usedChips[i], ZZZPciChipsets, NULL, NULL, NULL, NULL, NULL); } if (numUsed > 0) xfree(usedChips); } #ifdef HAS_ISA_DEVS /* * If the driver supports ISA hardware, the following block * can be included too. */ numUsed = xf86MatchIsaInstances(ZZZ_NAME, ZZZChipsets, ZZZIsaChipsets, drv, ZZZFindIsaDevice, devSections, numDevSections, &usedChips); for (i = 0; i < numUsed; i++) { ScrnInfoPtr pScrn = xf86AllocateScreen(drv,0); pScrn->driverVersion = VERSION; pScrn->driverName = ZZZ_DRIVER_NAME; pScrn->name = ZZZ_NAME; pScrn->Probe = ZZZProbe; pScrn->PreInit = ZZZPreInit; pScrn->ScreenInit = ZZZScreenInit; pScrn->SwitchMode = ZZZSwitchMode; pScrn->AdjustFrame = ZZZAdjustFrame; pScrn->EnterVT = ZZZEnterVT; pScrn->LeaveVT = ZZZLeaveVT; pScrn->FreeScreen = ZZZFreeScreen; pScrn->ValidMode = ZZZValidMode; foundScreen = TRUE; xf86ConfigActiveIsaEntity(pScrn, usedChips[i], ZZZIsaChipsets, NULL, NULL, NULL, NULL, NULL); } if (numUsed > 0) xfree(usedChips); #endif /* HAS_ISA_DEVS */ xfree(devSections); return foundScreen; 20.3.5 PreInit Define the PreInit() function. The purpose of this is to find all the infor- mation required to determine if the configuration is usable, and to ini- tialise those parts of the ScrnInfoRec that can be set once at the beginning of the first server generation. The information should be found in the least intrusive way possible. This function is mandatory. NOTES: 1. The PreInit() function is only called once during the life of the X server (at the start of the first generation). 2. Data allocated here must be of the type that persists for the life of the X server. This means that data that hooks into the ScrnInfoRec's privates field should be allocated here, but data that hooks into the ScreenRec's devPrivates field should not be allocated here. The driverPrivate field should also be allocated here. 3. Although the ScrnInfoRec has been allocated before this function is called, the ScreenRec has not been allocated. That means that things requiring it cannot be used in this function. 4. Very little of the ScrnInfoRec has been initialised when this function is called. It is important to get the order of doing things right in this function. static Bool ZZZPreInit(ScrnInfoPtr pScrn, int flags) { /* Fill in the monitor field */ pScrn->monitor = pScrn->confScreen->monitor; /* * If using the vgahw module, it will typically be loaded * here by calling xf86LoadSubModule(pScrn, "vgahw"); */ /* * Set the depth/bpp. Our preferred default depth/bpp is 8, and * we support both 24bpp and 32bpp framebuffer layouts. * This sets pScrn->display also. */ if (!xf86SetDepthBpp(pScrn, 8, 8, 8, Support24bppFb | Support32bppFb)) { return FALSE; } else { if (depth/bpp isn't one we support) { print error message; return FALSE; } } /* Print out the depth/bpp that was set */ xf86PrintDepthBpp(pScrn); /* Set bits per RGB for 8bpp */ if (pScrn->depth <= 8) { /* Take into account a dac_6_bit option here */ pScrn->rgbBits = 6 or 8; } /* * xf86SetWeight() and xf86SetDefaultVisual() must be called * after pScrn->display is initialised. */ /* Set weight/mask/offset for depth > 8 */ if (pScrn->depth > 8) { if (!xf86SetWeight(pScrn, defaultWeight, defaultMask)) { return FALSE; } else { if (weight isn't one we support) { print error message; return FALSE; } } } /* Set the default visual. */ if (!xf86SetDefaultVisual(pScrn, -1)) { return FALSE; } else { if (visual isn't one we support) { print error message; return FALSE; } } /* If the driver supports gamma correction, set the gamma. */ if (!xf86SetGamma(pScrn, default_gamma)) { return FALSE; } /* This driver uses a programmable clock */ pScrn->progClock = TRUE; /* Allocate the ZZZRec driverPrivate */ if (!ZZZGetRec(pScrn)) { return FALSE; } pZzz = ZZZPTR(pScrn); /* Collect all of the option flags (fill in pScrn->options) */ xf86CollectOptions(pScrn, NULL); /* * Process the options based on the information in ZZZOptions. * The results are written to ZZZOptions. */ xf86ProcessOptions(pScrn->scrnIndex, pScrn->options, ZZZOptions); /* * Set various fields of ScrnInfoRec and/or ZZZRec based on * the options found. */ from = X_DEFAULT; pZzz->hwCursor = FALSE; if (xf86IsOptionSet(ZZZOptions, OPTION_HW_CURSOR)) { from = X_CONFIG; pZzz->hwCursor = TRUE; } xf86DrvMsg(pScrn->scrnIndex, from, "Using %s cursor\n", pZzz->hwCursor ? "HW" : "SW"); if (xf86IsOptionSet(ZZZOptions, OPTION_NOACCEL)) { pZzz->noAccel = TRUE; xf86DrvMsg(pScrn->scrnIndex, X_CONFIG, "Acceleration disabled\n"); } else { pZzz->noAccel = FALSE; } if (xf86IsOptionSet(ZZZOptions, OPTION_PCI_RETRY)) { pZzz->UsePCIRetry = TRUE; xf86DrvMsg(pScrn->scrnIndex, X_CONFIG, "PCI retry enabled\n"); } pZzz->fooHack = 0; if (xf86GetOptValInteger(ZZZOptions, OPTION_FOO_HACK, &pZzz->fooHack)) { xf86DrvMsg(pScrn->scrnIndex, X_CONFIG, "Foo Hack set to %d\n", pZzz->fooHack); } /* * Find the PCI slot(s) that this screen claimed in the probe. * In this case, exactly one is expected, so complain otherwise. * Note in this case we're not interested in the card types so * that parameter is set to NULL. */ if ((i = xf86GetPciInfoForScreen(pScrn->scrnIndex, &pciList, NULL)) != 1) { print error message; ZZZFreeRec(pScrn); if (i > 0) xfree(pciList); return FALSE; } /* Note that pciList should be freed below when no longer needed */ /* * Determine the chipset, allowing config file chipset and * chipid values to override the probed information. The config * chipset value has precedence over its chipid value if both * are present. * * It isn't necessary to fill in pScrn->chipset if the driver * keeps track of the chipset in its ZZZRec. */ ... /* * Determine video memory, fb base address, I/O addresses, etc, * allowing the config file to override probed values. * * Set the appropriate pScrn fields (videoRam is probably the * most important one that other code might require), and * print out the settings. */ ... /* Initialise a clockRanges list. */ ... /* Set any other chipset specific things in the ZZZRec */ ... /* Select valid modes from those available */ i = xf86ValidateModes(pScrn, pScrn->monitor->Modes, pScrn->display->modes, clockRanges, NULL, minPitch, maxPitch, rounding, minHeight, maxHeight, pScrn->display->virtualX, pScrn->display->virtualY, pScrn->videoRam * 1024, LOOKUP_BEST_REFRESH); if (i == -1) { ZZZFreeRec(pScrn); return FALSE; } /* Prune the modes marked as invalid */ xf86PruneDriverModes(pScrn); /* If no valid modes, return */ if (i == 0 || pScrn->modes == NULL) { print error message; ZZZFreeRec(pScrn); return FALSE; } /* * Initialise the CRTC fields for the modes. This driver expects * vertical values to be halved for interlaced modes. */ xf86SetCrtcForModes(pScrn, INTERLACE_HALVE_V); /* Set the current mode to the first in the list. */ pScrn->currentMode = pScrn->modes; /* Print the list of modes being used. */ xf86PrintModes(pScrn); /* Set the DPI */ xf86SetDpi(pScrn, 0, 0); /* Load bpp-specific modules */ switch (pScrn->bitsPerPixel) { case 1: mod = "xf1bpp"; break; case 4: mod = "xf4bpp"; break; case 8: mod = "cfb"; break; case 16: mod = "cfb16"; break; case 24: mod = "cfb24"; break; case 32: mod = "cfb32"; break; } if (mod && !xf86LoadSubModule(pScrn, mod)) ZZZFreeRec(pScrn); return FALSE; /* Load XAA if needed */ if (!pZzz->noAccel || pZzz->hwCursor) if (!xf86LoadSubModule(pScrn, "xaa")) { ZZZFreeRec(pScrn); return FALSE; } /* Done */ return TRUE; } 20.3.6 MapMem, UnmapMem Define functions to map and unmap the video memory and any other memory aper- tures required. These functions are not mandatory, but it is often useful to have such functions. static Bool ZZZMapMem(ScrnInfoPtr pScrn) { /* Call xf86MapPciMem() to map each PCI memory area */ ... return TRUE or FALSE; } static Bool ZZZUnmapMem(ScrnInfoPtr pScrn) { /* Call xf86UnMapVidMem() to unmap each memory area */ ... return TRUE or FALSE; } 20.3.7 Save, Restore Define functions to save and restore the original video state. These func- tions are not mandatory, but are often useful. static void ZZZSave(ScrnInfoPtr pScrn) { /* * Save state into per-screen data structures. * If using the vgahw module, vgaHWSave will typically be * called here. */ ... } static void ZZZRestore(ScrnInfoPtr pScrn) { /* * Restore state from per-screen data structures. * If using the vgahw module, vgaHWRestore will typically be * called here. */ ... } 20.3.8 ModeInit Define a function to initialise a new video mode. This function isn't manda- tory, but is often useful. static Bool ZZZModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode) { /* * Program a video mode. If using the vgahw module, * vgaHWInit and vgaRestore will typically be called here. * Once up to the point where there can't be a failure * set pScrn->vtSema to TRUE. */ ... } 20.3.9 ScreenInit Define the ScreenInit() function. This is called at the start of each server generation, and should fill in as much of the ScreenRec as possible as well as any other data that is initialised once per generation. It should ini- tialise the framebuffer layers it is using, and initialise the initial video mode. This function is mandatory. NOTE: The ScreenRec (pScreen) is passed to this driver, but it and the Scrn- InfoRecs are not yet hooked into each other. This means that in this func- tion, and functions it calls, one cannot be found from the other. static Bool ZZZScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv) { /* Get the ScrnInfoRec */ pScrn = xf86Screens[pScreen->myNum]; /* * If using the vgahw module, its data structures and related * things are typically initialised/mapped here. */ /* Save the current video state */ ZZZSave(pScrn); /* Initialise the first mode */ ZZZModeInit(pScrn, pScrn->currentMode); /* Set the viewport if supported */ ZZZAdjustFrame(scrnIndex, pScrn->frameX0, pScrn->frameY0, 0); /* * Setup the screen's visuals, and initialise the framebuffer * code. */ /* Reset the visual list */ miClearVisualTypes(); /* * Setup the visuals supported. This driver only supports * TrueColor for bpp > 8, so the default set of visuals isn't * acceptable. To deal with this, call miSetVisualTypes with * the appropriate visual mask. */ if (pScrn->bitsPerPixel > 8) { if (!miSetVisualTypes(pScrn->depth, TrueColorMask, pScrn->rgbBits, pScrn->defaultVisual)) return FALSE; } else { if (!miSetVisualTypes(pScrn->depth, miGetDefaultVisualMask(pScrn->depth), pScrn->rgbBits, pScrn->defaultVisual)) return FALSE; } /* * Initialise the framebuffer. */ switch (pScrn->bitsPerPixel) { case 1: ret = xf1bppScreenInit(pScreen, FbBase, pScrn->virtualX, pScrn->virtualY, pScrn->xDpi, pScrn->yDpi, pScrn->displayWidth); break; case 4: ret = xf4bppScreenInit(pScreen, FbBase, pScrn->virtualX, pScrn->virtualY, pScrn->xDpi, pScrn->yDpi, pScrn->displayWidth); break; case 8: ret = cfbScreenInit(pScreen, FbBase, pScrn->virtualX, pScrn->virtualY, pScrn->xDpi, pScrn->yDpi, pScrn->displayWidth); break; case 16: ret = cfb16ScreenInit(pScreen, FbBase, pScrn->virtualX, pScrn->virtualY, pScrn->xDpi, pScrn->yDpi, pScrn->displayWidth); break; case 24: ret = cfb24ScreenInit(pScreen, FbBase, pScrn->virtualX, pScrn->virtualY, pScrn->xDpi, pScrn->yDpi, pScrn->displayWidth); break; case 32: ret = cfb32ScreenInit(pScreen, FbBase, pScrn->virtualX, pScrn->virtualY, pScrn->xDpi, pScrn->yDpi, pScrn->displayWidth); break; default: print a message about an internal error; ret = FALSE; break; } if (!ret) return FALSE; /* Override the default mask/offset settings */ if (pScrn->bitsPerPixel > 8) { for (i = 0, visual = pScreen->visuals; i < pScreen->numVisuals; i++, visual++) { if ((visual->class | DynamicClass) == DirectColor) { visual->offsetRed = pScrn->offset.red; visual->offsetGreen = pScrn->offset.green; visual->offsetBlue = pScrn->offset.blue; visual->redMask = pScrn->mask.red; visual->greenMask = pScrn->mask.green; visual->blueMask = pScrn->mask.blue; } } } /* * If banking is needed, initialise an miBankInfoRec (defined in * "mibank.h"), and call miInitializeBanking(). */ if (!miInitializeBanking(pScreen, pScrn->virtualX, pScrn->virtualY, pScrn->displayWidth, pBankInfo)) return FALSE; /* * If backing store is to be supported (as is usually the case), * initialise it. */ miInitializeBackingStore(pScreen); /* * Set initial black & white colourmap indices. */ xf86SetBlackWhitePixels(pScreen); /* * Install colourmap functions. If using the vgahw module, * vgaHandleColormaps would usually be called here. */ ... /* * Initialise cursor functions. This example is for the mi * software cursor. */ miDCInitialize(pScreen, xf86GetPointerScreenFuncs()); /* Initialise the default colourmap */ switch (pScrn->depth) { case 1: if (!xf1bppCreateDefColormap(pScreen)) return FALSE; break; case 4: if (!xf4bppCreateDefColormap(pScreen)) return FALSE; break; default: if (!cfbCreateDefColormap(pScreen)) return FALSE; break; } /* * Wrap the CloseScreen vector and set SaveScreen. */ ZZZPTR(pScrn)->CloseScreen = pScreen->CloseScreen; pScreen->CloseScreen = ZZZCloseScreen; pScreen->SaveScreen = ZZZSaveScreen; /* Report any unused options (only for the first generation) */ if (serverGeneration == 1) { xf86ShowUnusedOptions(pScrn->scrnIndex, pScrn->options); } /* Done */ return TRUE; } 20.3.10 SwitchMode Define the SwitchMode() function if mode switching is supported by the driver. static Bool ZZZSwitchMode(int scrnIndex, DisplayModePtr mode, int flags) { return ZZZModeInit(xf86Screens[scrnIndex], mode); } 20.3.11 AdjustFrame Define the AdjustFrame() function if the driver supports this. static void ZZZAdjustFrame(int scrnIndex, int x, int y, int flags) { /* Adjust the viewport */ } 20.3.12 EnterVT, LeaveVT Define the EnterVT() and LeaveVT() functions. These functions are mandatory. static Bool ZZZEnterVT(int scrnIndex, int flags) { ScrnInfoPtr pScrn = xf86Screens[scrnIndex]; return ZZZModeInit(pScrn, pScrn->currentMode); } static void ZZZLeaveVT(int scrnIndex, int flags) { ScrnInfoPtr pScrn = xf86Screens[scrnIndex]; ZZZRestore(pScrn); } 20.3.13 CloseScreen Define the CloseScreen() function: This function is mandatory. Note that it unwraps the previously wrapped pScreen->CloseScreen, and finishes by calling it. static Bool ZZZCloseScreen(int scrnIndex, ScreenPtr pScreen) { ScrnInfoPtr pScrn = xf86Screens[scrnIndex]; ZZZRestore(pScrn); ZZZUnmapMem(pScrn); pScrn->vtSema = FALSE; pScreen->CloseScreen = ZZZPTR(pScrn)->CloseScreen; return (*pScreen->CloseScreen)(scrnIndex, pScreen); } 20.3.14 SaveScreen Define the SaveScreen() function (the screen blanking function). When using the vgahw module, this will typically be: This function is mandatory. static Bool ZZZSaveScreen(ScreenPtr pScreen, Bool unblank) { return vgaHWSaveScreen(pScreen, unblank); } 20.3.15 FreeScreen Define the FreeScreen() function. This function is optional. It should be defined if the ScrnInfoRec driverPrivate field is used so that it can be freed when a screen is deleted by the common layer for reasons possibly beyond the driver's control. This function is not used in during normal (error free) operation. The per-generation data is freed by the Clos- eScreen() function. static void ZZZFreeScreen(int scrnIndex, int flags) { /* * If the vgahw module is used vgaHWFreeHWRec() would be called * here. */ ZZZFreeRec(xf86Screens[scrnIndex]); } Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml,v 1.9 1999/07/18 03:26:51 dawes Exp $ $XFree86: xc/programs/Xserver/hw/xfree86/doc/DESIGN,v 1.5 1999/07/18 08:34:28 dawes Exp $ From mmacdona@tsi.gte.com Fri Nov 12 13:45:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Fri, 12 Nov 1999 13:45:00 -0000 Subject: XF86SUP.SYS Message-ID: What are the XAA primitives? I'm very new to X programming, sorry.. I'm learning fast though :) I'm also looking at a giveio driver, and a mapmem driver, but I thing directx may be faster, and definately more flexable. Yeah, DX will create a pointer to a linear framebuffer - and emulate a linear framebuffer if the card doesn't directly support it, then it has various draw commands.. Whatever dx needs, or I can do quicker in asm, I can do seperate.. I think making a directx server with directx os-support is the best way to go.. I could use the mapmem, and getio drivers for pty, and mouse, and keyboard.. Then maybe later use directinput for mouse and keyboard if it makes sense.. I think I need to look at the server code now :) >What do you need for directx rendering? Basically, you should just need >the linear frame buffer, together with some information about video >resolution and pixel depth, and then call rendering operations like >bitblt, draw line, draw arc, etc.? Is this right? In this case you might >maybe only redirect the XAA primitives to corresponding directx calls. From ssiddiqi@inspirepharm.com Fri Nov 12 13:53:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Fri, 12 Nov 1999 13:53:00 -0000 Subject: XF86SUP.SYS References: Message-ID: may be you look into various documents in /xc/programs/Xserver/hw/xfree86/doc You will find answers to a lot of your questions. I am not sure xaa could be integrated in DX, but then I do not much about DX itself. xaa codes are in hw/xfree86, look at various Video card spoecific codes, particularly in xc/programs/Xserver/hw/xfree86/vga Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Friday, November 12, 1999 4:45 PM > To: 'Holger Veit' > Cc: 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: XF86SUP.SYS > > > > What are the XAA primitives? I'm very new to X > programming, sorry.. I'm > learning fast though :) > I'm also looking at a giveio driver, and a mapmem driver, > but I thing > directx may be faster, and definately more flexable. > > Yeah, DX will create a pointer to a linear framebuffer - > and emulate a > linear framebuffer if the card doesn't directly support > it, then it has > various draw commands.. Whatever dx needs, or I can do > quicker in asm, I > can do seperate.. I think making a directx server with > directx os-support is > the best way to go.. I could use the mapmem, and getio > drivers for pty, and > mouse, and keyboard.. Then maybe later use directinput > for mouse and > keyboard if it makes sense.. > > I think I need to look at the server code now :) > > >What do you need for directx rendering? Basically, you > should just need > >the linear frame buffer, together with some information > about video > >resolution and pixel depth, and then call rendering > operations like > >bitblt, draw line, draw arc, etc.? Is this right? In > this case you might > >maybe only redirect the XAA primitives to corresponding > directx calls. > From mmacdona@tsi.gte.com Fri Nov 12 13:59:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Fri, 12 Nov 1999 13:59:00 -0000 Subject: XF86SUP.SYS Message-ID: What about hw/svga? -----Original Message----- From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] Sent: Friday, November 12, 1999 4:48 PM To: Mike MacDonald; 'Holger Veit' Cc: cygwin-xfree@sourceware.cygnus.com Subject: RE: XF86SUP.SYS may be you look into various documents in /xc/programs/Xserver/hw/xfree86/doc You will find answers to a lot of your questions. I am not sure xaa could be integrated in DX, but then I do not much about DX itself. xaa codes are in hw/xfree86, look at various Video card spoecific codes, particularly in xc/programs/Xserver/hw/xfree86/vga Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Friday, November 12, 1999 4:45 PM > To: 'Holger Veit' > Cc: 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: XF86SUP.SYS > > > > What are the XAA primitives? I'm very new to X > programming, sorry.. I'm > learning fast though :) > I'm also looking at a giveio driver, and a mapmem driver, > but I thing > directx may be faster, and definately more flexable. > > Yeah, DX will create a pointer to a linear framebuffer - > and emulate a > linear framebuffer if the card doesn't directly support > it, then it has > various draw commands.. Whatever dx needs, or I can do > quicker in asm, I > can do seperate.. I think making a directx server with > directx os-support is > the best way to go.. I could use the mapmem, and getio > drivers for pty, and > mouse, and keyboard.. Then maybe later use directinput > for mouse and > keyboard if it makes sense.. > > I think I need to look at the server code now :) > > >What do you need for directx rendering? Basically, you > should just need > >the linear frame buffer, together with some information > about video > >resolution and pixel depth, and then call rendering > operations like > >bitblt, draw line, draw arc, etc.? Is this right? In > this case you might > >maybe only redirect the XAA primitives to corresponding > directx calls. > From mmacdona@tsi.gte.com Fri Nov 12 14:05:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Fri, 12 Nov 1999 14:05:00 -0000 Subject: XF86SUP.SYS Message-ID: Well, if I just use DX to set the video mode, and return a framebuffer, shouldn't the xaa primitives work fine as they are? I only want to change the part of the code that changes the video mode and calls xf86MapVidMem(), and call directx functions instead to set the video mode, and get a framebuffer.. I can worry about using dx to accelerate xaa stuff later, if the video hardware supports something.. -----Original Message----- From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] Sent: Friday, November 12, 1999 4:48 PM To: Mike MacDonald; 'Holger Veit' Cc: cygwin-xfree@sourceware.cygnus.com Subject: RE: XF86SUP.SYS may be you look into various documents in /xc/programs/Xserver/hw/xfree86/doc You will find answers to a lot of your questions. I am not sure xaa could be integrated in DX, but then I do not much about DX itself. xaa codes are in hw/xfree86, look at various Video card spoecific codes, particularly in xc/programs/Xserver/hw/xfree86/vga Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Friday, November 12, 1999 4:45 PM > To: 'Holger Veit' > Cc: 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: XF86SUP.SYS > > > > What are the XAA primitives? I'm very new to X > programming, sorry.. I'm > learning fast though :) > I'm also looking at a giveio driver, and a mapmem driver, > but I thing > directx may be faster, and definately more flexable. > > Yeah, DX will create a pointer to a linear framebuffer - > and emulate a > linear framebuffer if the card doesn't directly support > it, then it has > various draw commands.. Whatever dx needs, or I can do > quicker in asm, I > can do seperate.. I think making a directx server with > directx os-support is > the best way to go.. I could use the mapmem, and getio > drivers for pty, and > mouse, and keyboard.. Then maybe later use directinput > for mouse and > keyboard if it makes sense.. > > I think I need to look at the server code now :) > > >What do you need for directx rendering? Basically, you > should just need > >the linear frame buffer, together with some information > about video > >resolution and pixel depth, and then call rendering > operations like > >bitblt, draw line, draw arc, etc.? Is this right? In > this case you might > >maybe only redirect the XAA primitives to corresponding > directx calls. > From ssiddiqi@inspirepharm.com Fri Nov 12 14:07:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Fri, 12 Nov 1999 14:07:00 -0000 Subject: XF86SUP.SYS References: Message-ID: hw/sga or hw/xfree86/svga? sure... or try S3, there is a lot of XAA stuff too Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Friday, November 12, 1999 5:00 PM > To: 'Suhaib Siddiqi' > Cc: 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: XF86SUP.SYS > > > What about hw/svga? > > -----Original Message----- > From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] > Sent: Friday, November 12, 1999 4:48 PM > To: Mike MacDonald; 'Holger Veit' > Cc: cygwin-xfree@sourceware.cygnus.com > Subject: RE: XF86SUP.SYS > > > > > may be you look into various documents in > /xc/programs/Xserver/hw/xfree86/doc > > You will find answers to a lot of your questions. > > I am not sure xaa could be integrated in DX, but then I > do not much > about DX itself. xaa codes are in hw/xfree86, look at > various Video > card spoecific codes, particularly in > xc/programs/Xserver/hw/xfree86/vga > > Suhaib > > > -----Original Message----- > > From: cygwin-xfree-owner@sourceware.cygnus.com > > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Mike > > MacDonald > > Sent: Friday, November 12, 1999 4:45 PM > > To: 'Holger Veit' > > Cc: 'cygwin-xfree@sourceware.cygnus.com' > > Subject: RE: XF86SUP.SYS > > > > > > > > What are the XAA primitives? I'm very new to X > > programming, sorry.. I'm > > learning fast though :) > > I'm also looking at a giveio driver, and a mapmem driver, > > but I thing > > directx may be faster, and definately more flexable. > > > > Yeah, DX will create a pointer to a linear framebuffer - > > and emulate a > > linear framebuffer if the card doesn't directly support > > it, then it has > > various draw commands.. Whatever dx needs, or I can do > > quicker in asm, I > > can do seperate.. I think making a directx server with > > directx os-support is > > the best way to go.. I could use the mapmem, and getio > > drivers for pty, and > > mouse, and keyboard.. Then maybe later use directinput > > for mouse and > > keyboard if it makes sense.. > > > > I think I need to look at the server code now :) > > > > >What do you need for directx rendering? Basically, you > > should just need > > >the linear frame buffer, together with some information > > about video > > >resolution and pixel depth, and then call rendering > > operations like > > >bitblt, draw line, draw arc, etc.? Is this right? In > > this case you might > > >maybe only redirect the XAA primitives to corresponding > > directx calls. > > > From ssiddiqi@inspirepharm.com Fri Nov 12 14:09:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Fri, 12 Nov 1999 14:09:00 -0000 Subject: XF86SUP.SYS References: Message-ID: Your choice, > -----Original Message----- > From: Mike MacDonald [ mailto:mmacdona@tsi.gte.com ] > Sent: Friday, November 12, 1999 5:05 PM > To: 'Suhaib Siddiqi'; 'Holger Veit' > Cc: 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: XF86SUP.SYS > > > Well, if I just use DX to set the video mode, and return > a framebuffer, > shouldn't the xaa primitives work fine as they are? I > only want to change > the part of the code that changes the video mode and > calls xf86MapVidMem(), > and call directx functions instead to set the video mode, > and get a > framebuffer.. > > I can worry about using dx to accelerate xaa stuff later, > if the video > hardware supports something.. > > -----Original Message----- > From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] > Sent: Friday, November 12, 1999 4:48 PM > To: Mike MacDonald; 'Holger Veit' > Cc: cygwin-xfree@sourceware.cygnus.com > Subject: RE: XF86SUP.SYS > > > > > may be you look into various documents in > /xc/programs/Xserver/hw/xfree86/doc > > You will find answers to a lot of your questions. > > I am not sure xaa could be integrated in DX, but then I > do not much > about DX itself. xaa codes are in hw/xfree86, look at > various Video > card spoecific codes, particularly in > xc/programs/Xserver/hw/xfree86/vga > > Suhaib > > > -----Original Message----- > > From: cygwin-xfree-owner@sourceware.cygnus.com > > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Mike > > MacDonald > > Sent: Friday, November 12, 1999 4:45 PM > > To: 'Holger Veit' > > Cc: 'cygwin-xfree@sourceware.cygnus.com' > > Subject: RE: XF86SUP.SYS > > > > > > > > What are the XAA primitives? I'm very new to X > > programming, sorry.. I'm > > learning fast though :) > > I'm also looking at a giveio driver, and a mapmem driver, > > but I thing > > directx may be faster, and definately more flexable. > > > > Yeah, DX will create a pointer to a linear framebuffer - > > and emulate a > > linear framebuffer if the card doesn't directly support > > it, then it has > > various draw commands.. Whatever dx needs, or I can do > > quicker in asm, I > > can do seperate.. I think making a directx server with > > directx os-support is > > the best way to go.. I could use the mapmem, and getio > > drivers for pty, and > > mouse, and keyboard.. Then maybe later use directinput > > for mouse and > > keyboard if it makes sense.. > > > > I think I need to look at the server code now :) > > > > >What do you need for directx rendering? Basically, you > > should just need > > >the linear frame buffer, together with some information > > about video > > >resolution and pixel depth, and then call rendering > > operations like > > >bitblt, draw line, draw arc, etc.? Is this right? In > > this case you might > > >maybe only redirect the XAA primitives to corresponding > > directx calls. > > > From mmacdona@tsi.gte.com Fri Nov 12 14:12:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Fri, 12 Nov 1999 14:12:00 -0000 Subject: XF86SUP.SYS Message-ID: In other words, I can do this, I just need to make it use dx to set the video mode, and I don't know where to do that. I can use dx to return a pointer to a frame buffer, and return that from xf86MapVidMem... Problem is that I need to use dx to initialize the screen.. After that, its just a pointer to a framebuffer, and a size that xfree can do whatever it wants with.. IO for keyboard and mouse, memory maping for ptys are all easy to do now also.. So, thats the last piece of the puzzle, and I'm searching the code right now to figure out how to implement this.. From mmacdona@tsi.gte.com Fri Nov 12 14:24:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Fri, 12 Nov 1999 14:24:00 -0000 Subject: XF86SUP.SYS Message-ID: Ok, are there some standard svga non accelerated xaa files in the tree, I'm looking at vga256/vga, I think they might qualify. For the start I can use those, then the xaa files can be modified to use dx later to speed them up.. Cool thing about that is that X will work with any video card that DX supports.. From ssiddiqi@inspirepharm.com Fri Nov 12 14:34:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Fri, 12 Nov 1999 14:34:00 -0000 Subject: XF86SUP.SYS References: Message-ID: Onething all the XF86 servers need XF86MapVidMem function. If I remember correctly it is described in xc/doc and xc/programs/Xserver/hw/xfree86/doc As far as DirectX stuff is concerned. Could you please consult with John Fortin first (fortinj@ibm.net). John has done a lot of DirectX work for XGGI. You might save a lot of time if you comunicate with him directly. It will also avoid duplicating some of John's work. Thanks. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Friday, November 12, 1999 5:24 PM > To: 'Suhaib Siddiqi' > Cc: 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: XF86SUP.SYS > > > Ok, are there some standard svga non accelerated xaa > files in the tree, I'm > looking at vga256/vga, I think they might qualify. For > the start I can use > those, then the xaa files can be modified to use dx later > to speed them up.. > > Cool thing about that is that X will work with any video > card that DX > supports.. > From mmacdona@tsi.gte.com Fri Nov 12 14:46:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Fri, 12 Nov 1999 14:46:00 -0000 Subject: XF86SUP.SYS Message-ID: Sure, I'll email him. I would like to know where he's at, and what hes working on. If he has this piece done, and is working on acceleration, thats cool.. If he's working on acceleration, then I may as well build any changes I'm doing into this. I'm looking at things now, and I should be able to localize most of my stuff to os-support, but it won't support the hardware acceleration used by X. Thats the issue, and I probably can make this thing work without using directx, and using the accelerated drivers available with X, but I don't know that that would be the best way to go with things. What do you think? DirectX is potentialy more work, but will support more hardware, and cooler graphics modes (like x in a window).. using getio, and mapmem to do video can get hairy, may or may not take as long as directx, and would only allow for full screen displays. Though the latter method would include X acceleration. At this point I feel that I could probably have at least a fullscreen unaccelerated 256 color xserver up and running next week using direct x to just set the video mode, and return a framebuffer. -----Original Message----- From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] Sent: Friday, November 12, 1999 5:30 PM To: Mike MacDonald Cc: cygwin-xfree@sourceware.cygnus.com Subject: RE: XF86SUP.SYS Onething all the XF86 servers need XF86MapVidMem function. If I remember correctly it is described in xc/doc and xc/programs/Xserver/hw/xfree86/doc As far as DirectX stuff is concerned. Could you please consult with John Fortin first (fortinj@ibm.net). John has done a lot of DirectX work for XGGI. You might save a lot of time if you comunicate with him directly. It will also avoid duplicating some of John's work. Thanks. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Friday, November 12, 1999 5:24 PM > To: 'Suhaib Siddiqi' > Cc: 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: XF86SUP.SYS > > > Ok, are there some standard svga non accelerated xaa > files in the tree, I'm > looking at vga256/vga, I think they might qualify. For > the start I can use > those, then the xaa files can be modified to use dx later > to speed them up.. > > Cool thing about that is that X will work with any video > card that DX > supports.. > From mmacdona@tsi.gte.com Fri Nov 12 14:51:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Fri, 12 Nov 1999 14:51:00 -0000 Subject: FW: Xserver Message-ID: > -----Original Message----- > From: Mike MacDonald > Sent: Friday, November 12, 1999 5:50 PM > To: 'fortinj@ibm.net' > Subject: Xserver > > I heard that you are doing some work with XGGI, and DirectX. I'm in the > process of doing some work on the os-support part of the X server, and > have reached a point where I want to use DirectX to set the video mode, > initialize a frame buffer, and return it to a server. I was going to pick > some unaccelerated xaa files to use with that framebuffer. If you have > already set up this, or we can work together on this - Like I can do the > os-support part, and setting the graphics mode, and you can do the > acceleration, or whatever based on what work you have already done, please > let me know. From ssiddiqi@inspirepharm.com Fri Nov 12 14:53:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Fri, 12 Nov 1999 14:53:00 -0000 Subject: XF86SUP.SYS References: Message-ID: There are a few differences between the project you are working and John's XGGI. John's work uses DirectX for XGGI. He wrote DirectX support for GGI. XGGI needs GGI libraries. You are attempting to make the XF86 (which XFree86 itself) executables work on Windows itself, without using GGI. However GGI also requires video memort maping, and framebuffer you explained for XF86. This where you could benefit by collaborating with John. His email address is fortinj@ibm.net. Oh if you could get XF86 executables functional in a week, that would be a BIG suprise for all of us. We definitely look forward to your accomplishments. Suhaib > -----Original Message----- > From: Mike MacDonald [ mailto:mmacdona@tsi.gte.com ] > Sent: Friday, November 12, 1999 5:46 PM > To: 'Suhaib Siddiqi' > Cc: 'cygwin-xfree@sourceware.cygnus.com' > Subject: RE: XF86SUP.SYS > > > Sure, I'll email him. I would like to know where he's > at, and what hes > working on. If he has this piece done, and is working on > acceleration, > thats cool.. If he's working on acceleration, then I may > as well build any > changes I'm doing into this. > > I'm looking at things now, and I should be able to > localize most of my stuff > to os-support, but it won't support the hardware > acceleration used by X. > > Thats the issue, and I probably can make this thing work > without using > directx, and using the accelerated drivers available with > X, but I don't > know that that would be the best way to go with things. > > What do you think? DirectX is potentialy more work, but > will support more > hardware, and cooler graphics modes (like x in a > window).. using getio, and > mapmem to do video can get hairy, may or may not take as > long as directx, > and would only allow for full screen displays. Though > the latter method > would include X acceleration. > > At this point I feel that I could probably have at least > a fullscreen > unaccelerated 256 color xserver up and running next week > using direct x to > just set the video mode, and return a framebuffer. > > -----Original Message----- > From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] > Sent: Friday, November 12, 1999 5:30 PM > To: Mike MacDonald > Cc: cygwin-xfree@sourceware.cygnus.com > Subject: RE: XF86SUP.SYS > > > > Onething all the XF86 servers need XF86MapVidMem function. If I > remember correctly it is described in > xc/doc and xc/programs/Xserver/hw/xfree86/doc > > > As far as DirectX stuff is concerned. Could you please > consult with > John Fortin first (fortinj@ibm.net). John has done a lot of > DirectX work for XGGI. You might save a lot of time if you > comunicate > with him directly. It will also avoid duplicating some of John's > work. > Thanks. > > Suhaib > > > -----Original Message----- > > From: cygwin-xfree-owner@sourceware.cygnus.com > > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Mike > > MacDonald > > Sent: Friday, November 12, 1999 5:24 PM > > To: 'Suhaib Siddiqi' > > Cc: 'cygwin-xfree@sourceware.cygnus.com' > > Subject: RE: XF86SUP.SYS > > > > > > Ok, are there some standard svga non accelerated xaa > > files in the tree, I'm > > looking at vga256/vga, I think they might qualify. For > > the start I can use > > those, then the xaa files can be modified to use dx later > > to speed them up.. > > > > Cool thing about that is that X will work with any video > > card that DX > > supports.. > > > From ssiddiqi@inspirepharm.com Fri Nov 12 14:59:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Fri, 12 Nov 1999 14:59:00 -0000 Subject: XF86SUP.SYS References: Message-ID: And by the way hardware acceleation (XAA) can be handle later. If you could get a non accelerated XF86 up and runing, that would be a big leap forward. XAA is sort of tricky for Windows because of direct access to video chips. On linux it can be done easily, but on Windows I think It would be a problem, unless you take Holger veit's approach. Holger's approach my or may not work for Windows. Also the next version of xfree86 (i.e XF 4.0) has a different mechanism of hardware acceleration. We may have to revisit it that time. The best approach might be (which you are trying) to have non-XAA server from xfree86 3.3.5 working on Windows and work on XAA for XFree86 4.0. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Suhaib > Siddiqi > Sent: Friday, November 12, 1999 5:49 PM > To: Mike MacDonald > Cc: cygwin-xfree@sourceware.cygnus.com > Subject: RE: XF86SUP.SYS > > > > > There are a few differences between the project you are > working and > John's XGGI. John's work uses DirectX for XGGI. He wrote DirectX > support for GGI. XGGI needs GGI libraries. > > You are attempting to make the XF86 (which XFree86 itself) > executables work on Windows itself, without using GGI. > > However GGI also requires video memort maping, and framebuffer you > explained for XF86. This where you could benefit by collaborating > with John. His email address is fortinj@ibm.net. > > Oh if you could get XF86 executables functional in a week, that > would > be a BIG suprise for all of us. We definitely look > forward to your > accomplishments. > > Suhaib > > > -----Original Message----- > > From: Mike MacDonald [ mailto:mmacdona@tsi.gte.com ] > > Sent: Friday, November 12, 1999 5:46 PM > > To: 'Suhaib Siddiqi' > > Cc: 'cygwin-xfree@sourceware.cygnus.com' > > Subject: RE: XF86SUP.SYS > > > > > > Sure, I'll email him. I would like to know where he's > > at, and what hes > > working on. If he has this piece done, and is working on > > acceleration, > > thats cool.. If he's working on acceleration, then I may > > as well build any > > changes I'm doing into this. > > > > I'm looking at things now, and I should be able to > > localize most of my stuff > > to os-support, but it won't support the hardware > > acceleration used by X. > > > > Thats the issue, and I probably can make this thing work > > without using > > directx, and using the accelerated drivers available with > > X, but I don't > > know that that would be the best way to go with things. > > > > What do you think? DirectX is potentialy more work, but > > will support more > > hardware, and cooler graphics modes (like x in a > > window).. using getio, and > > mapmem to do video can get hairy, may or may not take as > > long as directx, > > and would only allow for full screen displays. Though > > the latter method > > would include X acceleration. > > > > At this point I feel that I could probably have at least > > a fullscreen > > unaccelerated 256 color xserver up and running next week > > using direct x to > > just set the video mode, and return a framebuffer. > > > > -----Original Message----- > > From: Suhaib Siddiqi [ mailto:ssiddiqi@inspirepharm.com ] > > Sent: Friday, November 12, 1999 5:30 PM > > To: Mike MacDonald > > Cc: cygwin-xfree@sourceware.cygnus.com > > Subject: RE: XF86SUP.SYS > > > > > > > > Onething all the XF86 servers need XF86MapVidMem function. If I > > remember correctly it is described in > > xc/doc and xc/programs/Xserver/hw/xfree86/doc > > > > > > As far as DirectX stuff is concerned. Could you please > > consult with > > John Fortin first (fortinj@ibm.net). John has done a lot of > > DirectX work for XGGI. You might save a lot of time if you > > comunicate > > with him directly. It will also avoid duplicating some > of John's > > work. > > Thanks. > > > > Suhaib > > > > > -----Original Message----- > > > From: cygwin-xfree-owner@sourceware.cygnus.com > > > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > > Behalf Of Mike > > > MacDonald > > > Sent: Friday, November 12, 1999 5:24 PM > > > To: 'Suhaib Siddiqi' > > > Cc: 'cygwin-xfree@sourceware.cygnus.com' > > > Subject: RE: XF86SUP.SYS > > > > > > > > > Ok, are there some standard svga non accelerated xaa > > > files in the tree, I'm > > > looking at vga256/vga, I think they might qualify. For > > > the start I can use > > > those, then the xaa files can be modified to use dx later > > > to speed them up.. > > > > > > Cool thing about that is that X will work with any video > > > card that DX > > > supports.. > > > > > > From Holger.Veit@gmd.de Sat Nov 13 00:12:00 1999 From: Holger.Veit@gmd.de (Holger Veit) Date: Sat, 13 Nov 1999 00:12:00 -0000 Subject: XF86SUP.SYS References: Message-ID: <19991113091234.A10796@gmd.de> On Fri, Nov 12, 1999 at 04:45:05PM -0500, Mike MacDonald wrote: > > What are the XAA primitives? I'm very new to X programming, sorry.. I'm > learning fast though :) Check the X server sources, directories xc/programs/Xserver/hw/xfree86/xaa* XAA is XFree86 Accelerated Architecture, a server internal API to make the primitives of an accelerated video card available to the server DDX layer. Basically, to add a new card to the SVGA server, you create a new driver bz implementing some or all of these XAA functions. > I'm also looking at a giveio driver, and a mapmem driver, but I thing > directx may be faster, and definately more flexable. > > Yeah, DX will create a pointer to a linear framebuffer - and emulate a > linear framebuffer if the card doesn't directly support it, then it has > various draw commands.. Whatever dx needs, or I can do quicker in asm, I > can do seperate.. I think making a directx server with directx os-support is > the best way to go.. I could use the mapmem, and getio drivers for pty, and > mouse, and keyboard.. Then maybe later use directinput for mouse and > keyboard if it makes sense.. > > I think I need to look at the server code now :) Definitely. Holger -- If Microsoft is ever going to produce something that does not suck, it is very likely a vacuum cleaner. From iamcliff@ix.netcom.com Sun Nov 14 15:52:00 1999 From: iamcliff@ix.netcom.com (C R Johnson) Date: Sun, 14 Nov 1999 15:52:00 -0000 Subject: lesstif problem: text boxes not taking input Message-ID: <382F4B34.6D6E025C@ix.netcom.com> I am trying to port an old motif program of mine to lesstif and cygwin. I does work with lesstif on linux I am using exceed 6.1 as the X server I compiled using b20.1 and cygwin-xfree-x11r6.4-B20.1 My application runs in every way except the text boxes do not accept any input. I can write XmTextSetString them and the stuff shows up in them. I am getting a mess of warnings like... Warning: translation table syntax error: Unknown keysym name: osfActivate Warning: ... found while parsing ':osfActivate: ManagerParentActivate() ...when I start the program. my sources (18K) are at ftp://ftp.freeengineer.org/pub/opsheet-1.1.tar.gz The complete list of runtime error messages is at http://freeengineer.org/opsheet-errors.txt Thanks for any help cliff From ssiddiqi@inspirepharm.com Sun Nov 14 17:33:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Sun, 14 Nov 1999 17:33:00 -0000 Subject: lesstif problem: text boxes not taking input References: <382F4B34.6D6E025C@ix.netcom.com> Message-ID: set the XKeysymDB and XErrorDB ENV. The XKeysymDB and XErrorDB files are in /usr/X11R6/lib/X11 For example if you have usr/X11R6 on C:\drive then in your Windows ENV you set SET XKeysymDB=c:\usr\X11R6\lib\X11\XKeysymDB SET XErrorDB=c:\usr\X11R6\lib\X11\XErrorDB Put these in autoexec.bat if you are on Win95/98. On NT add it to your system ENV via System Control Panel. Win95/98 will require reboot, but on NT after you set the above ENV and pushed 'Apply" button and opening a new console Window should be enough. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of C R > Johnson > Sent: Sunday, November 14, 1999 6:52 PM > To: cygwin-xfree@sourceware.cygnus.com > Subject: lesstif problem: text boxes not taking input > > > I am trying to port an old motif program of mine > to lesstif and cygwin. > > I does work with lesstif on linux > > I am using exceed 6.1 as the X server > > I compiled using b20.1 and cygwin-xfree-x11r6.4-B20.1 > > My application runs in every way except the > text boxes do not accept any input. > > I can write XmTextSetString them and the stuff > shows up in them. > > I am getting a mess of warnings like... > > Warning: translation table syntax error: Unknown keysym name: > osfActivate > Warning: ... found while parsing ':osfActivate: > ManagerParentActivate() > > ...when I start the program. > > my sources (18K) are at > ftp://ftp.freeengineer.org/pub/opsheet-1.1.tar.gz > > The complete list of runtime error messages is at > http://freeengineer.org/opsheet-errors.txt > > Thanks for any help > > cliff > From fortinj@ibm.net Sun Nov 14 19:06:00 1999 From: fortinj@ibm.net (John Fortin) Date: Sun, 14 Nov 1999 19:06:00 -0000 Subject: Test Message-ID: <382F7AF2.7639C0EF@ibm.net> Test From mmacdona@tsi.gte.com Mon Nov 15 05:42:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Mon, 15 Nov 1999 05:42:00 -0000 Subject: X Message-ID: I think I don't have the latest X source, the one I seem to have is 6.3... I'm going to go about this, I think, by creating an xf86MapDXMem function. Then I can also look at using mapmem and getio to duplicate what Holger did, and get all the normal accelerated X servers up and running. This way people can choose. DX will be slow until I get all the xaa primitives updated to use DX acceleration. From ssiddiqi@inspirepharm.com Mon Nov 15 06:10:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Mon, 15 Nov 1999 06:10:00 -0000 Subject: X References: Message-ID: You have the right source code. It is 3.3.5, which is the latest stable XF86 source code. XF86 4.0 is under alpha testing and source code is going through alot of changes. Therefore working on XF86 4.0 developers snapshots may not be a good idea. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Monday, November 15, 1999 8:42 AM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: X > > > I think I don't have the latest X source, the one I seem > to have is 6.3... > > I'm going to go about this, I think, by creating an > xf86MapDXMem function. > Then I can also look at using mapmem and getio to > duplicate what Holger did, > and get all the normal accelerated X servers up and running. > > This way people can choose. DX will be slow until I get > all the xaa > primitives updated to use DX acceleration. > From fortinj@ibm.net Mon Nov 15 08:21:00 1999 From: fortinj@ibm.net (John Fortin) Date: Mon, 15 Nov 1999 08:21:00 -0000 Subject: Direct X and Xfree86 Message-ID: <38303000.EE6E1939@ibm.net> John Fortin wrote: > I couple of things about DX that I have learned (possibly incorrectly ;). > > * In full screen mode, the video memory may be cleared when there is a > contest switch to the windows desktop. So there has to be a way to refresh the > screen. I did this by having a back-buffer in user-memory, which is not > cleared, and then I blit to the primary buffer when I want to draw. The DX > docs. say that writting directly to the primary surface is usually a bad idea. > > * There are not any 2d drawing primitives in DX. There may be hardware > blitting acceleration, but only in video memory. There may be 3D accel. and > there are 3d primitives. > > * To get a pointer to the buffers and guareentee that it is a good pointer, > you have to lock the surface, do the blit, and unlock. This is a very expensive > operation. DX 6 allows the programmer to define a block of memory as a > dx-surface, and the pointer to the memory block doesn't change. Then we don't > have to do a lock every time, and we can use DX blitting. DX 3 (i.e WinNT4 does > not have this capibility ). We can simulate this by writting our own blit > function, but I have not done this yet. > > * Using DX means that the program will be a Windows program, and needs to be > well behaved with regards to the OS. It has to handle context-switching > (alt-tab for instance). In my implementation, this functionality runs as a > seperate thread which in created during the library startup. > > John > > Mike MacDonald wrote: > > > I think I don't have the latest X source, the one I seem to have is 6.3... > > > > I'm going to go about this, I think, by creating an xf86MapDXMem function. > > Then I can also look at using mapmem and getio to duplicate what Holger did, > > and get all the normal accelerated X servers up and running. > > > > This way people can choose. DX will be slow until I get all the xaa > > primitives updated to use DX acceleration. From mmacdona@tsi.gte.com Mon Nov 15 08:49:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Mon, 15 Nov 1999 08:49:00 -0000 Subject: X Message-ID: Hmm, well, I've talked to alot of people who basically use DX to get a surface, then use ASM routines to to their blitting.. Esp from System to video ram.. I didn't know about the 2d drawing primitives. I thought they were a part of Direct Draw, but I haven't gotten into that very far. Worst case scenario, I have some good quick asm routines for most of those primitives. I have to assume that the straight vga256 primitives are unaccelerated and pretty fast too. I would be nice though to use some of the hardware accelerations features on different cards through DX.. I'm going to try and get the accel servers up and running too.. -----Original Message----- From: John Fortin [ mailto:fortinj@ibm.net ] Sent: Monday, November 15, 1999 11:07 AM To: Mike MacDonald Subject: Re: X I couple of things about DX that I have learned (possibly incorrectly ;). * In full screen mode, the video memory may be cleared when there is a contest switch to the windows desktop. So there has to be a way to refresh the screen. I did this by having a back-buffer in user-memory, which is not cleared, and then I blit to the primary buffer when I want to draw. The DX docs. say that writting directly to the primary surface is usually a bad idea. * There are not any 2d drawing primitives in DX. There may be hardware blitting acceleration, but only in video memory. There may be 3D accel. and there are 3d primitives. * To get a pointer to the buffers and guareentee that it is a good pointer, you have to lock the surface, do the blit, and unlock. This is a very expensive operation. DX 6 allows the programmer to define a block of memory as a dx-surface, and the pointer to the memory block doesn't change. Then we don't have to do a lock every time, and we can use DX blitting. DX 3 (i.e WinNT4 does not have this capibility ). We can simulate this by writting our own blit function, but I have not done this yet. * Using DX means that the program will be a Windows program, and needs to be well behaved with regards to the OS. It has to handle context-switching (alt-tab for instance). In my implementation, this functionality runs as a seperate thread which in created during the library startup. John Mike MacDonald wrote: > I think I don't have the latest X source, the one I seem to have is 6.3... > > I'm going to go about this, I think, by creating an xf86MapDXMem function. > Then I can also look at using mapmem and getio to duplicate what Holger did, > and get all the normal accelerated X servers up and running. > > This way people can choose. DX will be slow until I get all the xaa > primitives updated to use DX acceleration. From mmacdona@tsi.gte.com Mon Nov 15 09:26:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Mon, 15 Nov 1999 09:26:00 -0000 Subject: XServer Message-ID: My thinking now, for initial Xserver stuff.. modify the current vga256 x server to initialize a full screen Directx in a 256 color mode for now.. 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.. I'm not sure how to handle the message loop, etc, but I'm sure it will get figured out. Then, later, I suppose use either asm calls, or gdi for 2d primitives. It should be easy to move to higher color depths after its up and running. For the accelerated, I'm going to try using/modifying mapmem to provide memory mapping functionality, and getio for port access. For mouse, keyboard, ttys - mapmem, and getio. getio may not be fast enough, and mapmem might not map memory properly, but I'll hit that when I get to it.. From ssiddiqi@inspirepharm.com Mon Nov 15 09:39:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Mon, 15 Nov 1999 09:39:00 -0000 Subject: XServer References: Message-ID: Mike, I am going to forward your message to XF86 Developers list. I think "gang of D four" (as known at Xfree86) at Xfree86 (David, David, David and Dirk) who are the orginal authors of XF86 might be able to give a good advice. Once I receive an answer I will forward it to cygwin-xfree list. BTW. I added your name to cygwin-xfree URl under Developers. Thanks for hard work, Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Monday, November 15, 1999 12:27 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: XServer > > > My thinking now, for initial Xserver stuff.. > > > modify the current vga256 x server to initialize a full > screen Directx in a > 256 color mode for now.. > > 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.. > > I'm not sure how to handle the message loop, etc, but I'm > sure it will get > figured out. Then, later, I suppose use either asm > calls, or gdi for 2d > primitives. > It should be easy to move to higher color depths after > its up and running. > > For the accelerated, I'm going to try using/modifying > mapmem to provide > memory mapping functionality, and getio for port access. > > For mouse, keyboard, ttys - mapmem, and getio. > > getio may not be fast enough, and mapmem might not map > memory properly, but > I'll hit that when I get to it.. > > From fortinj@ibm.net Mon Nov 15 10:15:00 1999 From: fortinj@ibm.net (John Fortin) Date: Mon, 15 Nov 1999 10:15:00 -0000 Subject: XServer References: Message-ID: <38304ACD.2BE05985@ibm.net> Mike MacDonald wrote: > My thinking now, for initial Xserver stuff.. > > modify the current vga256 x server to initialize a full screen Directx in a > 256 color mode for now.. > > do a lock in xf86MapVidMem > do an unlock in xf86UnMapVidMem If we create the surface in user-memory, we don't need to lock/unlock the back surface. We can write to it whenever we want. In the blit-function, we would have to lock the primary surface before the blit call. > > I don't know if those sync up to work, (I'm not sure when X calls those > functions) but thats my current thinking.. > > I'm not sure how to handle the message loop, etc, but I'm sure it will get > figured out. Then, later, I suppose use either asm calls, or gdi for 2d > primitives. > It should be easy to move to higher color depths after its up and running. > The code I sent shows how I handled it. It works pretty well. > > For the accelerated, I'm going to try using/modifying mapmem to provide > memory mapping functionality, and getio for port access. > > For mouse, keyboard, ttys - mapmem, and getio. Direct Input is probably best for mouse and keyboard as it gets raw data.. This is what I am working on now. The only 'problem' is that DI return keyboard scan codes. I need to write a KB mapping function to do this. > getio may not be fast enough, and mapmem might not map memory properly, but > I'll hit that when I get to it.. From fortinj@ibm.net Mon Nov 15 16:35:00 1999 From: fortinj@ibm.net (John Fortin) Date: Mon, 15 Nov 1999 16:35:00 -0000 Subject: test2 Message-ID: <3830A911.CA6B755@ibm.net> test2 From ssiddiqi@inspirepharm.com Tue Nov 16 03:40:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Tue, 16 Nov 1999 03:40:00 -0000 Subject: FW: Win32 XServer Message-ID: 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" 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 | > +---------------------------------------------------------------+ > From ssiddiqi@inspirepharm.com Tue Nov 16 03:41:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Tue, 16 Nov 1999 03:41:00 -0000 Subject: FW: FW: Win32 XServer Message-ID: Mike This is another reply from xfree86 developers. Suhaib > -----Original Message----- > From: owner-devel@XFree86.Org > [ mailto:owner-devel@XFree86.Org]On Behalf > Of David Woodhouse > Sent: Tuesday, November 16, 1999 4:46 AM > To: Tim Roberts > Cc: devel@XFree86.Org > Subject: Re: FW: Win32 XServer > > > timr@probo.com said: > > 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. > > There was a fairly long discussion about this a while ago. > > We came to the conclusion that, although a fullscreen X > server perhaps isn't > ideal for many people, it's a lot easier to do, and fits > into the existing X > server framework. > > For co-locating X clients and Win32 clients on the > Windows desktop, a > different approach is required, and one which shares > little code with the > existing X servers. There is already a libX11 for Windows > which 'converts' X11 > primitives to Win32 primitives to allow X11 programs to > be compiled into > native Win32 code. We discussed the possibility of using > that to provide a > 'fake' X server which does the translation on the fly for > its clients. > > For more details, contact me off the list, or read the > archives. About > half-way through, I posted a summary of the discussion: > > http://www.xfree86.org/devel/archives/devel/1999-Aug/0419.shtml > > > > -- > dwmw2 > > From ssiddiqi@inspirepharm.com Tue Nov 16 08:07:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Tue, 16 Nov 1999 08:07:00 -0000 Subject: FW: Win32 XServer References: <38317C62.BA079077@ibm.net> Message-ID: 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" 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 | > > +---------------------------------------------------------------+ > > From ssiddiqi@inspirepharm.com Tue Nov 16 08:18:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Tue, 16 Nov 1999 08:18:00 -0000 Subject: FW: Win32 XServer References: <38317C62.BA079077@ibm.net> Message-ID: > 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 John, Most of the negative comments about this project are comming from commercial X server vendors for Windows. They had often flamed me on XFree86 developers list. It is understood that their business interests are at stake, if we could succeed in having xfree86 for Win32. Free86 server for Linux has kept commercial X servers prices under control. A while ago, one xfree86 developer on xfree86 list mentioned that a xfree86 for Win32 may make several X server vendors for Windows go out of business or force them to sell their product for 50 bucks like they do for Linux. Commercial X server vendors have a tremendous interest in xfree86.org and a few of them try to impose their will. Last month when some x servers developers flamed the xygwin-xfree project on xfree86 developers list, I responded that we would continue to develop and distribute binaries plus code, even xfree86.org refuses to accept our patches. Suhaib From mmacdona@tsi.gte.com Wed Nov 17 08:27:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 17 Nov 1999 08:27:00 -0000 Subject: FW: Win32 XServer Message-ID: Alot of people out there telling us it can't be done.. That REALLY pisses me off.. Anyway, theres a setruid function that I'm missing.. Is it out there, or do I gotta hack one together? I had the same problem with Eterm, I just hacked it out, but I don't know that I want to go around mindlessly hacking X code :).. Besides, it might be why Eterm didn't work.. Prolly not, but who knows? /usr/src/xc/programs/Xserver/hw/xfree86/common/xf86Config.c:975: undefined reference to `setruid' /usr/src/xc/programs/Xserver/hw/xfree86/common/xf86Config.c:989: undefined reference to `setruid' -----Original Message----- From: cygwin-xfree-owner@sourceware.cygnus.com [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Suhaib Siddiqi Sent: Tuesday, November 16, 1999 11:14 AM To: John Fortin Cc: Cygwin-Xfree@Sourceware.Cygnus.Com Subject: RE: FW: Win32 XServer > 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 John, Most of the negative comments about this project are comming from commercial X server vendors for Windows. They had often flamed me on XFree86 developers list. It is understood that their business interests are at stake, if we could succeed in having xfree86 for Win32. Free86 server for Linux has kept commercial X servers prices under control. A while ago, one xfree86 developer on xfree86 list mentioned that a xfree86 for Win32 may make several X server vendors for Windows go out of business or force them to sell their product for 50 bucks like they do for Linux. Commercial X server vendors have a tremendous interest in xfree86.org and a few of them try to impose their will. Last month when some x servers developers flamed the xygwin-xfree project on xfree86 developers list, I responded that we would continue to develop and distribute binaries plus code, even xfree86.org refuses to accept our patches. Suhaib From cgf@cygnus.com Wed Nov 17 12:38:00 1999 From: cgf@cygnus.com (Chris Faylor) Date: Wed, 17 Nov 1999 12:38:00 -0000 Subject: FW: Win32 XServer References: Message-ID: <19991117153840.A24231@cygnus.com> On Wed, Nov 17, 1999 at 11:26:56AM -0500, Mike MacDonald wrote: >Alot of people out there telling us it can't be done.. That REALLY pisses >me off.. Anyway, theres a setruid function that I'm missing.. Is it out >there, or do I gotta hack one together? I had the same problem with Eterm, >I just hacked it out, but I don't know that I want to go around mindlessly >hacking X code :).. Besides, it might be why Eterm didn't work.. Prolly >not, but who knows? > >/usr/src/xc/programs/Xserver/hw/xfree86/common/xf86Config.c:975: undefined >reference to `setruid' >/usr/src/xc/programs/Xserver/hw/xfree86/common/xf86Config.c:989: undefined >reference to `setruid' I can't imagine that it would matter in a cygwin application. We don't even have the concept of real and effective UIDs. So maybe you need a '-Dsetruid(x)=0' somewhere? cgf From mmacdona@tsi.gte.com Wed Nov 17 15:26:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Wed, 17 Nov 1999 15:26:00 -0000 Subject: Xserver Message-ID: Ok, I don't think I'll have anything this week as I'd hoped. Mainly this is because I have to have an impacted wisdom tooth removed tommorrow, and I don't think I'll be back in action until monday at the earliest.. From ssiddiqi@inspirepharm.com Wed Nov 17 17:58:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Wed, 17 Nov 1999 17:58:00 -0000 Subject: FW: Win32 XServer References: Message-ID: Ignore all those who said it cannot be done. I know few of them who are saying NO, have some reasons behind it, which I mentioned in my mails yesterday. for now try to hack the setruid. I believe, Corinna Vinschen can give a better advice on it. Suhaib > -----Original Message----- > From: Mike MacDonald [ mailto:mmacdona@tsi.gte.com ] > Sent: Wednesday, November 17, 1999 11:27 AM > To: 'Suhaib Siddiqi' > Cc: 'Cygwin-Xfree@Sourceware.Cygnus.Com' > Subject: RE: FW: Win32 XServer > > > Alot of people out there telling us it can't be done.. That REALLY pisses > me off.. Anyway, theres a setruid function that I'm missing.. Is it out > there, or do I gotta hack one together? I had the same problem > with Eterm, > I just hacked it out, but I don't know that I want to go around mindlessly > hacking X code :).. Besides, it might be why Eterm didn't work.. Prolly > not, but who knows? > > /usr/src/xc/programs/Xserver/hw/xfree86/common/xf86Config.c:975: undefined > reference to `setruid' > /usr/src/xc/programs/Xserver/hw/xfree86/common/xf86Config.c:989: undefined > reference to `setruid' > > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Suhaib > Siddiqi > Sent: Tuesday, November 16, 1999 11:14 AM > To: John Fortin > Cc: Cygwin-Xfree@Sourceware.Cygnus.Com > Subject: RE: FW: Win32 XServer > > > > > > 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 > > > John, > Most of the negative comments about this project are comming from > commercial X server vendors for Windows. > They had often flamed me on XFree86 developers list. It is > understood > that their business interests are at stake, if we could succeed in > having xfree86 for Win32. Free86 server for Linux has kept > commercial X servers prices under control. A while ago, one xfree86 > developer on xfree86 list mentioned that a xfree86 for Win32 may > make several X server vendors for Windows go out of business or > force them to sell their product for 50 bucks like they do for > Linux. Commercial X server vendors have a tremendous interest in > xfree86.org and a few of them try to impose their will. > > Last month when some x servers developers flamed the xygwin-xfree > project on xfree86 developers list, I responded that we would > continue to develop and distribute binaries plus code, even > xfree86.org > refuses to accept our patches. > > Suhaib > From ssiddiqi@inspirepharm.com Wed Nov 17 18:07:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib M. Siddiqi) Date: Wed, 17 Nov 1999 18:07:00 -0000 Subject: Xserver References: Message-ID: Your help is highly appreciated. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Mike > MacDonald > Sent: Wednesday, November 17, 1999 6:26 PM > To: 'cygwin-xfree@sourceware.cygnus.com' > Subject: Xserver > > > Ok, I don't think I'll have anything this week as I'd hoped. > Mainly this is > because I have to have an impacted wisdom tooth removed tommorrow, and I > don't think I'll be back in action until monday at the earliest.. > From KendallB@scitechsoft.com Wed Nov 17 18:47:00 1999 From: KendallB@scitechsoft.com (Kendall Bennett) Date: Wed, 17 Nov 1999 18:47:00 -0000 Subject: FW: Win32 XServer References: Message-ID: <199911171847555.SM00164@kendallb> Mike MacDonald wrote: > Alot of people out there telling us it can't be done.. That > REALLY pisses me off.. If you are referring to my email, I am not trying to tell you it can't done, but rather that it *will* be very difficult to get right. I am not saying this to try and put your down, but simply to elighten you on the problems you will encounter if you try to get direct hardware rendering working under Windows. A lot of people involved in this project have been looking over at the OS/2 port of XFree86, and saying 'Hey, if OS/2 can do it, so can Windows!'. Unfortunately OS/2 has some key underlying architectural differences that enable XFree86/2 to work seamlessly. This is specifically the ability for an OS/2 console program to run in a fullscreen session, and the OS/2 PM *expects* it to take over complete control of the graphics hardware (and also allows it implement a save/restore on it's state before switch to and from PM). Windows simply does not support that (we invented something similar many years ago called 'WinDirect' for games, but due to badly written Windows display drivers it does not work reliably, and is only for Windows 9x not NT). The fundamental problem with trying to use Direct hardware rendering under Windows is that the Windows drivers do not expect *any* other program in the system to be directly controlling the graphics hardware. Although it may sound like 'DirectX' allows this, in reality it doesn't. What it does do is provide an abstraction later with more game oriented functions for faster bitmap blitting, and a pointer to the framebuffer surface so you can do your own custom rendering. DirectX does not expect the programmer to directly program the hardware 2D or 3D engines on the graphics card, which is what using the XF86_SVGA server entails. I am also speaking from painful experience here, because we do similar things in some of our products (not X-server products, but game related ones). We have managed to get it working for a small subset of functions, but given the countless hours we have spent tuning our code to 'coexist' properly with specific cards and specific drivers, it would be a huge task to do the same for the existing XFree86 direct rendering code. However once again I want to stress that I am not saying that an X- server for Win32 can't be done. It certainly can, but a more fruitful approach to this problem is the following: 1. Forget about trying to get XF86_SVGA working direct to hardware (at least initially; go back and try later if you really wish). 2. Don't try to directly program the hardware for graphics, mouse or keyboard. Instead write the proper OS support functions for the X event mechanims that talk to the Win32 event mechanism and/or DirectInput. 3. Start out with an unaccelerated server (you can base it on XF86_SVGA since the framework is all there), that uses DirectDraw to draw directly on the video memory surface. 4. Use smart surface locks around the highest level primitives possible (by smart I mean use a reference counter so you can avoid a re-lock if the surface was already locked by a higher level primitive). 5. When the above all works, you can then use the DirectDraw BitBlt functions to do solid blits, transparent blits and solid color fills to get some form of acceleration. The blits and color fills will make a *huge* difference, and at that point you will have a *very* useable server. 6. To make things faster, you can use GDI to draw on the primary surface which would allow you to accelerate text, line drawing and pattern fills. 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 | +---------------------------------------------------------------+ From KendallB@scitechsoft.com Wed Nov 17 18:47:00 1999 From: KendallB@scitechsoft.com (Kendall Bennett) Date: Wed, 17 Nov 1999 18:47:00 -0000 Subject: FW: Win32 XServer References: <38317C62.BA079077@ibm.net> Message-ID: <199911171846902.SM00164@kendallb> "Suhaib Siddiqi" wrote: > > 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 > > Most of the negative comments about this project are comming from > commercial X server vendors for Windows. They had often flamed me > on XFree86 developers list. I have to say that I do not agree with the above comment, at least to the extent that commercial vendors have flamed you on the XFree86 developer list because their interests are at stake (you may well have been flamed in private email). If you are thinking of my responses to the project on the list, I have no problem with XFree86 being ported to the Win32 platform (in fact I encourage it). We are looking to enter that market eventually, but right now we don't have a product and I personally would find such as XFree86 server very useful. > It is understood that their business interests are at stake, if we > could succeed in having xfree86 for Win32. Free86 server for Linux > has kept commercial X servers prices under control. A while ago, > one xfree86 developer on xfree86 list mentioned that a xfree86 for > Win32 may make several X server vendors for Windows go out of > business or force them to sell their product for 50 bucks like they > do for Linux. Can you dig up that email? I follow the XFree86 developer list quite extensively and I don't ever recall such a conversation. I do recall a number of non-Win32 developers saying that a fullscreen only solution would be useless; something I disagree with also. > Commercial X server vendors have a tremendous interest in > xfree86.org and a few of them try to impose their will. I imagine that the XFree86 BOD would have quite a laugh at the above. I don't know of any commercial X server vendor who has *any* pull over the XFree86 sources, nor tries to impose their will on the project. If you think otherwise you are misinformed. 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 | +---------------------------------------------------------------+ From KendallB@scitechsoft.com Wed Nov 17 18:47:00 1999 From: KendallB@scitechsoft.com (Kendall Bennett) Date: Wed, 17 Nov 1999 18:47:00 -0000 Subject: FW: XF86SUP.SYS References: Message-ID: <199911171847183.SM00164@kendallb> Mike MacDonald 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 | +---------------------------------------------------------------+ From fortinj@ibm.net Wed Nov 17 19:52:00 1999 From: fortinj@ibm.net (John Fortin) Date: Wed, 17 Nov 1999 19:52:00 -0000 Subject: FW: XF86SUP.SYS References: <199911171847183.SM00164@kendallb> Message-ID: <38337A55.1BAF8905@ibm.net> Hi Kendall, Thanks for the responses. I've been looking at this mostly from another viewpoint. The work I have been doing is creating a DirectX interface for GGI, and then be able to run XGGI from that. I have gotten almost all the GGI functionality working under Full-screen DX. However, I believe that Mike can take the libraries I have written, and interface them. Including setting the mode and pixel depth. It is also a double buffer system, drawing to the back surface and then blitting to the primary surface on a timer ( ~ 15-20 FPS). If the server is not in the foreground, it only draws on the backing surface, with no blit. There is much more to be done, including (possible??) using the 3d primitives in a 2d fashion and gaining the hardware accel there. The only part I really have left is the keyboard/mouse interface (using Direct Input, of course). Then (sigh) testing... Of course, Suhaib did all the hard work by getting the X libs ported. John Kendall Bennett wrote: > > Mike MacDonald 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 | > +---------------------------------------------------------------+ From fortinj@ibm.net Wed Nov 17 20:07:00 1999 From: fortinj@ibm.net (John Fortin) Date: Wed, 17 Nov 1999 20:07:00 -0000 Subject: [Fwd: FW: Win32 XServer] Message-ID: <38337DCB.AFE0BE66@ibm.net> John Fortin wrote: > > > 1. Forget about trying to get XF86_SVGA working direct to hardware > > (at least initially; go back and try later if you really wish). > > Agreed.. > > > > > 2. Don't try to directly program the hardware for graphics, mouse or > > keyboard. Instead write the proper OS support functions for the X > > event mechanims that talk to the Win32 event mechanism and/or > > DirectInput. > > Mostly done > > > > 3. Start out with an unaccelerated server (you can base it on > > XF86_SVGA since the framework is all there), that uses DirectDraw > > to draw directly on the video memory surface. > > Well, back buffer, then blit to primary. back buffer is created in > user memory with a constant pointer so I don't have to lock the backing > surface... Only the primary gets locked during the blit. > > > 4. Use smart surface locks around the highest level primitives > > possible (by smart I mean use a reference counter so you can > > avoid a re-lock if the surface was already locked by a higher > > level primitive). > > Probably not needed. See above > > > > 5. When the above all works, you can then use the DirectDraw BitBlt > > functions to do solid blits, transparent blits and solid color > > fills to get some form of acceleration. The blits and color fills > > will make a *huge* difference, and at that point you will have a > > *very* useable server. > > To be done at a later time.. > > > > > 6. To make things faster, you can use GDI to draw on the primary > > surface which would allow you to accelerate text, line drawing > > and pattern fills. > > Personally, I don't like using the GDI. Since I have a buffer I can > access, I would almost rather use home-grown utilities. However, I > am not unwilling to be persuaded... > > John From KendallB@scitechsoft.com Wed Nov 17 21:05:00 1999 From: KendallB@scitechsoft.com (Kendall Bennett) Date: Wed, 17 Nov 1999 21:05:00 -0000 Subject: (Fwd) Re: FW: Win32 XServer Message-ID: <199911172104745.SM00164@kendallb> Forwarded message: From: Self To: John Fortin Subject: Re: FW: Win32 XServer Date: Wed, 17 Nov 1999 21:04:16 -0800 Hi John, > > 1. Forget about trying to get XF86_SVGA working direct to hardware > > (at least initially; go back and try later if you really wish). > > Agreed.. Well that is a relief. It seems to me that Suhaib is hell bent on getting XF86_SVGA to run natively under Win32 like it does on OS/2. A noble goal but a fruitless one given the bad design of Windows. > > 2. Don't try to directly program the hardware for graphics, mouse or > > keyboard. Instead write the proper OS support functions for the X > > event mechanims that talk to the Win32 event mechanism and/or > > DirectInput. > > Mostly done Excellent. Sounds like you guys are coming a long way. Can you build this stuff without Cygwin, or does it still rely on Cygwin for it's Unix'isms? > > 3. Start out with an unaccelerated server (you can base it on > > XF86_SVGA since the framework is all there), that uses > > DirectDraw to draw directly on the video memory surface. > > Well, back buffer, then blit to primary. back buffer is created > in user memory with a constant pointer so I don't have to lock the > backing surface... Only the primary gets locked during the blit. The performance of such a server will not be what you would wish, due to the fact that all the blitting from system memory to video memory will be done in software. Hence the performance hit would be quite large (especially if screen->screen and solid fills are done with DirectX primitives to the framebuffer). If you do your locking right, you should have no problem rendering directly to the framebuffer. Disregard what the DirectX docs tell you about this; unless you are doing blending and need high speed framebuffer reads, direct framebuffer writes will be faster. Also note that if the performance issue is a problem, the XFree86 server has a 'shadow buffer' mechanism built right in, so you can choose to have all drawing done to a system memory buffer at runtime (ie: then you can profile which is faster and choose the best one). > > 5. When the above all works, you can then use the DirectDraw BitBlt > > functions to do solid blits, transparent blits and solid color > > fills to get some form of acceleration. The blits and color fills > > will make a *huge* difference, and at that point you will have a > > *very* useable server. > > To be done at a later time.. Once you get the basic stuff working, adding screen->screen blits and solid fills will be very easy. The performance benefit would also be very much worth it. > > 6. To make things faster, you can use GDI to draw on the primary > > surface which would allow you to accelerate text, line drawing > > and pattern fills. > > Personally, I don't like using the GDI. Since I have a buffer I > can access, I would almost rather use home-grown utilities. > However, I am not unwilling to be persuaded... The main issue here with using GDI is that you will get access to some stuff that can be accelerated in the graphics hardware, that you can't access via DirectX services. Using GDI for drawing lines will beat the pants of any software line drawing function (assuming you are rendering direct to the framebuffer). Text, lines and pattern fills will be the things you can speed up big time this way. Other stuff you can do in software using XAA... 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 | +---------------------------------------------------------------+ From ssiddiqi@inspirepharm.com Thu Nov 18 03:51:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Thu, 18 Nov 1999 03:51:00 -0000 Subject: [Fwd: FW: Win32 XServer] References: <38337DCB.AFE0BE66@ibm.net> Message-ID: I noticed a lot of suggestions from Kendall. My understanding is John and Mike had been taking the same approaches. I also do not accept the idea of GDI. It is too slow and not good for any X server. As far as DirectX is concerned, I would rather leave this topic to our exerts (John and Mike). I am very confident they would do excellent job. To answer about negativity... I forgot to mention also a few private e-mails addressed to me which suggested XFree86 would not work on Win32 because it is written for UNIX therefore we would be wasting our time. Any how this is off topic now. Let's get XFree86 working on Windows. Without Cygwin it certainly would not have been possible to port the code in xc/programs/Xserver/hw to Win32. Suhaib > > > > > 1. Forget about trying to get XF86_SVGA working > direct to hardware > > > (at least initially; go back and try later if you > really wish). > > > > Agreed.. > > > > > > > > 2. Don't try to directly program the hardware for > graphics, mouse or > > > keyboard. Instead write the proper OS support > functions for the X > > > event mechanims that talk to the Win32 event > mechanism and/or > > > DirectInput. > > > > Mostly done > > > > > > 3. Start out with an unaccelerated server (you can base it on > > > XF86_SVGA since the framework is all there), that > uses DirectDraw > > > to draw directly on the video memory surface. > > > > Well, back buffer, then blit to primary. back > buffer is created in > > user memory with a constant pointer so I don't have to > lock the backing > > surface... Only the primary gets locked during the blit. > > > > > 4. Use smart surface locks around the highest level > primitives > > > possible (by smart I mean use a reference counter > so you can > > > avoid a re-lock if the surface was already locked > by a higher > > > level primitive). > > > > Probably not needed. See above > > > > > > 5. When the above all works, you can then use the > DirectDraw BitBlt > > > functions to do solid blits, transparent blits > and solid color > > > fills to get some form of acceleration. The blits > and color fills > > > will make a *huge* difference, and at that point > you will have a > > > *very* useable server. > > > > To be done at a later time.. > > > > > > > > 6. To make things faster, you can use GDI to draw on > the primary > > > surface which would allow you to accelerate text, > line drawing > > > and pattern fills. > > > > Personally, I don't like using the GDI. Since I > have a buffer I can > > access, I would almost rather use home-grown > utilities. However, I > > am not unwilling to be persuaded... > > > > John > From ssiddiqi@inspirepharm.com Thu Nov 18 04:03:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Thu, 18 Nov 1999 04:03:00 -0000 Subject: (Fwd) Re: FW: Win32 XServer References: <199911172104745.SM00164@kendallb> Message-ID: > Forwarded message: > From: Self > To: John Fortin > Subject: Re: FW: Win32 XServer > Date: Wed, 17 Nov 1999 21:04:16 -0800 > > Hi John, > > > > 1. Forget about trying to get XF86_SVGA working > direct to hardware > > > (at least initially; go back and try later if you > really wish). > > > > Agreed.. > > Well that is a relief. It seems to me that Suhaib is hell bent on > getting XF86_SVGA to run natively under Win32 like it > does on OS/2. A > noble goal but a fruitless one given the bad design of Windows. That what Mike and John refered to as negativve attitude. As I suggested that instead of keep telling volunteer FRUITLESS efforts, why not contribute. If I would not have taken a "hell bent on getting XF86_SVGA to run on Win32" atitude, XFree86 porting project would never had been started. My concept of doing a XF86 port along the line of Holger's approach might be totally wrong, but someone needs to prove me wrong by contributing, not by negative comments. > > > > 2. Don't try to directly program the hardware for > graphics, mouse or > > > keyboard. Instead write the proper OS support > functions for the X > > > event mechanims that talk to the Win32 event > mechanism and/or > > > DirectInput. > > > > Mostly done > > Excellent. Sounds like you guys are coming a long way. > Can you build > this stuff without Cygwin, or does it still rely on > Cygwin for it's > Unix'isms? Please note the name of project "CYGWIN-XFREE". Not sure why you are so much opposed to Cygwin. It is a marvelous tool. Now even Exceed supports Cygwin for X developers Kit (Exceed XDK). I prefer to take a step by step approach. Non-cygwin support MIGHT be added later on. I have already supplied you patches for libraries and clients for MSVC. This should allow developers to X develop products without using cygwin1.dll. > > > > 3. Start out with an unaccelerated server (you can > base it on > > > XF86_SVGA since the framework is all there), that uses > > > DirectDraw to draw directly on the video memory surface. > > > > Well, back buffer, then blit to primary. back > buffer is created > > in user memory with a constant pointer so I don't have > to lock the > > backing surface... Only the primary gets locked during > the blit. > > The performance of such a server will not be what you > would wish, due > to the fact that all the blitting from system memory to > video memory > will be done in software. Hence the performance hit would > be quite > large (especially if screen->screen and solid fills are done with > DirectX primitives to the framebuffer). Mike's idea is to have an unaccelerated server working first. This would be a test-case and would allow us to make further progress. I agree with Mike. It is a very approach. > > If you do your locking right, you should have no problem > rendering > directly to the framebuffer. Disregard what the DirectX > docs tell you > about this; unless you are doing blending and need high speed > framebuffer reads, direct framebuffer writes will be faster. > > Also note that if the performance issue is a problem, the XFree86 > server has a 'shadow buffer' mechanism built right in, so you can > choose to have all drawing done to a system memory buffer > at runtime > (ie: then you can profile which is faster and choose the > best one). > > > > 5. When the above all works, you can then use the > DirectDraw BitBlt > > > functions to do solid blits, transparent blits > and solid color > > > fills to get some form of acceleration. The blits > and color fills > > > will make a *huge* difference, and at that point > you will have a > > > *very* useable server. > > > > To be done at a later time.. > > Once you get the basic stuff working, adding > screen->screen blits and > solid fills will be very easy. The performance benefit > would also be > very much worth it. > We would certainly look into it, but first have at least one X-server working. Suhaib > > > 6. To make things faster, you can use GDI to draw on > the primary > > > surface which would allow you to accelerate text, > line drawing > > > and pattern fills. > > > > Personally, I don't like using the GDI. Since I > have a buffer I > > can access, I would almost rather use > home-grown utilities. > > However, I am not unwilling to be persuaded... > > The main issue here with using GDI is that you will get access to > some stuff that can be accelerated in the graphics > hardware, that you > can't access via DirectX services. Using GDI for drawing > lines will > beat the pants of any software line drawing function > (assuming you > are rendering direct to the framebuffer). Text, lines and pattern > fills will be the things you can speed up big time this > way. Other > stuff you can do in software using XAA... > > 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 | > +---------------------------------------------------------------+ > From fortinj@ibm.net Thu Nov 18 04:37:00 1999 From: fortinj@ibm.net (John Fortin) Date: Thu, 18 Nov 1999 04:37:00 -0000 Subject: [Fwd: (Fwd) Re: FW: Win32 XServer] Message-ID: <3833F55C.194A9DFF@ibm.net> John Fortin wrote: > > > > > 3. Start out with an unaccelerated server (you can base it on > > > > XF86_SVGA since the framework is all there), that uses > > > > DirectDraw to draw directly on the video memory surface. > > > > > > Well, back buffer, then blit to primary. back buffer is created > > > in user memory with a constant pointer so I don't have to lock the > > > backing surface... Only the primary gets locked during the blit. > > > > The performance of such a server will not be what you would wish, due > > to the fact that all the blitting from system memory to video memory > > will be done in software. Hence the performance hit would be quite > > large (especially if screen->screen and solid fills are done with > > DirectX primitives to the framebuffer). > > The biggest problem I had with my initial design using the primary > surface only was this... > If I do a context switch, the video memory get cleared, and there was > not a way to redraw. Restoring the surface does not restore what was on > the surface... I chose the user-memory/blit method in order to keep the > display-memory, and let the server "draw" during the while in the > background. I've asked about this on the Direct-X maillist and > user-groups. > > Hmmm, One thing I don't know though. Will xfree86 itself recover from > a context switch, and restore > the surface itself? > > John From ssiddiqi@inspirepharm.com Thu Nov 18 04:45:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Thu, 18 Nov 1999 04:45:00 -0000 Subject: [Fwd: (Fwd) Re: FW: Win32 XServer] References: <3833F55C.194A9DFF@ibm.net> Message-ID: > > Hmmm, One thing I don't know though. Will > xfree86 itself recover from > > a context switch, and restore > > the surface itself? > > > > John > Hi John, I am not sure that xfree86 could. Let's see what Kendall Benett says, if he is reading this message. Suhaib From sos@prospect.com.ru Thu Nov 18 05:32:00 1999 From: sos@prospect.com.ru (Sergey Okhapkin) Date: Thu, 18 Nov 1999 05:32:00 -0000 Subject: FW: Win32 XServer Message-ID: <000a01bf31c9$2dd8e580$02af6080@sokhapki-2.cc.bellcore.com> > 1. Forget about trying to get XF86_SVGA working direct to hardware > (at least initially; go back and try later if you really wish). > > 2. Don't try to directly program the hardware for graphics, mouse or > keyboard. Instead write the proper OS support functions for the X > event mechanims that talk to the Win32 event mechanism and/or > DirectInput. > I wrote the same more than year ago... _XFREE86_ is not a good candidate for win32 port. Sergey Okhapkin, http://www.lexa.ru/sos Piscataway, NJ From KendallB@scitechsoft.com Thu Nov 18 08:30:00 1999 From: KendallB@scitechsoft.com (Kendall Bennett) Date: Thu, 18 Nov 1999 08:30:00 -0000 Subject: (Fwd) Re: FW: Win32 XServer References: <3833F53E.F5ABD4A6@ibm.net> Message-ID: <199911180829253.SM00164@kendallb> Hi John, > The biggest problem I had with my initial design using the > primary surface only was this... If I do a context switch, the video > memory get cleared, and there was not a way to redraw. XFree86 already has mechanisms internally to handle this, as under Linux the user can switch away with a VT switch. I do believe that when the VT switch returns the server will request all windows to repaint themselves, which is exactly what you need. I will ask around on the XFree86 developer list and let you know what I find out. > Restoring the surface does not restore what was on the surface... I > chose the user-memory/blit method in order to keep the > display-memory, and let the server "draw" during the while in the > background. I've asked about this on the Direct-X maillist and > user-groups. Right. But note that when the server is switched away from under Linux, the drawing simply goes nowhere and hence a repaint is required in order to 'switch back' to the server. Same goes for under OS/2. Hence doing the switch with a repaint should be perfectly possible. > Hmmm, One thing I don't know though. Will xfree86 itself recover > from a context switch, and restore the surface itself? Yes, I believe so if you put the code to handle lost surfaces into the VT switch stuff. It may get tricky to figure out how to do this, but it should be doable. When you are doing rendering with DirectX, you can easily find when the surface gets switched away from because you will lose the surface and then any subsequent Lock() calls will fail (and hence you need to be able to flag the VT switch, bail out and don't draw anything to the screen). Note however that there are back door methods you can use to get 'into' the system that DirectX uses to handle focus switching, so that you can know in advance before the switch happens. This will make it cleaner to handle the switching before you get down to any of the rendering loops. I have code to do this in our MGL graphics library, and it works 100% under Windows 9x and about 95% under NT (under NT you can't trap into the Ctrl-Alt-Del mechanism, so you lose your surfaces so you still need the original code to deal with lost surfaces). If you get the rest of the stuff working, I will be more than willing to help out cleaning this stuff up further down the track. I have done this type of thing tons of times before (I wrote the code that Quake uses for this stuff, as WinQuake is based on our MGL graphics library ;-). 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 | +---------------------------------------------------------------+ From KendallB@scitechsoft.com Thu Nov 18 09:23:00 1999 From: KendallB@scitechsoft.com (Kendall Bennett) Date: Thu, 18 Nov 1999 09:23:00 -0000 Subject: FW: XF86SUP.SYS References: <38337A55.1BAF8905@ibm.net> Message-ID: <199911180923773.SM00164@kendallb> John Fortin wrote: > Thanks for the responses. I've been looking at this mostly from > another viewpoint. The work I have been doing is creating a > DirectX interface for GGI, and then be able to run XGGI from that. > I have gotten almost all the GGI functionality working under > Full-screen DX. Once you get that going, it would make sense to try and merge the GGI stuff directly into the server. Specifically you will want to try and eliminate the function call overheads to the GGI layers if they are being called from any of the actual drawing code. However I do believe this is the best approach to getting this working. The GGI driver is a chipset driver, and already has all the direct hardware support stripped out of it. > However, I believe that Mike can take the libraries I have > written, and interface them. Including setting the mode and pixel > depth. Yep, it should be possible to do that. > There is much more to be done, including (possible??) using the 3d > primitives in a 2d fashion and gaining the hardware accel there. That is a possibility, but not everyone has a 3D accelerator (although it these days most people do ;-). That is one way that you can get access to hardware lines via DirectX, but the 3D stuff won't allow you to do hardware pattern fills or text (something that is still missing from DirectDraw). However DirectX 8.0 has a lot of this stuff coming down the pipe, as MS is trying to integrate the functionality of DirectX and GDI for their new GDI 2K stuff. > The only part I really have left is the keyboard/mouse interface > (using Direct Input, of course). A couple of people have already mentioned that Win32 versions of the X input handling stuff already exists in a few places. Perhaps using their code can get that done quickly. 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 | +---------------------------------------------------------------+ From KendallB@scitechsoft.com Thu Nov 18 09:23:00 1999 From: KendallB@scitechsoft.com (Kendall Bennett) Date: Thu, 18 Nov 1999 09:23:00 -0000 Subject: (Fwd) Re: FW: Win32 XServer References: <199911172104745.SM00164@kendallb> Message-ID: <199911180923554.SM00164@kendallb> "Suhaib Siddiqi" wrote: > > Well that is a relief. It seems to me that Suhaib is hell bent on > > getting XF86_SVGA to run natively under Win32 like it > > does on OS/2. A > > noble goal but a fruitless one given the bad design of Windows. > > That what Mike and John refered to as negativve attitude. As I have said before, if you want to go ahead and try doing this, be my guest. The *reason* I am telling you that it is fruitless effort is because you *will* have major compatibility problems, and it may not be possible to even solve them all. I am not trying to take a negative attitude, but rather steer you all in the right direction. I would hate to see someone spend months trying to get this thing working, only to discover that the compatibility problems really are insurmountable and hence have to throw away all that hard work. I know all this because I *write* Win32 display drivers (and OS/2, QNX, Linux) for a living. But you know that, because I have told you the same thing on a number of occasions. And just because I write this stuff for a living doesn't mean that I have some ulterior motive and plan to 'steer' you in the wrong direction. > If I would not have taken a "hell bent on getting XF86_SVGA to run > on Win32" atitude, XFree86 porting project would never had been > started. I have said it before, what you have done is great. I have never tried to discount this. It is also a noble goal to try and get XF86_SVGA to run on Win32, but as I said above, making it actually happen is fraught with major compatibility issues. You have already said in the past that you are not an experienced graphics device driver developer, and have been seeking advice from others. I have offered my advice on a number of occasions, but it seems to me that you are not really looking for advice, but rather looking to find someone who will tell you 'sure, I can make this work!'. Perhaps you should read more carefully the responses from so many *experienced* device driver developers. It will be clear that I am not the only one telling you this. Many others have said the same thing, but it seems to me that you simply want to ignore all the good advice people have given you, even after you specifically sought it out! > My concept of doing a XF86 port along the line of Holger's > approach might be totally wrong, but someone needs to prove me > wrong by contributing, not by negative comments. What do you expect me to *contribute* that will make you believe what I am telling you? Do you want me to build the damn thing, come over to your place and demonstrate that it doesn't work?? You have already demonstrated to yourself that it doesn't work, because the XF86_SVGA.EXE you have built does nothing but crash your machine hard. I don't have the time right now to contribute with code, so I am trying to help by contributing my expertise. One day I hope to have more time to actually contribute some code, but at the moment I don't have that luxury. > Please note the name of project "CYGWIN-XFREE". Not sure why you > are so much opposed to Cygwin. It is a marvelous tool. I have nothing against Cygwin. I just don't use it as my primary development tool. When I do end up contributing to this project, part of that contribution will be to build it all with Visual C++ or Watcom C++, because that is what I use. > I prefer to take a step by step approach. Non-cygwin support > MIGHT be added later on. I have already supplied you patches for > libraries and clients for MSVC. This should allow developers to X > develop products without using cygwin1.dll. Sure. I understand all the above. I was simply asking if that stuff had been done yet. All you have to say is 'no, not yet'. 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 | +---------------------------------------------------------------+ From KendallB@scitechsoft.com Thu Nov 18 09:24:00 1999 From: KendallB@scitechsoft.com (Kendall Bennett) Date: Thu, 18 Nov 1999 09:24:00 -0000 Subject: [Fwd: FW: Win32 XServer] References: <38337DCB.AFE0BE66@ibm.net> Message-ID: <199911180923865.SM00164@kendallb> "Suhaib Siddiqi" wrote: > I noticed a lot of suggestions from Kendall. My understanding is > John and Mike had been taking the same approaches. Sure, except for that fact that some people still seem bent on the idea of getting XF86_SVGA to program the hardware directly under Win32. Doing so will be a fruitless task due to the major compatbility issues that will ensue. The whole thrust of my posts has been to forget about doing that (at least for now), and get a good DirectX based server up and running. > I also do not accept the idea of GDI. It is too slow and not good > for any X server. I tried to make this clear in my other posts, but I will re-iterate this again: 1. GDI *and* DirectDraw *can* be used at the same time for the primary surface under DirectX. Since the X-server will not be flipping this should be perfectly possible. 2. DirectDraw can be used for some stuff, but not everything is available. Specifically DirectDraw does not support hardware line drawing, hardware pattern fills or hardware text. 3. GDI can be used for those specific functions that can't be accelerated by DirectDraw, and those functions *will* use the hardware. Using the GDI line, pattern fill and text functions will blow away any software implementation (sure it won't be as fast as if you had native code from the XF86_SVGA server, but it will be faster than software). > As far as DirectX is concerned, I would rather leave this topic to > our exerts (John and Mike). I am very confident they would do > excellent job. I am sure they will do a excellent job. However I resent the insinuation that I don't know what I am talking about when it comes to DirectX. I know what I am talking about because I had done all of the DirectX code in our SciTech MGL graphics library; the same library that was used to port Quake to Windows, and has been used in countless commercial games on the Windows platform. Perhaps actually *listening* to what I have to say would help you get to the ultimate goal of a working DirectX based X-sever in a more timely manner? > Without Cygwin it certainly would not have been possible to port > the code in xc/programs/Xserver/hw to Win32. Sure. But another thrust of my posts is that the code under that directory is not useful for the Win32 port anyway. Getting XF86_SVGA to compile is not a useful task, because getting it to work is fraught with major compatibility problems. I think you have already found that it simply won't work out of the box, given that you have already gotten it compiling and linking. 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 | +---------------------------------------------------------------+ From ssiddiqi@inspirepharm.com Thu Nov 18 09:45:00 1999 From: ssiddiqi@inspirepharm.com (Suhaib Siddiqi) Date: Thu, 18 Nov 1999 09:45:00 -0000 Subject: [Fwd: FW: Win32 XServer] References: <199911180923865.SM00164@kendallb> Message-ID: Kendall, Thanks for participating and exchanging your experience. Your comments are well accepted. I leave the aspect of devices drivers with John and Mike. They have volunteer to work on it. How they want to do it is totaly their choice. I am already gratefull to them for offering their expert help and efforts to make cygwin-xfree project a successfull. Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On > Behalf Of Kendall > Bennett > Sent: Thursday, November 18, 1999 12:25 PM > To: cygwin-xfree@sourceware.cygnus.com > Subject: RE: [Fwd: FW: Win32 XServer] > > > "Suhaib Siddiqi" wrote: > > > I noticed a lot of suggestions from Kendall. My > understanding is > > John and Mike had been taking the same approaches. > > Sure, except for that fact that some people still seem > bent on the > idea of getting XF86_SVGA to program the hardware directly under > Win32. Doing so will be a fruitless task due to the major > compatbility issues that will ensue. The whole thrust of > my posts has > been to forget about doing that (at least for now), and > get a good > DirectX based server up and running. > > > I also do not accept the idea of GDI. It is too slow > and not good > > for any X server. > > I tried to make this clear in my other posts, but I will > re-iterate > this again: > > 1. GDI *and* DirectDraw *can* be used at the same time for the > primary surface under DirectX. Since the X-server will not be > flipping this should be perfectly possible. > > 2. DirectDraw can be used for some stuff, but not everything is > available. Specifically DirectDraw does not support hardware line > drawing, hardware pattern fills or hardware text. > > 3. GDI can be used for those specific functions that can't be > accelerated by DirectDraw, and those functions *will* use the > hardware. Using the GDI line, pattern fill and text > functions will > blow away any software implementation (sure it won't be > as fast as if > you had native code from the XF86_SVGA server, but it > will be faster > than software). > > > As far as DirectX is concerned, I would rather leave > this topic to > > our exerts (John and Mike). I am very confident they would do > > excellent job. > > I am sure they will do a excellent job. However I resent the > insinuation that I don't know what I am talking about > when it comes > to DirectX. I know what I am talking about because I had > done all of > the DirectX code in our SciTech MGL graphics library; the same > library that was used to port Quake to Windows, and has > been used in > countless commercial games on the Windows platform. > > Perhaps actually *listening* to what I have to say would > help you get > to the ultimate goal of a working DirectX based X-sever in a more > timely manner? > > > Without Cygwin it certainly would not have been possible to port > > the code in xc/programs/Xserver/hw to Win32. > > Sure. But another thrust of my posts is that the code under that > directory is not useful for the Win32 port anyway. > Getting XF86_SVGA > to compile is not a useful task, because getting it to work is > fraught with major compatibility problems. > > I think you have already found that it simply won't work > out of the > box, given that you have already gotten it compiling and linking. > > 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 | > +---------------------------------------------------------------+ > From ssiddiqi@ipass.net Sat Nov 20 14:39:00 1999 From: ssiddiqi@ipass.net (Suhaib M. Siddiqi) Date: Sat, 20 Nov 1999 14:39:00 -0000 Subject: Re Win32 (was VT switching) Message-ID: > -----Original Message----- > From: owner-devel@XFree86.Org [ mailto:owner-devel@XFree86.Org]On Behalf > Of Keith Packard > Sent: Friday, November 19, 1999 12:55 PM > To: devel@XFree86.Org > Subject: Re: Handling of VT switching? > > Cool. I think the Win32 developers could probably use some expert > > advice on how to get the Win32 event stuff set up. I don't think they > > fully understand events on Win32 or X enough at the moment (I know > > Win32, but not X well enough). Also doesn't the X11R6.4 sources > > already have Win32 event code in it?? Kendall, Thanks for discussing these issues here. I assume that you were refering to Mike, John and me as Win32 developers? Would you please mind cc'ing messages to cygwin-xfree list too, at least for the remaining part of November and December 1999 because I would be out of country on vacations? I willl not have net access during vacations. > > Mouse events are easy (as usual), translating Windows messages into X > events and queuing them. Keyboard events are harder (as always); the best > technique (used by Hummingbird) is to actually build keymaps containing > X keysyms for each supported keyboard and then do a trivial scancode to > X keycode translation within the server. Trying to make this automatic > is fraught with peril. > The Exceed (Hummingbird) keymaps give problems if an application is compiled with GCC under Cygwin. It dumps millions of Xt warnings relating to keymaps. The only work around is to set XKeysymDb and XErrorDB in Windows ENV, and point it to XKeysymDB abd XErrorDB files which comes with XFree86 or X11R6.4, i.e set XKeysymDB=c:\usr\X11R6\lib\X11\XKeysymDB set XErrorDB=c:\usr\X11R6\lib\X11\XErrorDB > And no, X11R6.4 doesn't have Win32 event code in it (at least not > that I've > seen). It does have some (broken) winsock code -- the various hacks > to support winsock's lame select don't work right as the various winsock > fd_set macros aren't functionally equivalent to the regular BSD macros. True, if X11R6.4 is compiled using MSVC the socket support sucks. That was one of the reasons I decided to choose Cygwin, because it allowed me to work around Win32 native lame winsock. Now Cygwin supports AF_UNIX under Win32, which make life easier. > > > BTW, I recall there is a free (albiet not very good) Win32 server > > around somewhere. Does anyone know the URL of this server? > > But no source code, making this rather useless. I don't recall the name > of it, but it ran so few X applications correctly when I tried it that > I quickly discarded it. > That is Mi/X from Microimage and it is no more free. It costs $25.00. On top of that Microimage compares it against Exceed, netmanage, and NCD because it is ceaper. It is still only X11R5 compliant and it can operate only in single Windows mode with stdin/stdout crap. Most of the modern X cleints would not work under MI/X 2.0. Suhaib > From joegi@geocities.com Sat Nov 20 19:05:00 1999 From: joegi@geocities.com (Joel Guerrero) Date: Sat, 20 Nov 1999 19:05:00 -0000 Subject: xterm help Message-ID: <38375BBE.A2AC522F@geocities.com> I'm trying to run xterm but i get this error: warning: locale not supported by C library, locale unchanged warning: X locale modifiers not suported by Xlib, locale set to C Warning: X locale modifiers not suported, using default Failed to open input method xterm: unable to find usable termcap entry. can anyone helpme? Tahnks, Joel GUERRERO __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From ssiddiqi@ipass.net Sat Nov 20 19:21:00 1999 From: ssiddiqi@ipass.net (Suhaib M. Siddiqi) Date: Sat, 20 Nov 1999 19:21:00 -0000 Subject: xterm help References: <38375BBE.A2AC522F@geocities.com> Message-ID: Ignore those messages. These are harmless and should not affect use of xterm. The problem will be fixed, once Xfree86 server works on Win32. Use termcap file which came with your Cygwin v 1.0 CD. The termcap file should be in /usr/etc or /etc Suhaib > -----Original Message----- > From: cygwin-xfree-owner@sourceware.cygnus.com > [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Joel > Guerrero > Sent: Saturday, November 20, 1999 9:41 PM > To: cygwin-xfree@sourceware.cygnus.com > Subject: xterm help > > > I'm trying to run xterm but i get this error: > warning: locale not supported by C library, locale unchanged > warning: X locale modifiers not suported by Xlib, locale set to C > Warning: X locale modifiers not suported, using default > Failed to open input method > xterm: unable to find usable termcap entry. > can anyone helpme? > Tahnks, > Joel GUERRERO > > > __________________________________________________ > Do You Yahoo!? > Bid and sell for free at http://auctions.yahoo.com > From ssiddiqi@ipass.net Sat Nov 20 20:35:00 1999 From: ssiddiqi@ipass.net (Suhaib M. Siddiqi) Date: Sat, 20 Nov 1999 20:35:00 -0000 Subject: Xfree diffs References: <006201bf33d8$cd77db80$4eda6ccb@stargate> Message-ID: ftp://sourceware.cygnus.com/pub/cygwin/xfree and get the file xfree86-3.9.15-cygwin-ss-dev.tar.bz2 3.9.15 in the name is misleading. It is actually 3.9.16b. I uploaded 3.9.16b with 3.9.15 name to overwrite the 3.9.15 archive. Once XFree86 4.0 source code is better organized, I will ppost another patch file, perhaps in January 2000. Suhaib > -----Original Message----- > From: cygwin-owner@sourceware.cygnus.com > [ mailto:cygwin-owner@sourceware.cygnus.com]On Behalf Of Trevor > Sent: Saturday, November 20, 1999 11:28 PM > To: Cygwin > Subject: Xfree diffs > > > Suhaib, > > Is the current cygwin-xfree diffs available for the xfree86 > 3.9.16(a-d) dev > sources. > > Trevor > > > > > > > > -- > Want to unsubscribe from this list? > Send a message to cygwin-unsubscribe@sourceware.cygnus.com > From mmacdona@tsi.gte.com Sat Nov 27 11:09:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Sat, 27 Nov 1999 11:09:00 -0000 Subject: [Fwd: FW: Win32 XServer] Message-ID: Thanks for your comments. I aggree with most everything that you have said. Getting the native X accel drivers up and running directly to the hardware is definately possible, definately not easy, and definately the best way to go. If you look at one of my previous posts you might see some mention of using GDI for its accelerated 2d primitives. Between that, and some assembly routines I have laying around we should be able to come up with some pretty good xaa direct x stuff. However, my thinking is that why not just get something out now that works, and speed it up later. So if you look at my posts you'll see that I want to modify the code in the unaccelerated vga256 driver, and create an XF86_DX that uses completely unaccelerated 2d primitives. The only major change will be to init the screen using DX, and bring back a pointer to a DX surface instead of setting the mode registers directly calling an XF86MapVidMem that maps the memory. At that point (with not much work) we should have a working, unaccelerated, (256 color?) directx server that we can now release. Then we can make sure and raise the color depths, and accelerate certain most used functions. If GDI is faster than software then we use GDI. If we find something else we can use that. I think one thing you have to remember is that DX is just a driver. We can write our own drivers. What we are doing by using DX is accepting that they are doing things well enough already that we don't need to duplicate their efforts. We are also accepting alot of constraints - like having to use a little slower acceleration, and depending on Microsoft to continue supporting DX, and the functions we are using. There is alot to balance here. I personally tipped to DX because I saw how quickly I could put something together (I still plan to directly access the keyboard and mouse amoung other things), and I saw how complicated it could get to get the kind of low level device access we need. In other words - It can be done, it is NOT a fruitless task, there would be NO compatibility issues. There would be issues, and they can be overcome. However, DirectX has (appatently) overcome many of these obstacles for us, and its proven, and its quicker to develop with. On the other hand if we find that DirectX is not suitable for running X, then we will have to look closer at direct hardware access. If you look at some of my previous posts (I was very interactive during my research process) You'll see that those are the conclusions I came to. I do plan to use everything in xc/programs/Xserver/hw - I think it would be a HORRIBLE waiste to throw away alot of good, tested code. Besides using an existing server's code to create the new DX server there is also the keyboard and mouse and pty stuff - John is working on a DX version of this stuff -at least the keyboard and mouse. This is the right way to do things, however it is a long project from what I've heard. I think that I can use some existing drivers for NT and get them to work with Holger's os2 code and get something up and running. I definately forsee us switching our dependence to a direct input final solution there, I don't see us abandoning the os-support stuff completely though, especially for ptys. -----Original Message----- From: cygwin-xfree-owner@sourceware.cygnus.com [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Kendall Bennett Sent: Thursday, November 18, 1999 12:25 PM To: cygwin-xfree@sourceware.cygnus.com Subject: RE: [Fwd: FW: Win32 XServer] "Suhaib Siddiqi" wrote: > I noticed a lot of suggestions from Kendall. My understanding is > John and Mike had been taking the same approaches. Sure, except for that fact that some people still seem bent on the idea of getting XF86_SVGA to program the hardware directly under Win32. Doing so will be a fruitless task due to the major compatbility issues that will ensue. The whole thrust of my posts has been to forget about doing that (at least for now), and get a good DirectX based server up and running. > I also do not accept the idea of GDI. It is too slow and not good > for any X server. I tried to make this clear in my other posts, but I will re-iterate this again: 1. GDI *and* DirectDraw *can* be used at the same time for the primary surface under DirectX. Since the X-server will not be flipping this should be perfectly possible. 2. DirectDraw can be used for some stuff, but not everything is available. Specifically DirectDraw does not support hardware line drawing, hardware pattern fills or hardware text. 3. GDI can be used for those specific functions that can't be accelerated by DirectDraw, and those functions *will* use the hardware. Using the GDI line, pattern fill and text functions will blow away any software implementation (sure it won't be as fast as if you had native code from the XF86_SVGA server, but it will be faster than software). > As far as DirectX is concerned, I would rather leave this topic to > our exerts (John and Mike). I am very confident they would do > excellent job. I am sure they will do a excellent job. However I resent the insinuation that I don't know what I am talking about when it comes to DirectX. I know what I am talking about because I had done all of the DirectX code in our SciTech MGL graphics library; the same library that was used to port Quake to Windows, and has been used in countless commercial games on the Windows platform. Perhaps actually *listening* to what I have to say would help you get to the ultimate goal of a working DirectX based X-sever in a more timely manner? > Without Cygwin it certainly would not have been possible to port > the code in xc/programs/Xserver/hw to Win32. Sure. But another thrust of my posts is that the code under that directory is not useful for the Win32 port anyway. Getting XF86_SVGA to compile is not a useful task, because getting it to work is fraught with major compatibility problems. I think you have already found that it simply won't work out of the box, given that you have already gotten it compiling and linking. 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 | +---------------------------------------------------------------+ From mmacdona@tsi.gte.com Sat Nov 27 11:12:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Sat, 27 Nov 1999 11:12:00 -0000 Subject: [Fwd: (Fwd) Re: FW: Win32 XServer] Message-ID: I saw some code in Holger's stuff that seemed to handle context switches. I'm really interested in this to.. Btw, I'm back.. I had a VERY VERY bad dental experience.. -----Original Message----- From: cygwin-xfree-owner@sourceware.cygnus.com [ mailto:cygwin-xfree-owner@sourceware.cygnus.com]On Behalf Of Suhaib Siddiqi Sent: Thursday, November 18, 1999 7:41 AM To: John Fortin; cygwin-xfree@sourceware.cygnus.com Subject: RE: [Fwd: (Fwd) Re: FW: Win32 XServer] > > Hmmm, One thing I don't know though. Will > xfree86 itself recover from > > a context switch, and restore > > the surface itself? > > > > John > Hi John, I am not sure that xfree86 could. Let's see what Kendall Benett says, if he is reading this message. Suhaib From mmacdona@tsi.gte.com Mon Nov 29 10:59:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Mon, 29 Nov 1999 10:59:00 -0000 Subject: Xfree Message-ID: Ok, I asked for an application to the XFree mailing list.. I'm mosly looking for a little help with source code layout in the hw directory, etc. I think there is a standard there set up for creating new servers, and I don't want to duplicate efforts.. Mainly I need to learn more here.. Like, I can't find where the main() for the Xservers is comming from, and other stupid questions.. From cvpsmith@olemiss.edu Mon Nov 29 18:52:00 1999 From: cvpsmith@olemiss.edu (Paul Smith) Date: Mon, 29 Nov 1999 18:52:00 -0000 Subject: Phigs/PEX development in Cygwin/XF86 Message-ID: <3.0.5.32.19991129205351.007bc800@b122r7> Help! I'm trying to port some software from Linux to Cygwin, and I'm having trouble because (I assume) I need the libphigs.a library ported to Cygwin... What do I need to do? Thanks, Paul Paul Smith cvpsmith@olemiss.edu Center for Computational Hydrosciences & Engineering University of Mississippi From mmacdona@tsi.gte.com Tue Nov 30 14:21:00 1999 From: mmacdona@tsi.gte.com (Mike MacDonald) Date: Tue, 30 Nov 1999 14:21:00 -0000 Subject: TCL/TK Message-ID: Anyone built tcl/tk under cygwin that displays back in X? From noer@cygnus.com Tue Nov 30 15:38:00 1999 From: noer@cygnus.com (Geoffrey Noer) Date: Tue, 30 Nov 1999 15:38:00 -0000 Subject: TCL/TK References: Message-ID: <19991130153832.B26106@cygnus.com> On Tue, Nov 30, 1999, Mike MacDonald wrote: > > Anyone built tcl/tk under cygwin that displays back in X? Yes, I know that this has been done. In specific, someone compiled Insight, our gdbtk graphical layer, with the X version of tcl/tk and then used it to debug Windows apps under linux, setting the display back... -- Geoffrey Noer Email: noer@cygnus.com Cygnus Solutions From sos@prospect.com.ru Tue Nov 30 16:07:00 1999 From: sos@prospect.com.ru (Sergey Okhapkin) Date: Tue, 30 Nov 1999 16:07:00 -0000 Subject: TCL/TK References: <19991130153832.B26106@cygnus.com> Message-ID: <000a01bf3b90$1ddf8320$0201a8c0@SOS> > > Anyone built tcl/tk under cygwin that displays back in X? > > Yes, I know that this has been done. In specific, someone compiled > Insight, our gdbtk graphical layer, with the X version of tcl/tk and > then used it to debug Windows apps under linux, setting the display > back... > Patches to compile X version of tcl/tk are on my web page. Sergey Okhapkin, http://www.lexa.ru/sos Somerset, NJ From juliano@cs.unc.edu Tue Nov 30 16:17:00 1999 From: juliano@cs.unc.edu (Jeffrey Juliano) Date: Tue, 30 Nov 1999 16:17:00 -0000 Subject: TCL/TK References: Message-ID: this belongs on the cygwin mailing list, not the cygwin-xfree list. I'm replying there, too. On Tue, 30 Nov 1999, Mike MacDonald wrote: > Date: Tue, 30 Nov 1999 17:21:34 -0500 > From: Mike MacDonald > To: "'cygwin-xfree@sourceware.cygnus.com'" > Subject: TCL/TK > > Anyone built tcl/tk under cygwin that displays back in X? > search the cygwin archives at http://www.delorie.com/archives/ You can try this search string: tcl +X +libraries perhaps this helps? http://www.delorie.com/archives/browse.cgi?p=cygwin/1999/05/17/10:36:49 -jeff From earnie_boyd@yahoo.com Tue Nov 30 17:54:00 1999 From: earnie_boyd@yahoo.com (Earnie Boyd) Date: Tue, 30 Nov 1999 17:54:00 -0000 Subject: TCL/TK Message-ID: <19991130222833.15803.qmail@web107.yahoomail.com> --- Mike MacDonald wrote: > Anyone built tcl/tk under cygwin that displays back in X? > Yea, at least attempted, but I forget who. Search the archives. ===== Earnie Boyd < mailto:earnie_boyd@yahoo.com > Cygwin Newbies, please visit < http://www.freeyellow.com/members5/gw32/index.html > __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com