On Sat, Sep 15, 2012 at 2:08 PM, Ville Syrjälä <syrjala@xxxxxx> wrote: > 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@xxxxxx> 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@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. >> >> 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. Being able to query default values is probably useful. But we might want the flag anyways to make life easier on userspace. But I guess these can be added over time if needed, they shouldn't block getting the basic multi-plane page-flip in place. >> 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. yup, I see both using a lot of the same code.. all the stuff about splitting out the object state is applicable to both. The property enhancements to support object properties, signed properties, etc, this all applies for both. > 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? I'm thinking of the sync ioctl in particular for things that change timings or light up a new display. Stuff like adding a new plane, flipping/moving an existing plane or crtc, etc.. these can all be done via the async ioctl. The crtc property on a plane, for example, would probably not have the 'dynamic' flag set[*], so that would require a test step. [*] in my current patchset, the dynamic flags are set in core, but this really isn't the way it should be, the driver should be in control of which properties have the 'dynamic' flag set, but I needed something temporary to get things up and running. BR, -R > -- > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
