From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1)
Description of problem:
XFree86 wont show screen resolutions above 640x480. If I edit XF86Config
manually to add resolutions of 800x600 and 1024x768 the modes are not detected
and the resolution is set back to default 640x480.
Acer 230LC Notebook
chipset: intel 82845G
OS: RH9 out of the box
It doesnt work with the i810 driver nor with vesa
The graphical Desktop is black.
The only mode that works is wit 640x480 16bit color depth
Version-Release number of selected component (if applicable):
RH 9 standart workstation Packages
Steps to Reproduce:
1.Configure Xfree with standart RH 9 configuration tools to resolutions above
Actual Results: Resolution was set back to 640x480
Expected Results: Resolutions should be set accordingly
More than likely, your BIOS is misconfigured or hard codes the amount of
"stolen memory" for your video card to be 1Mb or something very small, and
so the X server doesn't have much video memory to use, which then limits
the resolution you can choose.
Attach your X server log and config file please, as individual uncompressed
file attachments using the link below.
Created attachment 91978 [details]
Created attachment 91979 [details]
bless you Mike,
the "more than likely" comment was right on the money.
i had exactly the same problem.
correcting the bios settings allowed higher resolutions for me.
RH 9.0 w/all updates
IBM NetVista with intel 854G onboard graphics 8MB ram
(bios had this limited to 4MB - weird, that WinXP don't care, eh?)
> bios had this limited to 4MB - weird, that WinXP don't care, eh?
Actually, it is expected that Windows (any version of Windows) will
always work with any video hardware. The reason for this is that
video hardware vendors and motherboard manufacturers spend the
majority of their effort developing hardware and software specifically
for use in PC's shipping one of the variants of the Windows operating
If a given motherboard, laptop, etc. has a BIOS problem where it
limits the video memory, such as on the system this report is
filed against, the motherboard vendor who decided to put this
limitation in their BIOS is aware of it as they have done it
intentionally, in order to "simplify" the settings which are
easily available to their target userbase. Since they also
decided to ship the particular video hardware, they know their
systems wont sell if the video does not work, so they work
directly with the video hardware vendor (Intel in this case)
and the OS vendor (Microsoft) to ensure that the video drivers
have workarounds in them to directly program the motherboard
chipset to change the amount of video memory available.
This is "by design" in these systems, and they will always
work in Windows, even if the design is considered broken or
violates standards, because since these systems are targetted
generally at Windows users, and come with Windows, they
would never sell a single unit, if their system shipped to users
with video limited to 1Mb of memory. ;o)
So it's more a matter of the video driver than the operating
system. Intel writes the video driver and has full knowledge
of how all of their hardware works, so even though this is
considered a nonstandard hack to them, they will put hacks in
the drivers for Windows, so that their drivers actually work
on the systems it's being sold in.
For Linux however, the situation is different. These systems
were not designed to be sold or supported as Linux machines, so
this type of problem was never considered an issue when the
system was designed. Since the hardware specifications that
are needed in order to implement workarounds for these systems
with intentionally broken BIOSes, only the hardware vendor,
in this case Intel, has the necessary information to create
workarounds for these types of problems (which they use in
their Windows drivers as per above).
Unfortunately, Linux support for this type of system is often
considered an afterthought, so code is not usually contributed
to the XFree86 and/or X.Org projects to work around these issues,
until a certain threshold of disgruntled users complains to the
hardware vendor or system vendor. (Or so it seems from personal
observation). It's also unfortunate that X.Org, XFree86, and
vendors such as Red Hat generally have to wait for the hardware
vendor to supply patches to work around the issue before updates
can be shipped to support this hardware.
It's an unfortunate but recurring situation sadly, however I hope
the system vendors stop using broken-by-design BIOS implementations,
and ship systems with configureable memory - or that driver support
for Linux is considered of high importance in the future, so that
Linux users aren't left with a system that is less than fully
Anyhow, I hope this helps explain the situation a bit more
clearly. There have been enhancements contributed to later
XFree86 and X.Org X11 releases to work around more of these
issues on many Dell systems with Intel video hardware. It's
possible that this problem is now resolved in Fedora Core 2,
so I would recommend to upgrade to the new release.
If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"
Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes
that become available for consideration in future updates.