On Mon, Nov 12, 2012 at 8:17 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > 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 ... 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
