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@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@avionic-design.de
Reviewed-by: Alex Deucher alexander.deucher@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.