Bug 62671

Summary:	[Radeon HD 5650][kms] KDE thinks the monitor is reconnected each time it resumes
Product:	DRI	Reporter:	Filipus Klutiero <chealer>
Component:	DRM/Radeon	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED MOVED	QA Contact:
Severity:	normal
Priority:	medium	CC:	jlp.bugs
Version:	XOrg git
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Filipus Klutiero 2013-03-23 15:04:38 UTC

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).

Comment 1 Filipus Klutiero 2013-03-23 15:11:28 UTC

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.

Comment 2 Alex Deucher 2013-03-25 13:01:42 UTC

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?

Comment 3 Filipus Klutiero 2013-03-25 23:32:31 UTC

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.

Comment 4 Martin Peres 2019-11-19 08:32:40 UTC

-- 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.