Re: Installing XFree86 4.3 on RHL 7.3

["Mike A. Harris" <mharris www linux org uk>]

On Sat, 17 May 2003, Michael B Allen wrote:

>to the three packages mentioned. All of which I seem to have or have
>rebuilt from src.rpm. Rpmfind.net claims 2.4.18-3 provides kernel-drm. My
>impression was that the remaining stuff is just a problem with RPM
>dependencies. But if you know for certain a few packages that will
>definately give me problems then please enlighten me before I run rpm
>--nodeps and end up needing to back it off.
>
>"Upgrading" to RH 9 is not an option. This is my work machine and I don't
>need any headaches. Right now the machine is rock solid and I'm going
>to keep it that way. Backing off X is one thing but changing operating
>systems is not acceptable and I'm sorry to hear RH is so quick to leave
>people behind and EOL versions they just put out a year ago. I would
>just like to use a flat panel I have but the current video doesn't seem
>up to it so I was hoping improved support for my chip would help.

Don't even get me started.  You have absolutely no idea 
whatsoever the amount of engineering resources that are required 
to support releases for longer periods of time.

First, I must apologize to everyone reading this for its length,
however I need to speak my mind about a few things that I find a
lot of people simply do not understand, and appreciate how 
complicated it is to produce a Linux distribution, and to keep it 
as high quality as possible, knowing what risks are good and what 
ones are bad, and knowing how to make the most efficient usage of 
your manpower and time resources, and to divide that time amongst 
future development of products, as well as maintenance of 
released products.

I further apologize if this comes off as a rant to some people, 
as it is not intended in that way.  Since email does not carry 
through emotional content very well, in order to understand my 
inflection/tonality here, picture me sitting in a nice cozy 
lazyboy chair, sipping a nice hot cup of Earl Grey tea, with a 
pleasant look on my face, and a polite tone to my voice.  ;o)

I'd offer you all a cup of Earl Grey to enjoy while reading my 
rambling below, however distance and technology prevent that. ;o)

First, I should point out that the software comes at zero cost to
those who want to obtain it that way, and upgrades are also
optionally at zero cost.  Some people do pay for the software
and/or for RHN.  Red Hat does not and has never promised any
customers or users that any OS product would receive video driver
updates once a month, or once every 6 months.  Once the OS has
shipped, it is shipped largely as-is.  We provide security
updates for the OS to handle security issues that arise, and we 
try to provide bugfix errata for major bugs that arise and to 
which we have the manpower resources and time to work on 
producing such errata.  There is no guarantee of course that 
every single bug that gets reported can be fixed by us.  We do 
try to provide as many fixes as possible however, and work is 
prioritized based on many factors not worth going into here.

However, there are no good reasons why people can not upgrade
their OS to a newer version in order to obtain support for new
hardware.  If hardware is trivial to add support for in an
update, it often will happen, however non-trivial updates for new
hardware are not always easy to do, and can require extensive 
engineering resources even to attempt.

Nobody is obligated to pay for new OS versions of course, so they
can be downloaded free of cost for those who can not, or do not
want to pay for it.  Not a bad deal at all for a full fledged
operating system.  And if they've got an RHN subscription
already, after upgrading the OS, their entitlement can be changed
to the new version free of charge as well.

Some people wish that new XFree86 releases would be released as 
updates for existing OS releases every time a new release of X 
comes out, both so they can get the new XFree86 features, as well 
as the new XFree86 driver support and other enhancements.  This 
was attempted once, as an experiment.  I released XFree86 4.1.0 
as an update to XFree86 4.0.3 for Red Hat Linux 7.1.  I did this 
for 3 reasons:

1) Because the types of changes between the two releases did not 
change any core technology in any major way that might risk 
destabilization, or conflict with existing documentation of the 
OS, etc.

2) I wanted to be able to maintain one single set of XFree86 
packages for multiple releases of the operating system, thus 
minimizing workload hopefully

3) I wanted to test how well an update like that would be 
received by people, the types of problems that might arise, and 
other problems, as well as getting good feedback.  4.1.0's 
changeset happend to not contain any major changes that I thought 
were likely to be too risky, and I'd been running 4.1.0 on my 7.1 
box for quite some time already as were many others.  The 
experiment was worth trying.

Overall, the upgrade to 4.1.0 for RHL 7.1 worked out without any
major catastrophes, but it wasn't without regression and wasn't
without its share of angry users.  I had been quite careful to
try to minimize risks and retain as much packaging compatibility
as possible, and deal with the numerous font related problems,
DRM problems, driver change problems, and other issues as nicely
as possible.

Many people were glad to see the new release, and received it 
well, however not everyone did.  Some users had working setups, 
which after upgrading to the new release - no longer had a 
working X setup.  They were upset at the thought that we could 
possibly release an updated X package set which broke their 
setup.  How could we possibly not have tested their specific 
video chip on their motherboard with the exact configuration 
options they were using?  etc. for example.

The answer of course being, that we don't have every piece of
hardware, and even if we did have every motherboard, video card,
laptop, system, monitor, mouse, keyboard, etc., we could never
possibly have the time and manpower resources to even attempt to
test a small fraction of all possible hardware out there.  For
video hardware, we'd have to try and test it in every color depth
at every video resolution and do so both with and without DRI
enabled, with and without dualhead, and with and without a bunch
of other options, including testing Xvideo and the numerous other
features that are present in XFree86.

People just want stuff to work, and when it doesn't, then someone 
is going to get heat for it for sure.

So yes, upgrading the X server may work great for many people, 
but it may totally screw up other people's setups too, and people 
get much more angry for having their setup broken from an update 
than they do starting out with a non working setup and not 
getting an update to fix it.

Another *MAJOR* technical support issue, is the kernel DRM.  DRM 
are the kernel modules which are used by the DRI code in XFree86 
to perform direct rendering, and implement 3D acceleration.  

XFree86 can not work with just any old DRM, it requires the
specific kernel DRM that was shipped as part of the source code
of that specific XFree86 release, or a newer version of DRM which
retains backward compatibility.  This poses a significant
technical, and technical support problem for Red Hat, and also 
for the users.

If we hypothetically *wanted* to release an updated XFree86
version for an existing OS release, we absolutely can not just
update X, and let DRM break.  We *MUST* release a new kernel
_first_ which contains the updated DRM.  We must also try to
guarantee that the new DRM works also with the older XFree86, so
that users who do not want to upgrade X for whatever reason - are
not forced to.  And shipping multiple versions of DRM is also not 
feasible, as that requires supporting an ever expanding amount of 
software, with the same number of engineers.  We can't support 3 
different versions of X on 3 different kernels on one OS all at 
once, simply because some users want to upgrade and others do 
not, and all users want us to support whatever they are using.

Another problem, as you are learning above, is that new versions 
of XFree86, require other new pieces of software, such as 
freetype, fontconfig, expat, and other software as well.  In 
order to officially release all of those updated packages, we 
would technically have to make sure that any one of those 
packages can be updated on the system, and also work with the 
existing XFree86 in a compatible fashion, and that combinations 
of upgrades of the different pieces also work compatibly.  The 
amount of quality assurance testing complexity that it would 
involve to properly test the massive number of compatibility 
permutations in upgrading that many components is mind numbing.

One example I can think of, which I do not recall the specifics 
of, is that freetype exported some of it's internal interfaces in 
some releases, and that some stupid applications were using these 
internal interfaces and should not have been.  A newer version of 
freetype fixed this by not exporting those interfaces.  The 
applications which used them but should not have been of course 
would now be broken.  So releasing an update of freetype, would 
mean releasing an update of the other apps that ended up 
breaking due to updating freetype.  Imagine if that happened to 
be OpenOffice, Mozilla, and Nautilus.  The number of packages 
quickly expands to consume all engineering and QA resources.  The 
end result is that a large portion of the OS has been updated - 
just to upgrade something seemingly simple like XFree86.

So, while people can upgrade XFree86 on their systems manually,
and they might not have any problems personally with it, and may
never happen to run a piece of software that broke due to one of
the upgrades they did to get the new X installed, Red Hat, as a 
vendor will hear bad words from every user out there who does 
experience such a problem after such an update should an update 
be made available.

XFree86 is an extremely large major piece of software.  It is
totally impossible to test it completely in any combination of
automated or manual manner.  In particular, the most dynamic
thing is the video drivers, which may get upstream updates to fix
a given bug, add a new feature, etc. and silently break another 
card nobody developing has, or nobody tested on.  Perhaps that 
update just broke 16bit depth on C&T 65000 chip only, and all 
other C&T chips work fine.  Who would ever know?  To set up a 
test matrix to make sure these types of regressions are 
impossible would require being a company like IBM, and having 
every video vendor out there deeply interested in being involved 
and making sure their hardware works on as much hardware as 
possible.

That just is not something feasible at this stage of the Linux 
game.  And so, while companies such as Red Hat do make 
contributions to XFree86, fix bugs, and other companies do too, 
XFree86 largely remains developed by XFree86.org, the DRI 
project, and others in the community, and it is as high quality 
as it is handed over when branded with a new version number and 
release.  That gets integrated into RPM packaging, patches 
dropped that are included now, new problems that arise get fixed 
hopefully, and the beta test process begins.

>From a distribution beta test release perspective, as well as the
ongoing rolling rawhide packages, they're not just a test of any
given piece of software such as XFree86, but it is also a test of
how that software integrates with all of the other software being
beta tested.  As many bugs get fixed as possible of course, but
there are hundreds more bugs in XFree86 than are humanly possible
to fix with the number of people working on it both in
XFree86.org, the community, all distribution vendors shipping X,
and beyond.  There will always be bugs, and just like any other
vendor or distro, we just try to ship as bug free a version as
possible with the resources we have available, and to continue 
fixing problems that arise as best that can be done over time.

To release an update of a major new XFree86 release on an old OS,
means that while the video drivers are likely as well tested as
the new release of the OS, and other things are likely well 
tested too, there is no *integration* testing done by the public 
on the OS as a whole.  The risks are far to great at causing a 
domino effect of regression and requiring massive package updates 
for problems that could theoretically arise.

Does this all sound too complicated?  Probably, but this is just
a very brief commentary on why as a /general rule/ new XFree86
releases do not get released for old OS versions.  Whenever 
possible, drivers get updtated if it does not require significant 
re-engineering to retrofit them into an older X server as an 
update.  I've done this in the packages of 4.2.0 in RHL 8.0:

[mharris devel XFree86-4.2.1]$ ls -1 *cvs*
XFree86-4.2.0-apm-driver-update-cvs-20020617.patch
XFree86-4.2.0-ark-driver-update-cvs-20020617.patch
XFree86-4.2.0-chips-driver-update-cvs-20020617.patch
XFree86-4.2.0-cirrus-driver-update-cvs-20020617.patch
XFree86-4.2.0-i740-driver-update-cvs-20020617.patch
XFree86-4.2.0-i810-driver-update-cvs-20020617.patch
XFree86-4.2.0-mkfontscale-xcvs-20020618.patch
XFree86-4.2.0-pci-domains-from-cvs.patch
XFree86-4.2.0-siliconmotion-driver-update-cvs-20020617.patch
XFree86-4.2.0-trident-driver-update-cvs-20020617.patch

There are other updates as well.  However if someone finds that 
their chip is not supported, and will not be supported in any 
official OS update of XFree86, and they are told to upgrade to a 
new OS version for support for that chip - it is for a really 
good reason.  It means that adding support for that chip, is 
significantly complex that it would require major engineering 
resources, possibly even ending up forking the X codebase in a 
major way to even get it to work.

Intel i845 graphics is a good example of this.  i845 requires
invasive kernel changes, as well as very invasive X server
changes (compared to 4.2.0 that is), and the technical
specifications for the hardware aren't even possible if someone
did plan on doing it.  So that is why i845 will not ever be
supported in Red Hat Linux < 9.  If I could make i845 work in RHL 
8.0 in 2-3 days worth of work, then it might be feasible to try 
to do that.  It is not easily possible however, and so it will 
not happen.  There are massive number more things that are much 
more important for me to be working on, than wasting massive 
ammount of time trying to backport driver code without the 
hardware and without the docs, and with a huge amount of 
dependant code needing backporting as well.  It's easier to just 
upgrade the whole X server than maintain a massively forked 
backport.  And I've covered the reasons why an X server update is 
generally not feasible above.

You'll notice in the patches above there is:
	XFree86-4.2.0-i810-driver-update-cvs-20020617.patch

That was an attempt to backport the existing i845 video support
in XFree86 CVS as of June 2002.  It did not work at all for the
majority of people, but it worked better than nothing for a few
people, so it was kept, and it shipped in Red Hat Linux 8.0.  It
was unsupported of course, and remains unsupported.  

Nonetheless, it was an attempt I had made voluntarily on my own
personal time to try and get i845 running in any useable manner
on XFree86 4.2.0 in Red Hat Linux 8.0, and without having the
video hardware to even test with, and without any knowledge of
the hardware since the specs were not publically nor privately
available.  I had originally planned on trying to improve this in
my own spare time also, as I really couldn't justify spending
company time on doing what was largely a hack, and not something
that could be considered "supported".

The majority of feedback I received since then however about i845
support from users and customers however has been extremely
negative - ranting and raving.  People demanding that we support
i845, etc. and going ballistic when I tell them it is not 
supported, and that we wont ever support that video hardware on 
those specific products.

I've covered above why that support is not feasible to do, and
not going to happen, and that people need to upgrade to Red Hat
Linux 9 if they want officially supported i845 video.  If i845
could be made to work well in Red Hat Linux 8.0 or earlier
without a lot of effort, I probably would have gladly tried to do
so by now, even in my own time.

Due to the amount of complaining and negativity I've received
however, for something that is unsupported, and not feasible to
try to support, I dropped any plans to attempt doing this, as in
my personal time as a volunteer - as there wasn't anything
positive or good that I was receiving about it.

I've used i845 as a single example here, however there are lots
of other examples which could be used.  Some people want 3D
support for Radeon 8500 in Red Hat Linux 8.0 for example.  
Essentially, the only sane way to do that, is with XFree86 4.3.0.  
Ditto for many other hardware support related issues.

Soon there will be XFree86 4.1.0 updates forthcoming for Red Hat
Linux 7.1, 7.2 and the AS/AW/WS enterprise line of products.  
These updates contain some new video hardware updates that I was 
able to work on and integrate, including support for all 
remaining Rage 128 video chipsets, Savage driver update to the 
latest bits, some Radeon updates, Nvidia Quadro updates, and 
others.

There will be XFree86 4.2.1 updates for both Red Hat Linux 7.3
and 8.0 of which contain identical support and bug fixes now (but
different RPM packaging).  There is a new savage driver, R128 
updates as above for 4.1.0, FireGL 8700/8800 support update, and 
many many other updates as well.

There are still some driver and other updates which can be done 
without much effort for 4.2.1 and 4.1.0 however not a heck of a 
lot without going into major effort for little to no benefit.  

After this upcoming XFree86 update is released, both 4.1.0 and
4.2.1 will essentially go into security-fixes only phase, and
updates will only come out when there is a security issue found
that requires an update.  I will try to cram any stable sane
bugfixes into those updates as well, but people experiencing 
problems in those releases should expect that only security fixes 
will occur from now on for those releases, and that OS upgrades 
will be required in most cases where new hardware is unsupported 
in the given OS release currently.

Also, before someone asks me..  Yes, this will be an XFree86
4.2.0 -> 4.2.1 version update for Red Hat Linux 7.3 and 8.0, and
some people may see this as contradictory to what I've said above
(and below) about version upgrades.  XFree86 4.2.1 is only a 
cosmetic version number change that was made by XFree86.org for a 
security update.  XFree86 4.2.0 and 4.2.1 are identical support 
wise other than 4.2.1 containing a security fix (which we 
shipped as a patch to 4.2.0) and various other bug fixes which 
we've been shipping all along as patches to 4.2.0.  So while this 
is a version change, it is minor and only a few small patches 
different from our existing 4.2.0 packages not counting all of 
the new bugfixes I've rolled in personally of course.  ;o)

I will also be moving XFree86 packaging to a much more modular
set of packages sometime in the future, with the intent being to
be able to provide more frequent updates of certain pieces
without having to roll out a massive 150Mb errata to fix a
driver.  It'll be a gradual packaging shift that happens over
time rather than a major break in packaging strategy in order to
minimize user problems and whatnot.

I would eventually like to see the drivers split into their own
packages and be able to be updated independantly, and I'd like to
see the driver sources compatible across server releases in some
manner.  Those things require buy in from the upstream X supplier
however in order to truely be feasible.


>If there are no objections I'm going to try running with --nodeps. Last
>call! Stop me now if you know better!

Go nuts if you must, but do so realizing that dependancies exist
for a reason.  After running with "--nodeps", you can fully
expect whatever software required the given dependancies you've
chosen to ignore - to break.  That's not specific to XFree86 of
course, but is just the fact that dependancies are tracked by RPM
for a reason, and when you use --nodeps you are purposefully
saying "I know that this software *requires* this other thing in
order to work, but I don't care, install it broken anyway".


>Mike
>[who fortunately uses Pine]

Not so fortunate actually... pine was just officially removed 
from the distribution in rawhide.  Of course, I'll be maintaining 
pine rpms for RHL unofficially on people.redhat.com though, 
because I am such a nice guy.  ;o)

Anyway, I hope that some people out there got something
beneficial from my above attempt to rationalize XFree86 package
management and release engineering, and I hope people look at 
this much deeper in the future and with more perspective into the 
complexities involved in maintaining distribution software, and 
providing stable updates to the userbase, which are tested as 
much as can be reasonably done.

I hope people realize now that while upgrading any major software
component such as XFree86 on one's own personal system, may seem
to come off without any problems, that for a vendor to do it, a
lot more work must go into the process than just doing it and
saying "it works for me".  A vendor has a fair amount of
responsibility to its customers to not release software updates
which may cause any large risks to any particular part of its
installed userbase, and also to use its engineering and time
resources as wisely as possible, balancing future development 
with maintenance and support.  In the realm of video, that often 
means users will be required to upgrade their OS in order to stay 
up to date with the latest video hardware support available.

It's not the ideal solution, but it is the only really feasible 
one given the parameters and contraints.

One again, my apologies for the long book...  would you like 
another cup of Earl Grey?  ;o)


-- 
Mike A. Harris