Description of problem: when booting fc3 the screen goes blank when xorg starts. Version-Release number of selected component (if applicable): xorg-6.8.1-12 I have an HP Pavilion ze4315us laptop. I have so far determined that the video card, which is a radeon igp320, is correctly identified. Yet the monitor is not. When the Xorg server starts it apparently passes up the 1024x768 resolution (the natural size for the laptop lcd) size claiming the HorizSync and VertRefresh are out of range and then the screen goes black. I haven't found a modeline that works yet... but apparently this new xserver gets it wrong for my laptop.
This sounds very similar to an issue I was seeing. I have a 14 inch LCD attached to a Via Mini-ITX M motherboard with a CLE266 chipset. In FC1 and FC2, X used the vesa driver and all was well. In FC3, it wanted to use the via unichrome driver. X fails to start. The log file says HorizSync is out of range for all modes... and tells me the range for the monitor is 31.5 to ZERO! The interesting thing is that it works about one time in 20 with the unichrome driver. I've switched to the vesa driver for now, and everything works again.
My problem is somewhat similar; I have Toshiba m30-852 (nVidia GeForce FX 5200 64MB -- the card and screen, 1280x800 is recognised). First of all, the 1280x800 is not present in the drop-down list. After manually adding modeline to /usr/share/rhpl/extramodes there is no way to force xorg to addapt the desired resolution.
I have a similar problem with my ATI Radeon 9700 Pro after switching my monitor from a CRT screen to a digital LCD (ViewSonic VP191s). The ModeLines shown in Xorg.0.log do not at all match the ModeLines I specified in xorg.conf; X uses the same sync values for all resolutions! I can only get three resolutions to work: 1280x1024 (native), 1152x864, and 512x410 (go figure), and on the latter two the LCD's Info panel shows the actual resolution is 1280x1022. If I try 1024x768 or 800x600, the screen goes into vertical rolls and the LCD complains "Out Of Range". When I boot MS-Windows, the ATI display driver will show 1152x864, 1024x768, and 800x600 with no problems, and in all modes the LCD's Info dialog shows their proper respective resolutions. (That's how I was able to come up with suitable timing values for the ModeLines). I've seen reference in some of the documentation (http://www.x.org/X11R6.8.1/doc/chips4.html) to an 'Option "Use ModeLine"', but when I try to set this, the radeon driver spits back "Option "UseModeline" is not used".
UseModeline is not a valid "radeon" driver option. You're looking at documentation for a different driver, and I don't see any reference to "UseModeline" on the chips webpage URL you've provided. "Modeline" is the correct config file option, and it is generic. What does "ddcprobe" report for your display?
I can correct my origional bug submit somewhat... The x server or the configuration scripts (I don't know which) picks "ati" as the driver for my graphics card IGP320. I believe that is right, but the driver can't seem to pick a Modeline that works for the LCD monitor and xorg exits. If I instead change the driver to 'vesa' everything works. My LCD can only handle 1024x768 (well)... I believe I also pick 24bit? colors. By the way... I have found that all distributions based on this release of xorg exhibit the same behavior. I think the ones I tried are: ubuntu, suse, fedora.
# ddcprobe Videocard DDC probe results Description: ATI Technologies Inc. R300 Memory (MB): 128 Monitor DDC probe results ID: VSCb916 Name: VP191s Horizontal Sync (kHZ): 30-82 Vertical Sync (HZ) : 50-85 Width (mm): 380 Height(mm): 300 # By the way, since my previous post I have downloaded and tried ATI's fglrx driver (6.8.0-8.8.25-1), and their driver does respect the ModeLine options in xorg.conf. Unfortunately, it also locks up my whole system.
>By the way... I have found that all distributions based on this >release of xorg exhibit the same behavior. I think the ones I tried >are: ubuntu, suse, fedora. Please update to the newest Fedora Core 3 xorg-x11 update, and if the problem still persists, you may want to try xorg-x11 from rawhide, which contains some additional fixes. If the problem still persists in rawhide, please file a bug report in X.org bugzilla, as this does not sound like a Fedora Core specific issue from the above comment. 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. Thanks in advance. Setting status to NEEDINFO, awaiting results of testing feedback, and/or upstream bug report URL for tracking.
It's been 3 months since the original reporter has commented on this bug report, and we have not had the results of ddcprobe supplied, nor any further additional information that would be useful in diagnosis. Additionally, it's been 1 month since my last request in comment #7 to report the problem to X.Org and nobody has supplied any URL for us to track. Most of the "me too" comments from others here are definitely similar bug reports, but each of these issues are very likely driver specific issues, or config specific issues, and the solution for one of the problems almost certainly wont solve anyone elses problems. Roughly translated - each person is having a different problem unrelated to each other, but with similar symptoms for their own hardware, each of which will require different solutions -> different bugs. Each bug should be in it's own bug report ideally, as we're only tracking the original bug report here. For us to diagnose it further internally, we would require direct on-desk physical access to the hardware to reproduce and debug locally any issues, however we do not have this hardware. At this point, we require people who can reproduce this to directly troubleshoot it and provide the information we need, or there's nothing we can do about it. Alternatively, you must report the bug to X.Org directly like I requested in comment #7, and hopefully another X developer has the identical hardware and can reproduce it and diagnose directly. Closing WONTFIX, as the problem requires hardware we do not have to diagnose.