Red Hat Bugzilla – Bug 91600
XServer doesnt work on resolutions above 640x480
Last modified: 2007-04-18 12:54:00 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 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. System: Acer 230LC Notebook chipset: intel 82845G OS: RH9 out of the box Kernel: 2.4.20-8 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 How reproducible: Always Steps to Reproduce: 1.Configure Xfree with standart RH 9 configuration tools to resolutions above 640x480 2. 3. Actual Results: Resolution was set back to 640x480 Expected Results: Resolutions should be set accordingly Additional info:
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] Xf86Config
Created attachment 91979 [details] Xf86 log
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 XFree86 4.3.0-2 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 system. 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 useable. ;o/ 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" component. 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.