Red Hat Bugzilla – Bug 238470
Cant use higher resolution than 1400x1050 on computer capable of 1680x1050
Last modified: 2007-11-30 17:12:03 EST
Description of problem: I've installed Fedora 7 test4 on my HP/Compaq NC8430 laptop. The default resolution I got in X was 1280x1024, which is quite far from the 1680x1050 the computer is capable of. I tried to change this by choosing System->Administration->display. The list of resolutions in the "Settings" tab had no other alternatives than 1280x1024, so I looked at the "hardware" tab. The video card was correctly identified as "Ati Radeon Mobility X1600", and the Monitor type was set to "(autoconfigured)". I clicked on "Configure" for the monitor and chose "LCD Panel 1680x1050", and clicked OK. I then logged out and in again to restart X. Now the resolution was 1400x1050, but wouldn't go higher. The "Hardware" tab still says "LCD Panel 1680x1050" for my monitor, so the system is obviously aware that my monitor is capable of 1680x1050, but still it will not accept anything higher than 1400x1050. Version-Release number of selected component (if applicable): Xorg-x11-7.1 How reproducible: Highly reproducible. Steps to Reproduce: 1. Install Fedora 7 test 4 on a laptop of said model. 2. Try to set the resolution to 1680x1050 using said procedure. 3. Get frustrated. Actual results: X running at nothing higher than 1400x1050. Expected results: X running at 1680x1050. Additional info:
Sorry, there's no fixing this, at least not any time soon. The Xxxxx series of radeons are based on the R500 chip, and the open source radeon driver does not support these chips yet. As such, we are forced to use the vesa driver, and the vesa driver can only set the display to the set of modes listed in the card's video BIOS. It's almost certain that your card's video BIOS simply doesn't list a mode for 1680x1050, and that the closest one is 1400x1050. (You can verify this by running: % grep Mode: /var/log/Xorg.0.log which will print the mode sizes available in your video BIOS.) Upstream Xorg is working on native support for this chip, but until that happens, there's no fixing this bug. Apologies for the inconvenience.