Reported in Ubuntu https://bugs.launchpad.net/bugs/132716 "What happens: When X starts, all I get is a black screen. I've had to switch to the VESA driver to get X up and running." "The machine does not freeze under any version of the driver, only a blank screen on X. I can still hit Ctrl+Alt+F1 to get to a console and swap back to VESA driver and restart X. I suspect, based on the lack of obvious errors and the fact that the machine continues to run, that the driver is just not sending output or not sending it to the right place." He tried without an xorg.conf and with one generated by "dpkg-reconfigure -phigh xserver-xorg". xorg-server 2:1.3.0.0.dfsg-12ubuntu3 xserver-xorg-video-ati_6.7.192-1ubuntu2
Created attachment 11476 [details] xorg.conf
Created attachment 11477 [details] Xorg.0.log
Created attachment 11478 [details] output from xrandr -q -d :0
(II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1040 1688 1344 768 771 777 806 (48.4 kHz) (II) RADEON(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) looks like you are getting two modes for 1024x768 on LVDS. Try switching to the other one. you can use xrandr --verbose to list the modes.
you might also want to try with ati git master.
I'm the user who reported this on the ubuntu bug tracker. In any case, using 'xrandr -d :0 --output LVDS --mode 0x48' (the one with -HSync and -VSync) works for me. Is there a way to specify this in my xorg.conf? I honestly have no idea how to pull and build the git master -- never used git, but if you can point me in the right direction, I'd be happy to do whatever I can.
David, the newest version in Ubuntu xserver-xorg-video-ati 1:6.7.193-1ubuntu1 has everything from git master until a few days ago. For building your own packages from git, I'd recommend http://wiki.debian.org/XTips
How can I force it to use the second mode? I've tried adding a ModeLine in xorg.conf, but that didn't seem to do any good. I guess I don't have enough experience with xorg.conf.
(In reply to comment #8) > How can I force it to use the second mode? I've tried adding a ModeLine in > xorg.conf, but that didn't seem to do any good. I guess I don't have enough > experience with xorg.conf. > This should be fixed in ati git master.
The 6.7.194-ubuntu version package does not fix this for me. I'm going to try to pull the git master and install it and see if that helps any.
(In reply to comment #10) > The 6.7.194-ubuntu version package does not fix this for me. I'm going to try > to pull the git master and install it and see if that helps any. > Can you post your xorg log and config and the output of xrandr with the latest driver? Also, if your config has a "modes" line in the display section (e.g., Modes "1024x768"), does it help if you remove it?
Created attachment 11730 [details] Xorg.0.log
Created attachment 11731 [details] Xorg.conf
Created attachment 11732 [details] xrandr -q --verbose -d :0
New attachments added. Removing the 'modes' line had no effect. Still not detecting that it needs the second mode.
does xrandr --output LVDS --set scaler off fix the problem?
(In reply to comment #16) > does xrandr --output LVDS --set scaler off > fix the problem? > then re-run xrandr --auto
No, the screen remains blank and in mode 0x4f. I still need to set mode 0x50 to get the display to work. It does, however, leave only two modes in the options (0x4f and 0x50). A new xrandr -q --verbose will be attached momentarily.
Created attachment 11737 [details] xrandr after setting scaler off.
Add: Option "PanelSize" "1024x768" to your config and attach the output of xrandr --verbose
Created attachment 11742 [details] xrandr --verbose after PanelSize Attached is xrandr --verbose after adding Option "PanelSize" "1024x768". Problem still exists.
Can you try again with ati git?
Tried again with Tormod's build of ati git. This version doesn't work even AFTER changing the mode with xrandr. I get a black screen under both 1024x768 modes. So, I guess that, in many ways, this is a regression.
(The regression was confirmed by cyberdork33 in the same Ubuntu bug.)
try again with latest git. This _SHOULD_ finally be sorted out.
I see the same behavior as I reported on the 1st -- black screen regardless of mode selected. System hard locks when attempting to select any mode other than 1024x768, but not before switching the backlight off. (Nonresponsive to Caps Lock, SSH, etc.)
Two thing to try if you don't mind editing the source a bit. try them each individually and then together if possible. rebuild and see if any modes work. 1. comment out lines 771-776 of radeon_output.c 2. change the TRUE to FALSE in radeon_modes.c lines 106 and 162
I commented out 771-776 in radeon_output.c, rebuilt, copied the resulting .so, and restarted gdm -- and the display came right up. So unless I somehow broke it in a good way, that seems to fix the display issues.
(In reply to comment #28) > I commented out 771-776 in radeon_output.c, rebuilt, copied the resulting .so, > and restarted gdm -- and the display came right up. So unless I somehow broke > it in a good way, that seems to fix the display issues. > FINALLY. can you test the other modes besides 1024x768 and verify that they work as well?
I am able to switch to 800x600 and 640x480 with no problems. Looks like the driver fully works for me now.
Fix committed: 597dffce9bdc200003d0be880235258386a0bdd7 reopen if there are any more problems.
The change was reverted in git, so I'm reopening this bug. Hopefully there will be a method to get the right mode in "all" cases.
(In reply to comment #32) > The change was reverted in git, so I'm reopening this bug. Hopefully there will > be a method to get the right mode in "all" cases. > For now Option "LVDSBiosNativeMode" "FALSE" should do the trick until we sort out something better.
Can you try again with the latest code from ati git (without Option "LVDSBiosNativeMode" "FALSE")? I think I've finally got this sorted out.
This has been fixed for a while.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.