[RFC 0/9] nuclear pageflip

[Ville Syrjälä]

On Sat, Sep 15, 2012 at 12:15:59PM -0500, Rob Clark wrote:
> On Sat, Sep 15, 2012 at 12:04 PM, Ville Syrjälä <syrjala at sci.fi> wrote:
> > 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 at 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 at 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.
> 
> Well, if you reset *all* properties on modeset, then crtcs's that
> aren't set in the modeset go off..  atomic-modeset is userspace saying
> "here is the entire config I want.. go make it happen".  But I guess
> it does get a bit easier to implement legacy setcrtc on top of the new
> mechanism if untouched properties preserve their value.

Yeah. I don't see much point in maintaining the state stometimes,
but sometimes not. Either do or do not.

> I could live w/ just reset on master change.. that meets my minimum
> requirement of not carrying state between different processes using
> the device.

> Having a flag indicating 'reset untouched properties'
> would be useful if the default behavior is to preserve.

Perhaps. Or perhaps some way to query the default values of properties.

> I still think setcrtc and pageflip shouldn't be mashed into a single ioctl :-)

So instead of one ioctl w/ async flag, you want one sync ioctl and one
async ioctl. Sure, why not. Both would en up doing much of the same
things when collecting and verifying the state, but sharing the code is
easy anyway.

But I'm actually not sure what everyone wants from the sync ioctl,
especially when you use it for somthing that doesn't involve changing
the timings. Should it behave like the current setcrtc, setplane etc.
where the ioctl is free to execute asynchronously, but without any way
to get a completion event? Or should it always block until the operation
is truly complete?

-- 
Ville Syrjälä
syrjala at sci.fi
http://www.sci.fi/~syrjala/