From: Brian Starkey <Brian.Starkey@arm.com> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>, Liviu Dudau <Liviu.Dudau@arm.com>, nd <nd@arm.com>, Kieran Bingham <kieran.bingham@ideasonboard.com>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, "linux-media@vger.kernel.org" <linux-media@vger.kernel.org> Subject: Re: [PATCH v4 0/7] VSP1: Display writeback support Date: Thu, 21 Feb 2019 13:44:56 +0000 [thread overview] Message-ID: <20190221134456.ahwo7xt3wcfc6zkw@DESKTOP-E1NTVVP.localdomain> (raw) In-Reply-To: <20190221122310.GM3451@pendragon.ideasonboard.com> On Thu, Feb 21, 2019 at 02:23:10PM +0200, Laurent Pinchart wrote: > On Thu, Feb 21, 2019 at 12:19:13PM +0000, Brian Starkey wrote: [snip] > > > > I used a pre-existing internal tool which does exactly that. > > Any hope of sharing the sources ? > Not in a timescale or form which would be useful to you. I'm convinced people only ask questions like this to make us look like Bad Guys. Opening everything up is a process, and it's going to take us time. Sure we could be doing better, but I also think there's a lot of people who do worse. > > I appreciate that we don't have upstream tooling for writeback. As you > > say, it's a young API (well, not by date, but certainly by usage). > > > > I also do appreciate you taking the time to consider it, identifying > > issues which we did not, and for fixing them. The only way it stops > > being a young API, with bugs and no tooling, is if people adopt it. > > If the developers who initially pushed the API upstream without an > open-source test tool could spend a bit of time on this issue, I'm sure > it would help too :-) > No one suggested a test test tool before. In fact, the DRM subsystem explicitly requires that features land with something that isn't only a test tool, hence why we did drm_hwcomposer. That said, yes, we should be trying harder to get the igts landed. I personally think igts are far more useful than a random example C file, but I guess opinions differ. Thanks, -Brian
WARNING: multiple messages have this Message-ID (diff)
From: Brian Starkey <Brian.Starkey@arm.com> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>, Liviu Dudau <Liviu.Dudau@arm.com>, Kieran Bingham <kieran.bingham@ideasonboard.com>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, nd <nd@arm.com>, "linux-media@vger.kernel.org" <linux-media@vger.kernel.org> Subject: Re: [PATCH v4 0/7] VSP1: Display writeback support Date: Thu, 21 Feb 2019 13:44:56 +0000 [thread overview] Message-ID: <20190221134456.ahwo7xt3wcfc6zkw@DESKTOP-E1NTVVP.localdomain> (raw) In-Reply-To: <20190221122310.GM3451@pendragon.ideasonboard.com> On Thu, Feb 21, 2019 at 02:23:10PM +0200, Laurent Pinchart wrote: > On Thu, Feb 21, 2019 at 12:19:13PM +0000, Brian Starkey wrote: [snip] > > > > I used a pre-existing internal tool which does exactly that. > > Any hope of sharing the sources ? > Not in a timescale or form which would be useful to you. I'm convinced people only ask questions like this to make us look like Bad Guys. Opening everything up is a process, and it's going to take us time. Sure we could be doing better, but I also think there's a lot of people who do worse. > > I appreciate that we don't have upstream tooling for writeback. As you > > say, it's a young API (well, not by date, but certainly by usage). > > > > I also do appreciate you taking the time to consider it, identifying > > issues which we did not, and for fixing them. The only way it stops > > being a young API, with bugs and no tooling, is if people adopt it. > > If the developers who initially pushed the API upstream without an > open-source test tool could spend a bit of time on this issue, I'm sure > it would help too :-) > No one suggested a test test tool before. In fact, the DRM subsystem explicitly requires that features land with something that isn't only a test tool, hence why we did drm_hwcomposer. That said, yes, we should be trying harder to get the igts landed. I personally think igts are far more useful than a random example C file, but I guess opinions differ. Thanks, -Brian _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-02-21 13:45 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-17 2:48 [PATCH v4 0/7] VSP1: Display writeback support Laurent Pinchart 2019-02-17 2:48 ` Laurent Pinchart 2019-02-17 2:48 ` [PATCH v4 1/7] Revert "[media] v4l: vsp1: Supply frames to the DU continuously" Laurent Pinchart 2019-02-17 2:48 ` Laurent Pinchart 2019-02-17 2:48 ` [PATCH v4 2/7] media: vsp1: wpf: Fix partition configuration for display pipelines Laurent Pinchart 2019-02-17 2:48 ` Laurent Pinchart 2019-02-17 20:16 ` Kieran Bingham 2019-02-17 20:16 ` Kieran Bingham 2019-02-18 23:24 ` Laurent Pinchart 2019-02-18 23:24 ` Laurent Pinchart 2019-02-17 2:48 ` [PATCH v4 3/7] media: vsp1: Replace leftover occurrence of fragment with body Laurent Pinchart 2019-02-17 2:48 ` Laurent Pinchart 2019-02-17 20:20 ` Kieran Bingham 2019-02-17 20:20 ` Kieran Bingham 2019-02-17 2:48 ` [PATCH v4 4/7] media: vsp1: Fix addresses of display-related registers for VSP-DL Laurent Pinchart 2019-02-17 2:48 ` Laurent Pinchart 2019-02-17 20:27 ` Kieran Bingham 2019-02-17 20:27 ` Kieran Bingham 2019-02-17 2:48 ` [PATCH v4 5/7] media: vsp1: Refactor vsp1_video_complete_buffer() for later reuse Laurent Pinchart 2019-02-17 2:48 ` Laurent Pinchart 2019-02-17 20:35 ` Kieran Bingham 2019-02-17 20:35 ` Kieran Bingham 2019-02-18 23:43 ` Laurent Pinchart 2019-02-18 23:43 ` Laurent Pinchart 2019-02-17 2:48 ` [PATCH v4 6/7] media: vsp1: Replace the display list internal flag with a flags field Laurent Pinchart 2019-02-17 2:48 ` Laurent Pinchart 2019-02-17 20:38 ` Kieran Bingham 2019-02-17 20:38 ` Kieran Bingham 2019-02-17 2:48 ` [PATCH v4 7/7] media: vsp1: Provide a writeback video device Laurent Pinchart 2019-02-17 2:48 ` Laurent Pinchart 2019-02-17 20:06 ` Kieran Bingham 2019-02-17 20:06 ` Kieran Bingham 2019-02-17 20:09 ` Kieran Bingham 2019-02-17 20:09 ` Kieran Bingham 2019-02-19 0:31 ` Laurent Pinchart 2019-02-19 0:31 ` Laurent Pinchart 2019-02-18 12:22 ` [PATCH v4 0/7] VSP1: Display writeback support Brian Starkey 2019-02-18 12:22 ` Brian Starkey 2019-02-18 23:04 ` Laurent Pinchart 2019-02-18 23:04 ` Laurent Pinchart 2019-02-21 8:23 ` Laurent Pinchart 2019-02-21 8:23 ` Laurent Pinchart 2019-02-21 9:50 ` Brian Starkey 2019-02-21 9:50 ` Brian Starkey 2019-02-21 10:02 ` Laurent Pinchart 2019-02-21 10:02 ` Laurent Pinchart 2019-02-21 12:19 ` Brian Starkey 2019-02-21 12:19 ` Brian Starkey 2019-02-21 12:23 ` Laurent Pinchart 2019-02-21 12:23 ` Laurent Pinchart 2019-02-21 13:44 ` Brian Starkey [this message] 2019-02-21 13:44 ` Brian Starkey 2019-02-21 23:12 ` Laurent Pinchart 2019-02-21 23:12 ` Laurent Pinchart 2019-02-21 14:15 ` Daniel Vetter 2019-02-21 14:15 ` Daniel Vetter
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190221134456.ahwo7xt3wcfc6zkw@DESKTOP-E1NTVVP.localdomain \ --to=brian.starkey@arm.com \ --cc=Liviu.Dudau@arm.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=kieran.bingham@ideasonboard.com \ --cc=laurent.pinchart+renesas@ideasonboard.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-media@vger.kernel.org \ --cc=nd@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.