[PATCH] HACK: drm: Allow encoders to be reenabled

[Daniel Vetter]

On Thu, Nov 08, 2012 at 08:01:57PM +0100, Thierry Reding wrote:
> On Thu, Nov 08, 2012 at 12:48:18PM -0500, Alex Deucher wrote:
> > On Wed, Nov 7, 2012 at 5:06 PM, Thierry Reding
> > <thierry.reding at avionic-design.de> wrote:
> > > When running the xf86-video-modesetting driver on top of a KMS driver,
> > > leaving X causes the active encoder's DPMS mode to be set to off by the
> > > drm_crtc_helper_disable() function. This doesn't set the connector's
> > > DPMS mode to off, however, which results in subsequent calls to the
> > > drm_helper_connector_dpms() function to not enable the encoder because
> > > the connector's DPMS mode hasn't changed.
> > >
> > > This patch works around this by forcing the connector's DPMS mode to off
> > > if the encoder has changed, which always happens when a new mode is set
> > > after drm_crtc_helper_disable(). The code that sets the connector DPMS
> > > mode to on will then also enable the CRTC and encoder because the mode
> > > actually changed.
> > >
> > > Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de>
> > 
> > Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
> 
> This is really much uglier than I would have liked, but I honestly can't
> think of any better way that would be this easy to implement. An
> alternative solution would be to add dpms fields to both drm_crtc and
> drm_encoder structures and modify drm_helper_connector_dpms() to run the
> CRTC's and encoder's .dpms() functions if the new mode is different from
> that stored in the respective dpms fields. Coding that, however, will
> probably be more involved and more likely to introduce errors somewhere
> else because of the extra accounting required.
> 
> In case this workaround isn't acceptable I can take a look at coding up
> a cleaner fix.

Imo the confusion around dpms in the crtc helper all stem from the totally
unclear semantics of dmps vs. modeset calls. Besides your case, where we
essentially disable a encoder/crtc without updating the dpms properties,
theres the symmetric issue that after a modeset call all newly active
encoders/crtcs are fully enabled, but the connector dpms property is still
the same it was before the modeset call. Which is even more funny since
userspace is allowed to change the dpms property on an unused connector.

Additional, the i915 modeset code now also updates the userspace visible
dpms property after a modeset, to avoid potential confusion in userspace -
that way the dpms property always reflects reality when the connector is
used, and is ignored when it is unused. Dunno whether forcing dpms to on
after a modeset is the semantics we want though.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch