Created attachment 15553 [details] Xorg.0.log With xf86-video-ati from git I can't switch to the console (Ctrl+Alt+F..). If I do so, the screen is corrupted, I can only see some garbage. I can type, and the commands are recognized. Switching back to X works. This is not the same as bug: https://bugs.freedesktop.org/show_bug.cgi?id=13852 In fact reverting that commit doesn't help in my case. I also tried to upgrade X to the current git, but that doesn't help either. My hardware is an X1400 Mobility, on a DELL Inspiron 6400 laptop.
Created attachment 15554 [details] xorg.conf
Can you try again with the latest code from git?
Thanks Alex, I've tried the latest git and I still have the same corruption. But I've tried an ubuntu live cd, installed the driver there and everything works smooth! So I guess you can close this bug, as it seems to be a problem with my gentoo :( Any advice on how to discover what's wrong?
Interesting... I tried another different distro and the problem is still there! So I guess ubuntu has some setup that somehow makes radeon work? What could it be? Kernel config?
Ok, I think I solved it. I had to remove the option vga=XXX from grub's menu.lst. No matter what number I passed to "vga=" I would get the corruption.. Also different kind of corruption for different numbers. Now, the drawback is that the fonts in the console are huge, and I can't see the penguin logos at boot :P Btw, booting an ubuntu 8.04 liveCD and passing the "vga=" option at boot will cause the corruption too.
I have similar problems using an ATI M52 (Mobility Radeon X1300) on a Lenovo T60 and with a FireGL V5250 on a Lenovo T60p. I'm using X.Org X Server 1.4.0 and xf86-video-ati-6.8.0. When using a vesa framebuffer text console (vga=791) the screen of the text console gets corrupted as soon as Xorg server has started. That's pretty much the original bug report here. Additional to that I experience also problems with 'vga=0' boot parameter - the text console has very strange and mostly unreadable colors after switching back from the running Xorg server to any text console. Any ideas how to fix that? I would like to reopen the bug since the current behavior is not very satisfying ...
yea, and the bug is still present in git. I'll re-open it.
(In reply to comment #6) > I have similar problems using an ATI M52 (Mobility Radeon X1300) on a Lenovo > T60 and with a FireGL V5250 on a Lenovo T60p. > > I'm using X.Org X Server 1.4.0 and xf86-video-ati-6.8.0. > > When using a vesa framebuffer text console (vga=791) the screen of the text > console gets corrupted as soon as Xorg server has started. That's pretty much > the original bug report here. > > Additional to that I experience also problems with 'vga=0' boot parameter - the > text console has very strange and mostly unreadable colors after switching back > from the running Xorg server to any text console. > > Any ideas how to fix that? > > I would like to reopen the bug since the current behavior is not very > satisfying ... > I've had your same problem and solved it not removing the vga=xxx but using a lower number of colors. I've tested that removing the vga=xxx from lilo.conf it works great, and than I've tested to use more colours, in my case I've tested to use a 1024x768 resolution with 256 colours ... it's vga=773. if you test it you'll see that you won't have problems. If you use also 640x480 resolution with 32k colours you have the same problems. I've tested all options: the vga=xxx working good are the ones using just 256 colours, or the not usage of vga=xxx. All others create problems.
you might want to try with latest git, specifically: 87e66ce76430890ab4939ffcd42f72b9288eb598
I tried today's git, and the problem is still there, same as always :)
I don't see this bug anymore now, but I can't really say which commit solved it. If others don't have the bug anymore this should be closed :)
Fixed for me as well; too lazy right now to bisect. Thanks, closing.
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.