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

[Ville Syrjälä]

On Fri, Nov 09, 2012 at 10:26:52PM +0100, Daniel Vetter wrote:
> 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.

For the atomic modeset at least, I would prefer not to magically flip
some random properties. That is, if the user doesn't specify a property
its value should remain the same. Currently, I'm treating DPMS as
a special case, and changing its value just like the non-atomic modeset
does.

The rule of not changing anything the user didn't specify does make
the whole thing a bit more difficult to use though. What if we have a
property for something relatively innocuous, let's say chroma siting for
example, and the user changes the pixel format from packed YUV to planar
YUV, but the hardware only supports the MPEG2 chroma siting convetion
for packed YUV, and MPEG1 chroma siting for planar YUV. Now, if the user
doesn't specify the chroma siting, we would need to reject the request.
But I guess this case is not that much different from the user specifying
the wrong value for chroma siting.

We could solve it by having some kind of fuzzy vs. strict control. I
suppose we might even want more fine grained control over this
behaviour, so just two levels of fuzzyness may not be enough. Then
we'd need to assign each property to a different class, depending on
how extreme the result of changing it would be.

-- 
Ville Syrjälä
Intel OTC