[RFC PATCH v3 0/6] Introduce writeback connectors
brian.starkey at arm.com
Tue Apr 18 17:31:56 UTC 2017
On Fri, Apr 14, 2017 at 11:35:17AM +0200, Boris Brezillon wrote:
>On Fri, 25 Nov 2016 16:48:58 +0000
>Brian Starkey <brian.starkey at arm.com> wrote:
>> This is v3 of my series introducing a new connector type:
>> See v1 and v2 here:  
>> Writeback connectors are used to expose the memory writeback engines
>> found in some display controllers, which can write a CRTC's
>> composition result to a memory buffer.
>> This is useful e.g. for testing, screen-recording, screenshots,
>> wireless display, display cloning, memory-to-memory composition.
>> Writeback connectors are given a WRITEBACK_FB_ID property (which acts
>> slightly differently to FB_ID, so gets a new name), as well as
>> a PIXEL_FORMATS blob to list the supported writeback formats, and
>> OUT_FENCE_PTR to be used for out-fences.
>> The changes since v2 are in the commit messages of each commit.
>> The main differences are:
>> - Subclass drm_connector as drm_writeback_connector
>> - Slight relaxation of core checks, to allow
>> (connector->crtc && !connector->fb)
>> - Dropped PIXEL_FORMATS_SIZE, which was redundant
>> - Reworked the event interface, drivers don't need to deal with the
>> fence directly
>> - Re-ordered the commits to introduce writeback out-fences up-front.
>> I've kept RFC on this series because the event reporting (introduction
>> of drm_writeback_job) is probably up for debate.
>> v4 will be accompanied by igt tests.
>I plan to add writeback support to the VC4 driver and wanted to know if
>anything has changed since this v3 (IOW, do you have a v4 + igt tests
Oh that's good to hear. I've got a v4 (just rebased for the most
part), but was holding off sending it until having some "proper"
userspace to support it. Unfortunately in the meantime we've had some
team changes which mean I'm not really able to work on it to move
things forward - Liviu might be able to pick this up.
I'll collect together what I have and send it out anyway. It includes
some functional tests in igt, but I'm not sure if that meets the "new
uapi needs userspace" bar.
>> As always, I look forward to any comments.
>I'll try to review these patches. Keep in mind that I didn't follow the
>initial discussions and might suggest things or ask questions that have
>already been answered in previous versions of this series or on IRC.
More information about the dri-devel