https://bugs.freedesktop.org/show_bug.cgi?id=46711
--- Comment #10 from Tvrtko Ursulin tvrtko.ursulin@onelan.co.uk 2012-04-17 08:23:56 PDT --- (In reply to comment #9)
(In reply to comment #8)
Brief look doesn't show me any locks there, I'll dig in.
The locking (or lack there of) would be on the kernel side.
If relevant, we have the same symptoms with and without a "desktop environment". Meaning same thing happens with pure X, and also with our software running which does explicit output probing when nothing is connected.
Problem is (seems to me) xrandr reports monitor connected when in that state.
Also if relevant we do get two RandR events (RRScreenChangeNotify and RRNotify_OutputChange) when re-plugging the monitor.
Unless there is no intersection between RandR and DPMS... ?
We don't change the dpms state in the hotplug handler we just use the dpms code paths to properly tear down and bring up the display when an enabled monitor is connected or disconnected.
Isn't that the problem? You are referring to radeon_connector_hotplug where it puts old dpms state into the connector.
On disconnect DPMS gets set to off, and then connector->dpms restored to ON.
Subsequent hotplug then doesn't bring up the display becausedrm_helper_connector_dpms bails out early due to current mode and target mode being the same.
Manually calling xset dpms force off and then on works because "off" this time really sets connector->dpms to OFF which allows following "on" command to do all things it needs to turn it on.
So my question is why this saved_state business in radeon_connector_hotplug?