I experienced a regression after upgrading Linux from Debian's 3.2.35-2 to its 3.2.39-2. As Ben Hutchings explained to me, that is because some Linux 3.3/3.4 graphics changes were backported in Debian's 3.2.39. And indeed, if I try 3.4.4 or 3.8.3, the regression remains. I have only experienced the problem on KDE, but I didn't try other environments. My laptop has a Radeon HD 5650 card connected to an LCD screen via HDMI. When I leave the laptop idle and come back after a while, the screen resumes. What changed is that I now get 2 KDE dialogs telling me: A monitor output has been disconnected. Do you wish to run a configuration tool to adjust the monitor setup? immediately followed by A monitor output has been connected. Do you wish to run a configuration tool to adjust the monitor setup? (The latter shows on top) Obviously, this is incorrect. I simply press Escape twice and the problem disappears until the next time I leave the PC. This is just an annoyance. I ran tail --follow on .xsession-errors to debug and found as only clue the message "main input error: ES_OUT_RESET_PCR called" logged twice. For example, after a monitor resume, the following had been logged: [0x85fc680] main input error: ES_OUT_RESET_PCR called [0xf1b0a9b8] main input error: ES_OUT_RESET_PCR called I noticed that this error is logged every time the system detects a monitor (dis)connection, real or spurious (On my good Linux version, a resume doesn't trigger that error). Oddly enough, I searched the web quite a bit, asked #debian-kde and #kde and found no one with the same problem. The ES_OUT_RESET_PCR error is common, but in very different contexts. This does not happen when using the vesa driver, nor when modeset is disabled, nor when I plug the screen via VGA (the laptop has no DVI plug to test). There are no hints in system logs. The KDE prompts above are the standard prompts shown when a (dis)connection is detected. Debian testing's KDE version is not the latest (4.8.4).
Forgot to mention one oddity I noticed when debugging this. To reproduce faster, I reduced the powerdevil delay to suspend the screens to 1 minute. This works, and while the bug may not happen if I resume just after the monitor suspends, waiting an extra 20 seconds (so a total of 80 seconds) seems to be enough. But I noticed that after my monitor suspends, it is kind of suspended a second time 30 to 40 seconds later (the monitor reactivates to show "HDMI POWER SAVING", then is disabled again). But I don't have to wait this second suspend to get the bug, and it also happens on 3.2.35, so I'm not sure this is a clue.
A lot of monitors poll their inputs (some when the there is no input signal, others all the time) which can cause hotplug events. Since you've indicated this is a regression, can you bisect?
I just identified that the regression appeared between 3.3.6 and 3.4.1. Beyond that, Debian has no images for me to try. I never installed Linux without using Debian packages. And even building with make-kpkg is something I haven't done for a number of years. If more testing is wanted, I would need guidance. To install intermediary images, and maybe also to test more quickly, as with my current manual test, just testing (after the target version is installed) requires about 5 minutes per version.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/329.
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.