On Wed, 10 Jul 2002, Dr. David Kirkby wrote: >Date: Wed, 10 Jul 2002 23:11:55 +0100 >From: Dr. David Kirkby <drkirkby@ntlworld.com> >To: xfree86-list@redhat.com >Content-Type: text/plain; charset=iso-8859-15 >List-Id: Red Hat XFree86 list <xfree86-list.redhat.com> >Subject: Re: Redhat 7.3 and ATI Radeon 7500 graphics card > >"Mike A. Harris" wrote: > >> This card is *NOT* an ATI produced card. Any cards not made by >> ATI, may or may not work at all with XFree86. If a board vendor >> who has licenced ATI's technology makes the board work *exactly* >> like ATI's own hardware, then it should work. If they change the >> design, then it may or may not work. I do not have any non ATI >> boards using ATI chips. >> >> I have had various reports from people that they could not get >> Radeon 7500 and other cards working without tweaking things. All >> cases so far, their hardware was not ATI boards. > >As far as I could tell, the card was made by ATI - there was no other >manufacturer on the box. I should add I sold the card today, so can't at this >second double-check that fact, but I'm not aware of any other make being >obvious. Someone at work bought the card from me, but since he was ill today, >the card is still on his desk. I'll double-check the box tomorrow. ATI hardware has vendor code 1002, and subvendor code 1002. If the subvendor code is not 1002, then it is not made by ATI, only the core chip is made by ATI, and someone else manufactured the board. >> In order for this hardware to be supported properly in XFree86, >> and in Red Hat Linux, someone who has the hardware, needs to >> experiment with config file settings, and then file a Request for >> Enhancement bug report in bugzilla, including their config file, >> X server log, "lspci -v" and "lspci -vn" output, and preferably >> the exact board manufacturer's name, and the marketing name the >> board is marketed as, ie: Radeon 7500 whizbang 2000 >> By using the Subvendor and Subdevice ID's, I can add new entries >> for that specific card to the database and tweak the >> configurations. > >I've bought an Nvidia GeForce 4 Ti4200 based card instead, made in this case by >Inno. Inno does not produce GNU/Linux drivers, but I was hoping the Nvida >drivers (from Nvidia's web site) would have worked. So far I've not managed to >get the Nvidia drivers to work, but to be fair I've not put a lot of time into >this, whereas a wasted a *lot* of time on the Radeon 7500 before giving up. Well, I can assure you that a real Radeon 7500 produced by ATI does work. And any bugs reported in other variants are likely to be fixed, as long as the person with the hardware is willing to help troubleshoot it. >The Redhat 7.3 drivers do at least work on the Inno GeForce 4 >Ti4200, albeit not at the full resolution - for some reason, I >have very few resolutions/colour options to choose from. The >card is detected in Redhat 7.3 as a GeForce 4 (generic), whereas >there is also a GeForce DDR board. I selected the DDR, but that >does not work, despite the fact my card has DDR on the box. >However, the GeForce 4 generic option does work, on the DVI-I >port, at low resolution. All GeForce 4 hardware is unsupported in XFree86 4.2.0 which ships in Red Hat Linux 7.3. We defaulted the autodetection to use the "vesa" driver, which uses the card's BIOS in an attempt to provide mediocre working 2D. Reports that I've received back are that it does not work - at least on some GeForce 4 hardware anyway. XFree86 4.3.0 will support the GeForce 4 family however. >Clearly there seems to be an issue with various manufacturers >making cards slightly differently and only bothering to write >drivers for Windoze. I can see this being a real hassle for >everyone. That problem has been around for ages, and is not specific at all to video drivers. Look at some of the Linux kernel's network drivers for an example. The NE2000 driver, and DEC tulip drivers being good examples. >I also have a Sun workstation at home, which costs a lot more >(even used) for the same performance of a PC. However, I must >say, everything I've ever put into my Sun (currently a dual 450 >MHz processor Ultra 60 with 1280 Mb RAM), has worked first time. >Every Sun I've owned is the same. Sun make the OS and the >hardware. I only use the machine for home use, but can see why >people like my sysadmin at work prefer to uses Sun servers and >won't touch GNU/Linux. I'm not knocking Linux, but hardware >compatability clearly seems to be an issue which will not go >away. It is not a flaw of Linux per se. but a problem due to hardware vendors not treating Linux as a primary platform. Linux support is often last-ditch support thrown over the fence. There isn't any technical reason why hardware can't be supported in Linux. All that is required is: 1) Developers willing to do the work, and having the time to do the work. This can be gratis, or it can be funded. Funded work tends to be work that is finished sooner and more complete than done-on-weekend-hacker-time type of work. 2) Hardware documentation: Developers need access to hardware documentation, addendum's, and possibly access to engineers at the IHV. 3) Hardware: Developers of course need access to the specific hardware being developed. If there are 10 slightly different pieces of hardware, then the developer will need access to all of that hardware, and also the documentation. In the case of video hardware, it is pretty much impossible for a given driver maintainer to acquire one of every single board out there that could be just slightly different. So yes, there is a problem, but it is nothing new. And it is unlikely to change any time soon. People buying hardware should do compatibility checks, and research the hardware adequately ahead of time in order to be confident that their specific hardware selection will work adequately. This is not always *easy* per se, depending on numerous factors, but it is the only way nonetheless to get good working hardware and have a reasonably expect it to work. We don't have the luxury yet of walking into a computer store and purchasing random hardware and expecting it to work, and having it work. Some might argue, that that is the case in Windows also however... -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris
