On Wed, Sep 12, 2012 at 07:30:18AM -0500, Rob Clark wrote: > On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrjälä > <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote: > >> On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky <ben@xxxxxxxxxxxx> wrote: > >> > On Sun, 9 Sep 2012 22:19:59 -0500 > >> > Rob Clark <rob@xxxxxx> wrote: > >> > > >> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark <rob.clark@xxxxxxxxxx> wrote: > >> >> > From: Rob Clark <rob@xxxxxx> > >> >> > > >> >> > This is following a bit the approach that Ville is taking for atomic- > >> >> > modeset, in that it is switching over to using properties for everything. > >> >> > The advantage of this approach is that it makes it easier to add new > >> >> > attributes to set as part of a page-flip (and even opens the option to > >> >> > add new object types). > >> >> > >> >> oh, and for those wondering what the hell this is all about, > >> >> nuclear-pageflip is a pageflip that atomically updates the CRTC layer > >> >> and zero or more attached plane layers, optionally changing various > >> >> properties such as z-order (or even blending modes, etc) atomically. > >> >> It includes the option for a test step so userspace compositor can > >> >> test a proposed configuration (if any properties not marked as > >> >> 'dynamic' are updated). This intended to allow, for example, weston > >> >> compositor to synchronize updates to plane (sprite) layers with CRTC > >> >> layer. > >> >> > >> > > >> > Can we please name this something different? I complained about this in > >> > IRC, but I don't know if you hang around in #intel-gfx. > >> > > >> > Some suggestions: > >> > multiplane pageflip > >> > muliplane atomic pageflip > >> > atomic multiplane pageflip > >> > atomic multiflip > >> > pageflip of atomic and multiplane nature > >> > > >> > Nuclear is not at all descriptive and requires as your response shows > >> > :-) > >> > > >> > >> fair enough.. I was originally calling it atomic-pageflip until > >> someone (I don't remember who) started calling it nuclear-pageflip to > >> differentiate from atomic-modeset. But IMO we could just call the two > >> ioclts atomic-modeset and atomic-pageflip. (Or even modeset2 and > >> pageflip2, but that seems much more boring) > > > > My plan has been to use the same ioctl for both uses. They'll need > > nearly identical handling anyway on the ioctl level. I have something > > semi-working currently, but I need to clean it up a bit before I can > > show it to anyone. > > I do think the atomic-pageflip ioctl really should take the crtc-id.. > so probably should be two ioctls, but nearly identical But then you can't support atomic pageflips across multiple crtcs even if the hardware would allow it. I would hate to add such limitation to the API. I can immediately think of a use case; combining several smaller displays to form a single larger display. With a unified API you could just add some kind of flag that tells the kernel that user space really wants an atomic update, and if the driver/hardware can't do it, it can return an error. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
