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

Daniel Vetter daniel at ffwll.ch
Mon Nov 12 06:17:15 PST 2012


On Mon, Nov 12, 2012 at 3:11 PM, Rob Clark <robdclark at gmail.com> wrote:
> I do prefer that, at least on lastclose, that we revert properties
> back to default/initial state, so that userspace unaware of some new
> or driver specific properties doesn't get confused.
>
> But dpms is a bit of an odd-duck property.  Probably we need to split
> out the property value "what userspace wants it to be" from the
> current state which could change temporarily as the modeset is
> applied.  At the end of the modeset the driver should somehow try to
> put things back to the state that userspace wants according to the
> dpms property.

That could result into some serious flicker if e.g. we enable things
but dpms is off, so we switch things off. Then userspace does a dpms
on again after all modesets have completed. iirc some desktops do this
to fake less flickery modeset, but it seems to only result in more
(since userspace doesn't know which outputs to disable and which are
unaffected by a given modeset changes). Imo simply updating the dpms
property (both the internal tracking in the helper, but also the
userspace visible part) is the best option. At least it's what intel
now does with it's own modeset code ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the dri-devel mailing list