I'm not sure how much this applies to the 2D drivers, but there is code and some basic howto's on the utah-glx website (http://utah-glx.sf.net) detailing how to port the old 3.3.6 3D drivers to the 4.x architecture by simply swapping out the appropriate 3.3.6 function calls with 4.x ones. perhaps this would be a good start for port the old drivers or for getting someone familiar with the X code. just thought I'd throw that out there... Alex --- "Mike A. Harris" <mharris@redhat.com> wrote: > 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 > === message truncated === __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
