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@linux.intel.com 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@bwidawsk.net wrote:
On Sun, 9 Sep 2012 22:19:59 -0500 Rob Clark rob@ti.com wrote:
On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark rob.clark@linaro.org wrote:
From: Rob Clark rob@ti.com
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.