On Sat, Sep 15, 2012 at 11:07:02AM -0500, Rob Clark wrote: > On Sat, Sep 15, 2012 at 9:56 AM, Ville Syrjälä <syrjala@xxxxxx> wrote: > > On Fri, Sep 14, 2012 at 09:12:35PM -0500, Rob Clark wrote: > >> On Thu, Sep 13, 2012 at 11:35 AM, Rob Clark <rob.clark@xxxxxxxxxx> wrote: > >> > note that the test phase doesn't need vblank events, and also > >> > shouldn't -EBUSY if there is still a pending flip[*], so I'd propose > >> > that however we go about pageflip (one super-ioctl, or one per crtc), > >> > we could use the atomic-modeset ioctl for the test step > >> > >> actually, I think I take this back.. one thing that was discussed on > >> IRC, but didn't make it to this email thread is the behavior of > >> non-specified properties. What I am thinking: > >> > >> modeset: unspecified properties revert to default > >> pageflip: unspecified properties preserve current value > > > > Why on earth would you want to revert stuff to default? That's only > > going to make the code more complex. > > well, you need to do it *somewhere*.. possibly it can be on drm file > close or dropmaster. But modeset seems like a sensible place. I > really hate the v4l2 approach of preserving settings for the next > process that opens the device. Ah so it's the same workaround for lack of proper state management. Each master should just have its own state. Or if that's too much to ask, at least the reset could be done only when the master changes. If you do it at modeset time, which props do you reset anyway? All of them for the whole device? Just the ones related to the CRTCs undergoing the modeset? What if there's some conflict between the default values on that CRTC and the current values on another CRTC? What about properties for planes that can move across CRTCs? This kind of partial state reset opens up a lot of open questions, so a full reset at master switch seems a lot more sensible. -- Ville Syrjälä syrjala@xxxxxx http://www.sci.fi/~syrjala/ _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
