new driver help
hi all Hi all I am ready to start my X driver I have copped the /dummy directory And renamed dummy to nvxf to get me started I need to know whear I have To add nvxf to imakefiles and so on ? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Mike A. Harris wrote: > On Fri, 20 Feb 2004, Marc Aurele La France wrote: > > >This thread actually started on [EMAIL PROTECTED] The problem is that gcc's > >broken define conflicts with our driver API. > > ISO C99: > > 7.16 > > Boolean type and values > > 1 The header defines four macros. > 2 The macro bool expands to _Bool. > > > > Which define is broken in gcc exactly? recap: one of his header files has a struct with a field named 'bool'. ncurses' curses.h is including stdbool.h (long story). stdbool.h's bool definition interferes with his header file. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Marc Aurele La France wrote: >This thread actually started on [EMAIL PROTECTED] The problem is that gcc's >broken define conflicts with our driver API. ISO C99: 7.16 Boolean type and values 1 The header defines four macros. 2 The macro bool expands to _Bool. Which define is broken in gcc exactly? -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver
Hi, as I already pointed out some of the users affected by the problem don't want to or aren't able to build XFree86 out of the CVS sources. So I wrote a small hack which wraps around int 0x10 and prevents the function in question (ax=0x5f64, bx=0x0300) from being called. I'm aware that that's a much dirtier solution to the problem than the patched driver but nonetheless I think it might be useful for people who want to use the precompiled XFree86 that came with their distribution. Download URL for 855wrap: http://www.chzsoft.com.ar/855wrap.tar.gz CU Christian -- Christian Zietz - CHZ-Soft - [EMAIL PROTECTED] WWW: http://chzsoft.com.ar/ - Fido: Christian [EMAIL PROTECTED]:2437/74.9 PGP-Key auf Anfrage oder ueber http://wwwkeys.de.pgp.net (Port 11371) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Kelledin wrote: > >> I don't see the original comment on the mail archive - but have the > >> impression that he's trying to use some definition that relies on the > >> bogus "bool" from stdbool.h - So I guess the best recommendation is that > >> he should update to the regular release version of ncurses rather than > >> one > >> of the development versions. > > > > Thanks for responding. > > > > This thread actually started on [EMAIL PROTECTED] The problem is that gcc's > > broken define conflicts with our driver API. > > Well, that's rather debatable. From what I can gather on Google, C99 7.16 > actually allows for stdbool.h and the relevant macros for bool, true, and > false. Of course, it breaks ANSI C89/C90, but as the gcc devs point out, > ANSI C89/C90 code shouldn't be including stdbool.h in the first place. hmm - checking (I do have a copy of C99), you're correct. I only recalled _Bool (and also some comments from google that indicated the original reason for adding the macro had to do with C++), but see that C99 states that "The macro bool expands to _Bool". On the second part - maybe not. The wide-character code is not C89, but uses features from 1996/1998. But iirc, the reason why it's including stdbool.h is to try to iron out whatever problems arise from applications that might include it. > Unfortunately, I don't have a copy of C99 (and can't afford to purchase it > atm), so I'm in no position to argue the finer points. $20US for a PDF > Furthermore, if we applied this "fix", then curses.h would break whenever > it got run through gcc -ansi. > > Perhaps the best solution here is for curses.h to simply not have anything > to do with stdbool.h? (and, of course, put the #undef bool at the end, as > it was in 5.3) perhaps - but (not inclined to argue at this point) will have to research it a little more. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
Marc Aurele La France said: > On Fri, 20 Feb 2004, Thomas Dickey wrote: >> On Fri, 20 Feb 2004, Marc Aurele La France wrote: >> > Anyway, some versions of ncurses #undef bool just after #include'ing >> > . Thomas Dickey, ncurses developer, is on this list, so if >> > he's reading this, he probably has some suggestions. > >> I overlooked the beginning of the thread. stdbool.h is a C99 file, >> which >> is fine. But defining "bool" in that file is a gcc-ism. Both gcc's >> stdbool.h and ncurses.h are trying to solve the same problem (though >> ncurses.h has a more valid reason - "bool" is a documented part of >> X/Open >> curses, gcc is doing it solely as an extension). > >> In current ncurses (5.4), I don't have an undef for bool following >> stdbool.h -- there was an undef in the version from last spring. That >> was >> to work around (no surprise) a conflict on BeOS with inconsistent >> definitions of bool. If gcc hadn't added that definition to stdbool.h >> the >> #undef wouldn't have been needed. > >> I don't see the original comment on the mail archive - but have the >> impression that he's trying to use some definition that relies on the >> bogus "bool" from stdbool.h - So I guess the best recommendation is that >> he should update to the regular release version of ncurses rather than >> one >> of the development versions. > > Thanks for responding. > > This thread actually started on [EMAIL PROTECTED] The problem is that gcc's > broken define conflicts with our driver API. Well, that's rather debatable. From what I can gather on Google, C99 7.16 actually allows for stdbool.h and the relevant macros for bool, true, and false. Of course, it breaks ANSI C89/C90, but as the gcc devs point out, ANSI C89/C90 code shouldn't be including stdbool.h in the first place. Unfortunately, I don't have a copy of C99 (and can't afford to purchase it atm), so I'm in no position to argue the finer points. Furthermore, if we applied this "fix", then curses.h would break whenever it got run through gcc -ansi. Perhaps the best solution here is for curses.h to simply not have anything to do with stdbool.h? (and, of course, put the #undef bool at the end, as it was in 5.3) -- Kelledin "If a server crashes in a server farm and no one pings it, does it still cost four figures to fix?" ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Thomas Dickey wrote: > On Fri, 20 Feb 2004, Marc Aurele La France wrote: > > Anyway, some versions of ncurses #undef bool just after #include'ing > > . Thomas Dickey, ncurses developer, is on this list, so if > > he's reading this, he probably has some suggestions. > I overlooked the beginning of the thread. stdbool.h is a C99 file, which > is fine. But defining "bool" in that file is a gcc-ism. Both gcc's > stdbool.h and ncurses.h are trying to solve the same problem (though > ncurses.h has a more valid reason - "bool" is a documented part of X/Open > curses, gcc is doing it solely as an extension). > In current ncurses (5.4), I don't have an undef for bool following > stdbool.h -- there was an undef in the version from last spring. That was > to work around (no surprise) a conflict on BeOS with inconsistent > definitions of bool. If gcc hadn't added that definition to stdbool.h the > #undef wouldn't have been needed. > I don't see the original comment on the mail archive - but have the > impression that he's trying to use some definition that relies on the > bogus "bool" from stdbool.h - So I guess the best recommendation is that > he should update to the regular release version of ncurses rather than one > of the development versions. Thanks for responding. This thread actually started on [EMAIL PROTECTED] The problem is that gcc's broken define conflicts with our driver API. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 3D support for radeon 9600 pro (ppc)
Sven Luther wrote: On Fri, Feb 20, 2004 at 07:55:27AM -0800, Ian Romanick wrote: Sven Luther wrote: I think that ATI is missing something here. I believe that Powerpc hardware with ATI graphics represent a ever growing linux installed base, with the G5 Powermac, with the new powerbooks, as well as with non-apple powerpc boxes like the pegasos motherboards. But then, it is probably that the ATI drivers are not endian clean, and that they can't be bothered to make a powerpc build, even an unsupported one, probably because of that, or maybe for some hidden reason like the intel-ATI connection or something such. Even if it is "ever growing", it probably still only represents 1% of 1% of their total market. It would take some pretty extreme dedication to the Linux movment to make a business case to devote even an single engineer to that cause. :( Whatever. The truth is that outside of x86, there is actually not a single graphic card vendor with recent graphic card which provide 3D driver support. Until something changes, this mean the death of 3D support on non x86 linux. Agreed. And then, seriously, do you believe it it will need a full time engineer to make a powerpc build ? If the drivers were endian clean, then it would only be a matter of launching a build, and track the occasional arch related problem. Hell, if a volunteer project can make it, why can't ATI ? And i would do it, if ATI would give me access to the needed sources, under strong NDA or whatever, i would build their drivers, but they don't want to. Chances of Nvidia releasing powerpc binaries are worse even, altough it is possible that their drivers are more endianess clean, if they share the code with the OS X driver, which i know ATI does not. I think the endianess issue is minor. There's probably lots of assembly code in various parts of the driver. The driver may also have some software fallback cases for vertex programs that generate x86 machine code instead of code for the GPU (pure speculation). If the driver was not written with other architectures in mind, it is very likely that there's way more to it than just kicking off a build. The only real hope is that ATI will release the R300 specs once the R400 is released, but even there, i only half believe it. Agreed 100% on both counts. :( ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Kelledin wrote: > Thomas Dickey said: > > I don't see the original comment on the mail archive - but have the > > impression that he's trying to use some definition that relies on the > > bogus "bool" from stdbool.h - So I guess the best recommendation is that > > he should update to the regular release version of ncurses rather than one > > of the development versions. > > Well, just to bring everyone up to speed...the problem we face is that > XFree86 defines a union type called ValueUnion, and names one of the union > fields "bool". Obviously this wasn't really a great idea. It bites us > now because ncurses 5.4 includes , which defines the bool type, > which confuses the hell out of gcc when it hits the ValueUnion typedef. :( ok (at least we're current). > The simple answer would be to change the ValueUnion field name to "xbool" > or the like. The problem is, this naming snafu has become part of a > publicly documented API for XFree86 driver development. "bool" is a keyword in C++, and is a bad choice for a variable name (even if the compiler can keep it distinct). > IMO modifying ncurses would only be a temporary fix, good only until the > next system header decides it needs . > > BTW--"regular version" of ncurses? Is 5.4 a stable release or not? FWIW > I pulled it off ftp.gnu.org...if it's "unstable", it ought to be taken > down from there and put on alpha.gnu.org. no. I was referring obliquely to various packagers' pulling patches from my development area and releasing them (ftp://invisible-island.net/ncurses/). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
Thomas Dickey said: > I don't see the original comment on the mail archive - but have the > impression that he's trying to use some definition that relies on the > bogus "bool" from stdbool.h - So I guess the best recommendation is that > he should update to the regular release version of ncurses rather than one > of the development versions. Well, just to bring everyone up to speed...the problem we face is that XFree86 defines a union type called ValueUnion, and names one of the union fields "bool". Obviously this wasn't really a great idea. It bites us now because ncurses 5.4 includes , which defines the bool type, which confuses the hell out of gcc when it hits the ValueUnion typedef. :( The simple answer would be to change the ValueUnion field name to "xbool" or the like. The problem is, this naming snafu has become part of a publicly documented API for XFree86 driver development. IMO modifying ncurses would only be a temporary fix, good only until the next system header decides it needs . BTW--"regular version" of ncurses? Is 5.4 a stable release or not? FWIW I pulled it off ftp.gnu.org...if it's "unstable", it ought to be taken down from there and put on alpha.gnu.org. -- Kelledin "If a server crashes in a server farm and no one pings it, does it still cost four figures to fix?" ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
On Fri, 20 Feb 2004, Marc Aurele La France wrote: > Redirected from xfree86@ to devel@, where this belongs. > > On Thu, 19 Feb 2004, Kelledin wrote: > > On Thursday 19 February 2004 03:42 pm, Marc Aurele La France wrote: > > > Secondly (and perhaps more to the point), is that > > > is a very recent (glibc-wise) invention (read: bleeding edge). > > > So, in your shoes, I'd first talk to the glibc people about > > > the implications of an stdbool.h in the first place. > > > Not that bleeding edge. stdbool.h is part of gcc and has been > > around since stock 2.95.3 (possibly earlier as well). 2.95.3 > > is...downright ancient, at least in software terms. > > Ooops, right. I was only looking at /usr/include. > > Anyway, some versions of ncurses #undef bool just after #include'ing > . Thomas Dickey, ncurses developer, is on this list, so if > he's reading this, he probably has some suggestions. I overlooked the beginning of the thread. stdbool.h is a C99 file, which is fine. But defining "bool" in that file is a gcc-ism. Both gcc's stdbool.h and ncurses.h are trying to solve the same problem (though ncurses.h has a more valid reason - "bool" is a documented part of X/Open curses, gcc is doing it solely as an extension). In current ncurses (5.4), I don't have an undef for bool following stdbool.h -- there was an undef in the version from last spring. That was to work around (no surprise) a conflict on BeOS with inconsistent definitions of bool. If gcc hadn't added that definition to stdbool.h the #undef wouldn't have been needed. I don't see the original comment on the mail archive - but have the impression that he's trying to use some definition that relies on the bogus "bool" from stdbool.h - So I guess the best recommendation is that he should update to the regular release version of ncurses rather than one of the development versions. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 3D support for radeon 9600 pro (ppc)
On Fri, Feb 20, 2004 at 07:55:27AM -0800, Ian Romanick wrote: > Sven Luther wrote: > >I think that ATI is missing something here. I believe that Powerpc > >hardware with ATI graphics represent a ever growing linux installed > >base, with the G5 Powermac, with the new powerbooks, as well as with > >non-apple powerpc boxes like the pegasos motherboards. But then, it is > >probably that the ATI drivers are not endian clean, and that they can't > >be bothered to make a powerpc build, even an unsupported one, probably > >because of that, or maybe for some hidden reason like the intel-ATI > >connection or something such. > > Even if it is "ever growing", it probably still only represents 1% of 1% > of their total market. It would take some pretty extreme dedication to > the Linux movment to make a business case to devote even an single > engineer to that cause. :( Whatever. The truth is that outside of x86, there is actually not a single graphic card vendor with recent graphic card which provide 3D driver support. Until something changes, this mean the death of 3D support on non x86 linux. And then, seriously, do you believe it it will need a full time engineer to make a powerpc build ? If the drivers were endian clean, then it would only be a matter of launching a build, and track the occasional arch related problem. Hell, if a volunteer project can make it, why can't ATI ? And i would do it, if ATI would give me access to the needed sources, under strong NDA or whatever, i would build their drivers, but they don't want to. Chances of Nvidia releasing powerpc binaries are worse even, altough it is possible that their drivers are more endianess clean, if they share the code with the OS X driver, which i know ATI does not. The only real hope is that ATI will release the R300 specs once the R400 is released, but even there, i only half believe it. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 3D support for radeon 9600 pro (ppc)
Sven Luther wrote: I think that ATI is missing something here. I believe that Powerpc hardware with ATI graphics represent a ever growing linux installed base, with the G5 Powermac, with the new powerbooks, as well as with non-apple powerpc boxes like the pegasos motherboards. But then, it is probably that the ATI drivers are not endian clean, and that they can't be bothered to make a powerpc build, even an unsupported one, probably because of that, or maybe for some hidden reason like the intel-ATI connection or something such. Even if it is "ever growing", it probably still only represents 1% of 1% of their total market. It would take some pretty extreme dedication to the Linux movment to make a business case to devote even an single engineer to that cause. :( ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] XFree86 4.3.x: ValueUnion and loaded variable names
Redirected from xfree86@ to devel@, where this belongs. On Thu, 19 Feb 2004, Kelledin wrote: > On Thursday 19 February 2004 03:42 pm, Marc Aurele La France wrote: > > Secondly (and perhaps more to the point), is that > > is a very recent (glibc-wise) invention (read: bleeding edge). > > So, in your shoes, I'd first talk to the glibc people about > > the implications of an stdbool.h in the first place. > Not that bleeding edge. stdbool.h is part of gcc and has been > around since stock 2.95.3 (possibly earlier as well). 2.95.3 > is...downright ancient, at least in software terms. Ooops, right. I was only looking at /usr/include. Anyway, some versions of ncurses #undef bool just after #include'ing . Thomas Dickey, ncurses developer, is on this list, so if he's reading this, he probably has some suggestions. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver - solved
Hi, Thank you Alain for sorting out this problem and Alan for commiting a patch. Would it be possible to offer binaries or a small, easy to build source package? I think many of the users affected by that problem can't build or don't want to build the whole XFree86 from source. CU Christian ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver - solved
On Fri, Feb 20, 2004 at 12:33:41PM +0100, Alain Poirier wrote: > Le vendredi 20 Février 2004 01:33, Alan Hourihane a écrit : > > Alain, > > > > Can you try the int10 emulator ? > > > > To do this, (re)move this file out of the way. > > > > /usr/X11R6/lib/modules/linux/libint10.a > > > > Then XFree86 will use > > > > /usr/X11R6/lib/modules/libint10.a > > > > Which is the emulator. Does it still lockup with that BIOS call ? > > I tried and got the exact same lockup. O.k. Thanks. I committed a patch which turns this BIOS call off by default and it can be turned back on again with the option "DisplayInfo". Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver - solved
Le vendredi 20 Février 2004 01:33, Alan Hourihane a écrit : > Alain, > > Can you try the int10 emulator ? > > To do this, (re)move this file out of the way. > > /usr/X11R6/lib/modules/linux/libint10.a > > Then XFree86 will use > > /usr/X11R6/lib/modules/libint10.a > > Which is the emulator. Does it still lockup with that BIOS call ? I tried and got the exact same lockup. - Section "Module" Load"dbe" SubSection "extmod" Option "omit xfree86-dga" EndSubSection Load"type1" Load"freetype" Load"glx" Load"dri" Load"synaptics" EndSection Section "Files" RgbPath "/usr/X11R6/lib/X11/rgb" #FontPath "/usr/X11R6/lib/X11/fonts/local" FontPath"/usr/X11R6/lib/X11/fonts/misc" FontPath"/usr/X11R6/lib/X11/fonts/75dpi:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/100dpi:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/Type1" #FontPath "/usr/X11R6/lib/X11/fonts/CID" #FontPath "/usr/X11R6/lib/X11/fonts/Speedo" FontPath"/usr/X11R6/lib/X11/fonts" #FontPath "/usr/X11R6/lib/X11/fonts/truetype" FontPath"/usr/X11R6/lib/X11/fonts/TTF" FontPath"/usr/local/share/fonts/TTF" EndSection Section "InputDevice" Identifier "Keyboard" Driver "keyboard" Option "AutoRepeat""500 30" Option "XkbRules" "xfree86" Option "XkbModel" "pc105" Option "XkbLayout" "fr" #Option "XkbVariant""fr-latin1" EndSection Section "InputDevice" Identifier "Mouse" Driver "mouse" Option "Protocol" "ImPS/2" #Option "Device""/dev/input/mice Option "Device""/dev/misc/psaux" Option "Emulate3Buttons" Option "ZAxisMapping" "4 5" EndSection Section "Monitor" Identifier "LCD" EndSection Section "Device" Identifier "Device" Driver "i810" #VideoRam 32768 VideoRam8192 #Option "hw cursor" "off" #Option "no_accel" EndSection Section "Screen" Identifier "Screen" Device "Device" Monitor "LCD" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1280x1024" EndSubsection EndSection Section "ServerLayout" Identifier "Main Layout" Screen "Screen" InputDevice "Mouse" "CorePointer" InputDevice "Keyboard" "CoreKeyboard" EndSection Section "DRI" Mode0666 EndSection - This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs). XFree86 Version 4.3.0.1 Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.6.3-love1 i686 [ELF] Build Date: 20 February 2004 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Sat Feb 21 12:20:10 2004 (==) Using config file: "/etc/X11/XF86Config" (==) ServerLayout "Main Layout" (**) |-->Screen "Screen" (0) (**) | |-->Monitor "LCD" (**) | |-->Device "Device" (**) |-->Input Device "Mouse" (**) |-->Input Device "Keyboard" (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "fr" (**) XKB: layout: "fr" (==) Keyboard: CustomKeycode disabled (WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts". Entry deleted from font path. (Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts"). (**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc,/usr/X11R6/lib/X11/fonts/75dpi:unscaled,/usr/X11R6/lib/X11/fonts/100dpi:unscaled,/usr/X11R6/lib/X11/fonts/Type1,/usr/X11R6/lib/X11/fonts/TTF,/usr/local/share/fonts/TTF" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" Using vt 7 (--) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such file or directory) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.3.0.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Render
Re: 3D support for radeon 9600 pro (ppc)
On Thu, Feb 19, 2004 at 03:06:13PM -0800, Ian Romanick wrote: > jaspal kallar wrote: > >I know there is already 2D support for the radeon 9600 pro in the upcoming > >4.4 release. My question is if I buy an Apple Powermac G5 with a radeon > >9600 pro card will I eventually in the future be able to > >get 3D support on the powerpc platform (not x86!!) ? > > Only if ATI ports their closed-source driver to PowerPC. And since they probably wont do it, there is little hope there. Maybe you should send Apple some mail, telling them that you are thinking about asking a linux machine, and that the G5 Powermac looks interesting, but that the lack of 3D linux support would be an argument to go for an x86 box instead. I think that ATI is missing something here. I believe that Powerpc hardware with ATI graphics represent a ever growing linux installed base, with the G5 Powermac, with the new powerbooks, as well as with non-apple powerpc boxes like the pegasos motherboards. But then, it is probably that the ATI drivers are not endian clean, and that they can't be bothered to make a powerpc build, even an unsupported one, probably because of that, or maybe for some hidden reason like the intel-ATI connection or something such. Anyway, i believe that the fastest 3D solution on powerpc hardware right now would be a 3Dlabs wildcat VP graphic card, which have lowered in price quite some lately, together with the paying AcceleratedX server, altough they don't officially distribute powerpc binaries too, at least they ship sparc ones, so they should be endian clean. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel