On Thu, 23 Jan 2003, Rigault, Philippe wrote:
> >This workaround for the BIOS bug will be officially part of the
> >next Red Hat Linux release. There are no plans to backport the
> >new driver to Red Hat Linux 8.0 as that would entail a rather
> >large amount of development engineering for what is not even an
> >XFree86 bug, but is a hardware bug.
>
>So the conclusion is:
>
>1. It is a serious bug (laptops with i830 are plain unusable with X for
>regular users).
Well yeah... It is a serious Intel specification violating
design flaw in the BIOS.
>2. It can be fixed in software (it really is a hardware bug, actually
>BIOS, but it does not matter since Dell has apparently no intention to
>fix it and Windows drivers already workaround this in software).
Precicely.
>3. RedHat will fix the bug for the next version of RedHat Linux (good
>news here)
Not exactly. Red Hat had no part of working around this issue.
Normal XFree86 development processes eventually got the
information needed to work around the problem eventually from
Intel. My attempts at getting documentation from Intel went
nowhere at the time.
>4. RedHat will not fix the bug for current (and officially supported) RH
>releases.
Red Hat does not have access to Dell laptop BIOS source code, and
as such is of course unable to fix the bug.
>I respect the fact that it is up to RedHat to decide whether
>this bug warrants by itself an XFree86 update for 7.3 and 8.0,
>but I strongly support that updated XFree86 packages should be
>released to address this issue (maybe wait until XFree86 4.3.0
>is out), given that Dell hardware is de facto common hardware
>and regular RedHat users expect some support for it.
Well that isn't going to happen for multiple reasons:
1) It is *NOT* an XFree86 bug. It is a hardware bug, specific to
certain hardware.
2) The manufacturer of that hardware specifically does not
support Linux on that hardware.
3) Releasing XFree86 4.3.0 for prior versions of Red Hat Linux
once it is available, is not an option.
4) Backporting the massively redesigned Intel i810 driver from
XFree86 4.3.0 to XFree86 4.2.x is also not an option.
>It may also send a very bad message by appearing as a veiled
>'forced upgrade' policy.
Tough. Purchase broken hardware that is officially not supported
on the OS by the vendor selling it to you, and you get burned.
Red Hat is not going to go adding 10000 workarounds for IHV's
broken hardware and then releasing high-engineering-expense
updates to fix broken hardware. It is the responsibility of
hardware vendors to decide what OS platforms they will and will
not support, and to make sure their hardware works on those
platforms if they want to sell their hardware to users of those
platforms.
If your hardware vendor does not support Linux, then find one
that does. Alternatively, find another OS vendor who is willing
to spend half of their R&D budget backporting major work to
support broken hardware that advertises no Linux support, while
there are numerous legitimate bugs open that are driver bugs, and
not hardware bugs.
>I have pesonally no problem with upgrading and testing the
>latest stuff when time allows, and always had very good
>experiences of RedHat on Dell laptops so far. But I have been
>frustrated all along by this i830 fiasco (on a Dell inspiron
>2600 with RH 8.0) and had to resort to a commercial (xig) X
>server, since Mike's RPMs did not work in my case.
My suggestion then, is to purchase hardware in the future from a
vendor who actively supports Linux openly, and to research it
beforehand.
For the record, these are my plans going forward with all
currently supported base OS releases:
Red Hat Linux 7.0 will remain with 4.0.1a indefinitely
Red Hat Linux 7.1 will remain with 4.1.0 indefinitely
Red Hat Linux 7.2 will remain with 4.1.0 indefinitely
Red Hat Linux 7.3 *might* have an update from 4.2.0 to 4.2.1,
which basically amounts to a backport of the
4.2.1 packages I have in testing for 8.0 on my
ftpsite, but if and when time permits and
engineering and QA resources also are
available. It will remain at 4.2.1 afterward
indefinitely
Red Hat Linux 8.0 will get an update to 4.2.1 when time permits
and engineering and QA resources also are
available. It will most likely remain at 4.2.1
from that point onward. There is an extremely
small chance of at least investigating the
amount of work necessary to entertain the idea
of releasing a 4.3.0 update a million years
from now, but don't count on it.
The next version of Red Hat Linux, will be the first release, and
quite possibly the only release to ship with the 4.3.0 codebase
(with the exception perhaps of future releases, depending on the
timing of XFree86 future development).
Red Hat Linux 7.0, 7.1, and 7.2 are currently in "security fix
only" state. Assuming 7.3 does get the update to 4.2.1 (because
4.2.1 is essentially 4.2.0 plus minor updates that do not change
half the world), once that update has been done, then 7.3 will be
in security fix only state as well. All releses containing
XFree86 3.3.6 servers, the 3.3.6 stuff is in more or less "no
updates ever" state. If 3.3.6 security issues arise, the
recommendation will be to use the 4.x server instead, possibly
using the "vesa" driver if necessary.
Many major changes happen in XFree86 each XFree86 release that
require many libraries such as freetype, fontconfig, and others
to be upgraded also in order to update a prior OS release to a
new XFree86 release. The amount of engineering work needed to do
that, is about 30 times the work _minimum_ of Joe Blow(TM)
downloading the RPM package and ad-hoc rebuilding it for the
older OS. Joe Blow doesn't have to test 90000 video cards out
with the OS on multiple architectures, fix new problems that
arise, and Joe Blow does not need to know or care about RPM
packaging changes that occured in newer distro releases in the
XFree86 packaging. Joe Blow doesn't need to ensure that packages
work with Red Hat Network's updating mechanism, or even with RPM
for that matter. Also, a XFree86 release comes along with a
forced kernel upgrade for new DRM modules required for proper DRI
functionality to work.
So, while I appreciate people's enthusiasm as to how great it
would be to have every new XFree86 release, and every driver
bugfix backported back across 5 previous OS products, it is not
something feasible that can be done, due to the massive amount of
engineering and quality testing that would be required.
I updated Red hat Linux 7.1 from 4.0.3 to 4.1.0 with erratum
before, and with that update we got very lucky. There was a fair
number of dependancy requirements that had to be released also
(Xconfigurator, freetype, etc...), but compatibility was quite
good for that release of X, and that of the dependancies.
Getting the kernel in sync with DRM was trickier until we
released unified kernel for both 7.1 and 7.2. It was a bit of
work, but there was time to do it back then, and the gains
outweighed the losses from an engineering resource point of view.
Examination of 4.2.0 or 4.2.1 for release on 7.2 or 7.1 would
require wayyyyy to much work. When releasing one piece of
software the size of XFree86 for multiple OS products, one wants
to have _ONE_ rpm package to maintain, not 3 different ones to
keep in sync and divide one's time by 3. Updating RHL 7.2/7.1 to
be able to use Xft, then updating freetype, then updating all the
apps the freetype upgrade breaks because those apps used internal
freetype APIs, updating all the other things needing updating,
and doing all that, with NO distribution integration testing and
massive public beta exposure - is not providing a quality tested
product for customers and users. Instead, it is dividing
engineering resources resolving already solved problems over and
over again.
Red Hat Linux is an operating system which is freely downloadable
off the Internet. Users who want updates that are only available
in newer OS releases, are free to download those new OS releases
at no charge, and upgrade their systems. Users who purchased the
OS, are also welcome to download or purchase new versions of the
OS. Downloading again is free of charge.
If you have purchased Red Hat Linux, and feel that you should be
entitled to new versions of XFree86 every time one comes out, for
the life of the product, then if there are enough customers out
there who think that Red Hat should spend the engineering
resources on backporting XFree86 50 times a year, perhaps there
is a market I'm unaware of. I'm sure we could increase the $30
boxed set price from $30 to $500 to accomodate this however if
there is sufficient demand.
Call it forced upgrading if you like, call it whatever you want,
I really don't care. There are nonetheless certain realities in
the open source world, and one of them is effective use of
engineering resources. OS products like Windows don't have this
problem because the hardware vendor themselves write the drivers,
and they also update the drivers. Microsoft doesn't. Those
hardware vendors, and also Microsoft themselves, or even Apple
are under no real obligation to provide you with new drivers
ever.
At the end of the day, if you want to have the latest XFree86
video driver support, then you upgrade to the latest erratum
packages released for the distro version you are using, or you
upgrade the OS to the latest supported OS and update the packages
to any erratum released. That is what is manageable, and that is
what engineering resources are able to provide.
While the open source community does a great job of maintaining
the Linux kernel, with hundreds of developers, XFree86 is
developed by a very small number of people, and it does not have
the community following around it as that of the kernel.
In addition, very few video hardware vendors provide the
necessary technical documentation and hardware. Few vendors at
all pay to have drivers developed.
Anyway, I've said my piece, and am stepping down off my soapbox
to go work on some of the 200+ open XFree86 bug reports.
TTYL
P.S. If about 50 of you volunteer to help out by debugging issues
reported against XFree86 in bugzilla, and attaching patches,
perhaps I can work on releasing 4.2.1 for 7.3 before 2004.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
_______________________________________________
xfree86-list mailing list
xfree86-list@redhat.com
https://listman.redhat.com/mailman/listinfo/xfree86-list
IRC: #xfree86 on irc.redhat.com
