linux-kernel - Re: [RFC PATCH 00/11] Introduce writeback connectors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKMK7uF5AbmAMdcWNGor5K5zR2EMcS-j9z-CwsV7KchT381Kbw@mail.gmail.com>
Date:   Tue, 11 Oct 2016 18:29:20 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Ville Syrjälä <ville.syrjala@...ux.intel.com>
Cc:     Brian Starkey <brian.starkey@....com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        Liviu Dudau <liviu.dudau@....com>,
        "Clark, Rob" <robdclark@...il.com>,
        Hans Verkuil <hverkuil@...all.nl>,
        Eric Anholt <eric@...olt.net>
Subject: Re: [RFC PATCH 00/11] Introduce writeback connectors

On Tue, Oct 11, 2016 at 6:25 PM, Ville Syrjälä
<ville.syrjala@...ux.intel.com> wrote:
>> Writeback connector usage:
>> --------------------------
>> Due to connector routing changes being treated as "full modeset"
>> operations, any client which wishes to use a writeback connector
>> should include the connector in every modeset. The writeback will not
>> actually become active until a framebuffer is attached.
>>
>> The writeback itself is enabled by attaching a framebuffer to the
>> FB_ID property of the connector. The driver must then ensure that the
>> CRTC content of that atomic commit is written into the framebuffer.
>>
>> The writeback works in a one-shot mode with each atomic commit. This
>> prevents the same content from being written multiple times.
>> In some cases (front-buffer rendering) there might be a desire for
>> continuous operation - I think a property could be added later for
>> this kind of control.
>
> I though people agreed that this sort of thing would go through v4l.
> Continously writing to the same buffer isn't perhaps all that sensible
> anyway, and so we'd need queueing, which is what v4l has already. Well,
> I guess we might add some queueing to atomic eventually?
>
> I guess for front buffer rendering type of thing you might have some
> use for a continuous mode targeting a single fb. Though I think
> peridically triggering a new write could do as well. Of course either
> way would likely tear horribly, and having multiple buffers seems like
> the better option

Yeah, momentarily entirely forgot about v4l. I think making FB_ID
one-shot (perhaps better to call it WRITEBACK_FB_ID to avoid
confusion) is the right thing to do, and then push everything
continuous to some form of drm/v4l integration.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch