On Mon, Nov 12, 2012 at 8:29 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Mon, Nov 12, 2012 at 3:25 PM, Rob Clark <robdclark@xxxxxxxxx> wrote: >> 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) > > Oh, for atomic modeset that's definitely the better option (we simply > need code to be clever enought to not enable stuff if it's not > required). But there's the pesky problem of what should happen with > the legacy modeset stuff, which I've thought is the topic here ... well, I was hoping to avoid too many special cases for legacy stuff.. it would be nice if we could do this for atomic and regular modeset. If userspace does assume modeset lights up the displays that it had previously disabled, then maybe we should just declare it to be so and make sure the user visible properties are updated to reflect this. BR, -R >> well, that works unless userspace assumes that the modeset implicitly >> turns dpms(ON).. then we have problems. > > Presume it does assume that, since that's how the code currently > works. Save that the userspace visible dpms property doesn't reflect > reality at all. > -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
