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

[Rob Clark]

On Mon, Nov 12, 2012 at 8:17 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> 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 ...

no, I mean at the end of modeset we should replace dpms(ON) w/
dpms(what_userspace_set_connector_property_to)

well, that works unless userspace assumes that the modeset implicitly
turns dpms(ON).. then we have problems.

BR,
-R

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch