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
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 Loaddbe SubSection extmod Option omit xfree86-dga EndSubSection Loadtype1 Loadfreetype Loadglx Loaddri Loadsynaptics 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 AutoRepeat500 30 Option XkbRules xfree86 Option XkbModel pc105 Option XkbLayout fr #Option XkbVariantfr-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 Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.3.0.1, module
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
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: [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 stdbool.h 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 stdbool.h. 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: 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: 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: [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 stdbool.h 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 stdbool.h. 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: [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 stdbool.h, 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 stdbool.h. 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: 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
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 stdbool.h. 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, 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 stdbool.h 1 The header stdbool.h 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
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
