| Summary: | intermittent horizonal fuzziness on M26 | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Tormod Volden <bugzi11.fdo.tormod> |
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> |
| Status: | RESOLVED INVALID | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
Created attachment 27645 [details]
screenshot, drawing a cross in gimp
Created attachment 27646 [details]
Xorg.0.log with KMS (version 1:6.12.99+git20090709.43db263d-0ubuntu0sarvatt)
Does the patch on bug 22644 help in the non-KMS case? No, the patch does not fix it. I was still able to get the fuzzy screen after switching between X and VT a number of times. Created attachment 27652 [details] Xorg.0.log without KMS and with patch from bug 22644 Created attachment 27658 [details] [review] possible fix Does this patch help the non-KMS case? Created attachment 27683 [details] Xorg.0.log without KMS and with patch from comment 6 No, the patch made things consistently bad. Still seeing this occasionally on 2.6.32-rc8 with KMS. I still have this (intermittently) with a 2.6.32 kernel with the "fix LVDS setup on r4xx chips" patch applied. Can the "pull in lvds misc mode info" patch help? If so I can try I it out some more. Does this patch have a UMS equivalent? (In reply to comment #10) > I still have this (intermittently) with a 2.6.32 kernel with the "fix LVDS > setup on r4xx chips" patch applied. Can the "pull in lvds misc mode info" patch > help? If so I can try I it out some more. Does this patch have a UMS > equivalent? > I might. I don't port it to UMS yet. There are several patches in Dave's drm-radeon-next tree related to r4xx LVDS, you might try that. Still the same with both patches from bug 25336 applied, and also with drm-next from 7 Dec. With UMS I could stress-test by switching consoles, with KMS "xrandr --output LVDS --off; xrandr --output LVDS --auto" does the trick (I also got it at first boot of the drm-next kernel). I have a feeling (not great statistical evidence yet) that this got worse from 2.6.34 snapshot 100405 to 0100413. Worse in the sense happening more often. Is this still an issue with 2.6.35? Yes, unfortunately. But now (running 2.6.36-rc7 lately) I would say it is more seldom, based on a statistically unconfident gut feeling. Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases. |
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.
Created attachment 27644 [details] dmesg with KMS This is an old problem, and I have discussed with Alex (on IRC?) a long time ago, then everything was fine for a long time, but has gotten worse again. Sometimes when X is started, the screen is fuzzy with things smeared out (rapidly moving shadows) horizontally. I believe it is the PLL timing that is wrong. But most of the times it starts up fine. When it is wrong, I can switch to a console and back and it will be fine again. However, sometimes I have seen this on the console afterwards. With KMS, this happens when the radeon module is loaded and the console goes high resolution. In this case console switching does not help, so I have to run turn the screen off and on again with xrandr. Hardware: Acer TravelMate 8101 with X700 Mobility.