Re: [RFC 0/9] nuclear pageflip

["Ville Syrjälä" <syrjala@sci.fi>]

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@sci.fi> 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@linaro.org> 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@sci.fi
http://www.sci.fi/~syrjala/