[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=46711

--- Comment #10 from Tvrtko Ursulin <tvrtko.ursulin at 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?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.