On Mon, Nov 12, 2012 at 3:11 PM, Rob Clark <robdclark@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
