On Wed, 5 Jun 2002, Thomas Dodd wrote: Long email follows. An attempt to help users of older hardware, ensure that it stands the highest chances of being supported in the future, rather than being dropped and unsupported. >Date: Wed, 05 Jun 2002 18:16:46 -0500 >From: Thomas Dodd <ted@cypress.com> >To: valhalla-list@redhat.com, xfree86-list@redhat.com >Content-Type: text/plain; charset=us-ascii; format=flowed >List-Id: Red Hat XFree86 list <xfree86-list.redhat.com> >Subject: Re: Solved: post 7.2->7.3 upgrade X server problem > >David M. Wood wrote: > >>to the 4.2.0 server XFree86 rather than to the the 3.3.6 S3 server >>XF86_S3 which the installer had properly installed (given my older video >>card). Linking to >>XF86_S3 instead fixed everything. >> >File a bug in bugzilla.redhat.com on Anaconda or Xconfigurator >for this. It's supposed to switch to XF4.0 if it's supported. > >It's misdetecting the card/chip, and thinks the XF4.0 server is correct. >I thik the XF3.3.6 server was installed because you had it there before. > >I'll also mention it on the Red Hat XFree86 list ( xfree86-list@redhat.com) >since Mike Harris, the Red Hat X maintainer isn't on the valhalla list. I've had a few reports of this now for S3 hardware. There are a few different issues here I believe. One, is that XFree86 4.2.0 contains a new S3 driver which supports hardware previously unsupported by 3.3.6. After discussing it with the author of this new driver, I changed the default server to 4.2.0 for the hardware that he (Ani Joshi) claimed was supported, after confirming it by examining the driver source code. However, the problem is that there are cards out there which identify as being the same piece of hardware via PCI ID, however they contain different a RAMDAC. In the case of the new driver, it only supports certain RAMDACs, and not all of them. So there is no really easy way to autodetect this sort of thing, and pick the server which is guaranteed to work in all cases. The only way to guarantee it, is to default to 3.3.6 all the time, and not use the new driver. However, the problem with that, is that most people with this hardware will just accept and use the old driver, like they always have in the past. That however does not allow us to find out about bugs in the new stuff. Here is a deeper problem to solve: At the time that XFree86 4.0 originally came out, the new driver interface it used did not have support for all of the hardware that the XFree86 3.3.6 servers did. So in order to maximize hardware support, 4.x was made the official X release to ship, and 3.3.6 was included merely for the X servers. The inclusion of these 3.3.6 X servers was done ONLY for compatibility reasons, similarly to how we include backward compatible C libraries, and various other libraries for a few releases to ensure a smooth transition between major release cycles. There was never any intention of shipping XFree86 3.3.6 indefinitely. It was only done, so that hopefully, as time moved on, XFree86 4.x would mature enough to support more hardware, and eventually 3.3.6 would become irrelevant because either: 1) All hardware supported in 3.3.6 would be supported by 4.x or 2) Most hardware supported by 3.3.6 would be supported by 4.x, and the remaining hardware would be considered old enough that if nobody ported the stuff, it would be considered obsolete and unmaintained. In either case, 3.3.6 would be removed at some point in time, and hopefully all of the important drivers would be ported to the 4.x infrastructure. Well, during the last couple of years since the release of XFree86 4.0, new 4.x releases have indeed added support for a lot of the older hardware previously only supported by 3.3.6. Also, time has moved ahead by 2+ years now, and a lot of that hardware is either no longer used and/or the number of users out there has dwindled significantly. In order to get people moved over to 4.x, we need people to test out the new drivers that come out supporting hardware previously that only worked on 3.3.6, and to not only report bugs to us here at Red Hat, but to report bugs in the drivers to the upstream people who wrote those drivers, and are thus much more likely to be able to fix them. If people try 4.x, it doesn't work, then they switch to 3.3.6, then the 4.x drivers will likely never ever get fixed, and when 3.3.6 is dropped eventually, those users will find themselves needing to buy a new video card, or to hack in an old copy of 3.3.6. So, the reason for 4.x being the default for a lot of hardware, is that 4.x contains code now which allegedly supports stuff only supported by 3.3.6. We do not have all of this hardware, and we rely on end-users testing the stuff during our beta cycles. Especially if it is ancient hardware like S3. (For the record, I have no S3 hardware at all for testing or debugging). Since most people have moved on to more modern hardware however, I'm noticing a patern of ancient hardware not being adequately tested until after we make our final release, at which point users upgrade, and then find that our defaults do not work for them any longer. Maintaining both XFree86 4.x, and 3.3.6 in the distro is a lot more extra work than would be maintaining just 4.x. The configuration tools are much more complicated, as are many other aspects of the system. Maintaining XFree86 3.3.6 indefinitely is just not a feasible thing to do, and each release, the number of users needing 3.3.6 decreases, which makes it even more infeasible to keep around. Another problem that magnifies the amount of maintainership overhead that needs to be done, is when a security hole is found in X. Twice as much work needs to be done to fix it generally including developer work, as well as QA testing before releasing erratum. Does it make sense to spend all of these human resources maintaining a piece of legacy? I believe that redirecting the resources spent on maintaining XFree86 3.3.6 are much much more usefully spent on finding/fixing bugs in XFree86 4.x. In order to do so however, that means that some hardware just falls into a black hole of "we no longer officially support this, sorry". So, rather than wasting a lot more time on 3.3.6, what I personally think is MUCH more important, is that users who use 3.3.6, should test out 4.x, and at least take a serious shot at getting it to work for them. The following options are available: 1) The 4.x native driver for your card (if there is one), check the XFree86 status doc to see if it is listed as supported. http://www.xfree86.org/4.2.0/Status.html 2) Try using the "vesa" driver instead. Hunt through Xconfigurator's Card list, it is in there. ;o) Or just change the driver to "vesa" in the config file. 3) Try using the framebuffer driver. You'll need to read the Framebuffer-HOWTO on http://www.linuxdoc.org 4) Try using the "vga" driver (yes, this sucks bigtime). Keep also in mind, the older the hardware is, the much lower on the priority list it will be for me to personally look at it, since more problems get reported than one person can ever look at, I must prioritize things to look at the bugs affecting the largest number of people, or bugs which cause the most serious problems. ISA video hardware, VESA localbus hardware basically are unsupported, and first generations of PCI hardware are low on the list also. The absolute best thing that any user experiencing problems can do, is to report the problem directly to XFree86.org both via their bug submission address, as well as to join their mailing list and post the problem there (driver issues, etc.). Bug reports to: xfree86@xfree86.org Mailing list: xpert@free86.org This maximizes the number of people aware of the issue, as well as maximizes the chances of finding someone else with the same problem, and potentially finding a workaround, or a real solution. Someone reading, may have the same hardware, and may be able to look into the problem and even perhaps create a driver fix, etc. If someone can submit to me a driver fix to a problem which is reported that would end up getting extremely low priority, it can end up usually making it into my next build, and the problem becoming resolved. If users who experience problems in XFree86 could do those steps, and open reports with a greater level of detail, as well as reporting it to the community, and providing updates to the bug report they've filed in bugzilla, and hopefully an actual patch or other solution, it can go a long way to helping us to help others. I'd like to keep as much hardware supported as possible, but a lot of problems - without having the hardware and/or documentation, and being able to see/reproduce problems, and justify the time being spent on a given issue, I feel a lot of problems fall through the cracks that could be fixed much more easily or stand a higher chance of being fixed if the same issue is reported to the community and/or the original driver authors. So please, always report driver issues both to us, and to xpert@xfree86.org, and follow up on the reports. Don't settle for 3.3.6 if you can avoid it, but rather try to get 4.x working with the suggestions from above. Update bug reports with things you've tried and the results they've given. Another thing I'm planning on doing is writing an XFree86 troubleshooting and debugging HOWTO. A lot of display corruption problems, mouse pointer corruption can be solved with Option "swcursor" and/or "noaccel" or one of the many "XaaNo" options from the config file. If I can get people experiencing these kind of problems to troubleshoot things on their side (due to me not having all hardware out there), it can help greatly to get the default configurations _working_ and as optimal as possible. What does this have to do with the original S3 problem reported above? ;o) Well, if 3.3.6 was not necessary at all, then this problem wouldn't exist. I could spend time fixing issues in 4.x instead of wasting time tracking down problems with 3.3.6 and Xconfigurator, etc. especially hard to fix problems due to not having any of the hardware the bugs are generally reported against. If the issues with 4.x were reported to more people, and troubleshooted a bit more beforehand (not this particular issue, but others), then someone somewhere could stand higher probability of fixing it. I've been thinking these things for quite a while now, and just now decided to vocalize my random brainwaves (or lack thereof). ;o) So, now that I've put forth the above commentary, I'd appreciate hearing back all of your opinions and ideas as well. Perhaps I can even stimulate people with old hardware and a bit of programming experience to port the 3.3.6 driver code for their hardware to a 4.x driver. ;o) Anyway, enough boring chatter from me.. I'm going to go start writing that troubleshooting guide now. /me disappears back into the cave. -- 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
