Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753799AbcJKQ3X (ORCPT ); Tue, 11 Oct 2016 12:29:23 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:32961 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752973AbcJKQ3W (ORCPT ); Tue, 11 Oct 2016 12:29:22 -0400 MIME-Version: 1.0 X-Originating-IP: [2a02:168:56b5:0:ac27:b86c:7764:9429] In-Reply-To: <20161011162559.GR4329@intel.com> References: <1476197648-24918-1-git-send-email-brian.starkey@arm.com> <20161011162559.GR4329@intel.com> From: Daniel Vetter Date: Tue, 11 Oct 2016 18:29:20 +0200 X-Google-Sender-Auth: GUPgOld-d-W-QmV9rDee1xvNlUE Message-ID: Subject: Re: [RFC PATCH 00/11] Introduce writeback connectors To: =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= Cc: Brian Starkey , dri-devel , Linux Kernel Mailing List , "linux-media@vger.kernel.org" , Liviu Dudau , "Clark, Rob" , Hans Verkuil , Eric Anholt Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u9BGTRJl008425 Content-Length: 1864 Lines: 39 On Tue, Oct 11, 2016 at 6:25 PM, Ville Syrjälä 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