xf86-video-ati, master (d586a2c6f821c821a4a7708a3382acb63187534f) Ubuntu 8.10, xserver-xorg 1:7.4~5ubuntu3 When I start X the monitor instantly enters sleep mode. By SSH-ing into the machine I see that the X-server is alive. xrandr show that the monitor is connected to HDMI-0 and using the correct resolution. Changing resolution using xrandr also works but the monitor stay off. Attaching Xorg.0.log and output from "xrandr --verbose" and "avivotool regs all". The computer have two ATI cards (HD3200 + HD3870). With radeon I can only use the one that is set as primary in BIOS, but that is a separate bug that I don't think affect this one that I am reporting now. :-)
Created attachment 23491 [details] Xorg.0.log
Created attachment 23492 [details] xrandr --verbose
Created attachment 23493 [details] avivotool regs all
Are you connecting to an HDMI monitor or are you using an HDMI to DVI adapter?
(In reply to comment #4) > Are you connecting to an HDMI monitor or are you using an HDMI to DVI adapter? HDMI to DVI adapter.
I tried this card with -radeonhd (master) and latest drm kernel modules (r6xx-r7xx-support). Using this the output works fine. I also verified that the bug is still present with latest -ati master (a55ced5ee20c07e743c7c0978803fd10589c1531).
Created attachment 23882 [details] avivotool regs all (radeonhd) reg dump with working video output and running radeonhd.
can you try with ati from git master? Specifically commit 66b194a78c470cb3978f310828dd96c3f3e96944.
Can you try with the latest code from xf86-video-ati git master? I just committed some new PLL code that might help.
(In reply to comment #9) > Can you try with the latest code from xf86-video-ati git master? I just > committed some new PLL code that might help. I just tried vanilla 2.6.32 together with latest -ati git packages from Ubuntu xorg-edgers ppa. X works, this blank screen-bug is definitely fixed! On 2009-10-21 you asked me to try latest git, but I have not had time to do that. This means that I unfortunately can't say if you fixed it then or in your latest commits. I see quite a bit of flickering pixels now, which goes away if I lower the resolution from the panels native 1600x1200 down to 1280x1024. This is noticeable in text mode before X is started, so I guess it is an unrelated kernel issue.
(In reply to comment #10) > I see quite a bit of flickering pixels now, which goes away if I lower > the resolution from the panels native 1600x1200 down to > 1280x1024. This is noticeable in text mode before X is > started, so I guess it is an unrelated kernel issue. > For non-KMS, does: Option "DisplayPriority" "HIGH" in the device section of your config help?
(In reply to comment #11) > For non-KMS, does: > Option "DisplayPriority" "HIGH" > in the device section of your config help? If I boot without KMS (options radeon modeset=0) there is no flicker while in text-mode as expected. X still flickers, but significantly less than with KMS. No noticeable difference when setting DisplayPriority=HIGH. However setting NewPLL=FALSE make non-KMS flicker as much as KMS, maybe even more. Would you like to see how the flicker look? I filmed the monitor a few seconds in KMS and non-KMS, but the movies are 16M each so I probably should not attach them to bugzilla. :)
(In reply to comment #12) > X still flickers, but significantly less than with KMS. No noticeable > difference when setting DisplayPriority=HIGH. However setting > NewPLL=FALSE make non-KMS flicker as much as KMS, maybe even more. KMS and non-KMS should use the same pll code assuming you have a new enough drm. If you update your drm, you should get the same behavior with both KMS and non-KMS.
(In reply to comment #13) > KMS and non-KMS should use the same pll code assuming you have a new enough > drm. If you update your drm, you should get the same behavior with both KMS > and non-KMS. My kernel is vanilla 2.6.32, is that new enough? librdm is latest git, package from xorg-edgers: libdrm (2.4.16+git20091211.edc77dd2-0ubuntu0sarvatt2) karmic; urgency=low * Checkout from git 20091211 (master branch) up to commit edc77dd291594e017ca0ee96a785412107ebff74
(In reply to comment #14) > (In reply to comment #13) > > KMS and non-KMS should use the same pll code assuming you have a new enough > > drm. If you update your drm, you should get the same behavior with both KMS > > and non-KMS. > > My kernel is vanilla 2.6.32, is that new enough? You need what will become 2.6.33. Either Linus' or Dave's tree.
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > KMS and non-KMS should use the same pll code assuming you have a new enough > > > drm. If you update your drm, you should get the same behavior with both KMS > > > and non-KMS. > > > > My kernel is vanilla 2.6.32, is that new enough? > > You need what will become 2.6.33. Either Linus' or Dave's tree. I tried latest from Linus master-branch, with all necessary firmwares. R600_rlc.bin and R700_rlc.bin was a bit hard to find :) Non-KMS and KMS now behave the same way. Both have a low amount of flicker, like with 2.6.32 and non-KMS. DisplayPriority=HIGH still makes no difference.
Is this still an issue with KMS on a newer kernel?
Pär Andersson, Karmic reached EOL on April 30, 2011. For more on this, please see https://wiki.ubuntu.com/Releases . If this is reproducible in a supported release, it will help immensely if you filed a new report with Ubuntu by ensuring you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information running the following from a terminal: ubuntu-bug xorg Also, please feel free to subscribe me to it. For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.
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.