; I'm not sure I agree with the TODO, and even if I did, I'm not sure I agree
> with this solution. Since queuing the buffer to the driver is not the same
> as 'just before the DMA', since there may be many buffers queued up in the
> driver and you don't know in vb2
o the mapping when buffers
> > are queued in the driver since that's when the actual DMA operation are
> > going to happen.
> >
> > Suggested-by: Nicolas Dufresne
> > Signed-off-by: Javier Martinez Canillas
>
> Sorry, but I don't get why such chan
more appropriate to do the mapping when buffers
> > are queued in the driver since that's when the actual DMA operation are
> > going to happen.
> >
> > Suggested-by: Nicolas Dufresne
> > Signed-off-by: Javier Martinez Canillas
> >
> > ---
> >
Le mercredi 12 octobre 2016 à 23:33 +0800, Wu-Cheng Li (李務誠) a écrit :
> I'm trying to use V4L2_DEC_CMD_STOP to implement flush. First the
> userspace sent V4L2_DEC_CMD_STOP to initiate the flush. The driver
> set
> V4L2_BUF_FLAG_LAST on the last CAPTURE buffer. I thought implementing
> V4L2_DEC_CM
Le samedi 15 octobre 2016 à 08:16 +0800, Wu-Cheng Li (李務誠) a écrit :
> last_buffer_dequeued is only cleared to false when CAPTURE queue is
> STREAMOFF (#1). Queuing a header to OUTPUT queue won't clear
> last_buffer_dequeued of CAPTURE queue. It looks to me that v4l2 core
> needs to intercept CMD_S
Le lundi 17 octobre 2016 à 13:37 +0200, Hans Verkuil a écrit :
> 1.5 Requests vs. w/o requests
>
> There are three options for drivers w.r.t. the request API:
>
> 1) The driver doesn't use the request API
> 2) The driver requires the request API
> 3) The request API is optional.
>
> It is not cl
Le vendredi 15 décembre 2017 à 16:56 +0900, Alexandre Courbot a écrit :
> Here is a new attempt at the request API, following the UAPI we agreed on in
> Prague. Hopefully this can be used as the basis to move forward.
>
> This series only introduces the very basics of how requests work: allocate a
Le vendredi 15 décembre 2017 à 16:56 +0900, Alexandre Courbot a écrit :
> Here is a new attempt at the request API, following the UAPI we agreed on in
> Prague. Hopefully this can be used as the basis to move forward.
>
> This series only introduces the very basics of how requests work: allocate a
Le mercredi 10 janvier 2018 à 14:07 -0200, Gustavo Padovan a écrit :
> v7 bring a fix for a crash when not using fences and a uAPI fix.
> I've done a bit more of testing on it and also measured some
> performance. On a intel laptop a DRM<->V4L2 pipeline with fences is
> runnning twice as faster tha
Le vendredi 12 janvier 2018 à 10:58 +0100, Anatolij Gustschin a écrit :
> On Fri, 12 Jan 2018 01:16:03 +0100
> Florian Boor florian.b...@kernelconcepts.de wrote:
> ...
> > Basically it works pretty well apart from the really strange
> > colors. I guess its
> > some YUV vs. RGB issue or similar. Her
Le mardi 19 décembre 2017 à 13:38 +0100, Neil Armstrong a écrit :
> >
> > The coda driver does not allow S_FMT anymore, as soon as the
> > buffers are
> > allocated with REQBUFS:
> >
> > https://bugzilla.gnome.org/show_bug.cgi?id=791338
> >
> > regards
> > Philipp
> >
>
> Thanks Philipp,
>
>
Le vendredi 26 janvier 2018 à 12:40 -0800, Randy Dunlap a écrit :
> > +Request API
> > +===
> > +
> > +The Request API has been designed to allow V4L2 to deal with
> > requirements of
> > +modern IPs (stateless codecs, MIPI cameras, ...) and APIs (Android
> > Codec v2).
>
> Hi,
> Just a qu
Le vendredi 03 août 2018 à 13:36 +0200, Guennadi Liakhovetski a écrit :
> This macro defines "information about quirks," not "quirks for
> information."
Does not sound better to me. It's "Quirk's information", vs
"information about quirks". I prefer the first one. In term of C
namespace the origna
Le lundi 06 août 2018 à 10:16 +0200, Paul Kocialkowski a écrit :
> Hi Hans and all,
>
> On Sat, 2018-08-04 at 15:50 +0200, Hans Verkuil wrote:
> > Hi all,
> >
> > While the Request API patch series addresses all the core API issues, there
> > are some high-level considerations as well:
> >
> > 1
Le samedi 04 août 2018 à 15:50 +0200, Hans Verkuil a écrit :
> Hi all,
>
> While the Request API patch series addresses all the core API issues, there
> are some high-level considerations as well:
>
> 1) How can the application tell that the Request API is supported and for
>which buffer type
Le mercredi 15 août 2018 à 09:11 -0300, Mauro Carvalho Chehab a écrit :
> Em Sat, 4 Aug 2018 15:50:04 +0200
> Hans Verkuil escreveu:
>
> > Hi all,
> >
> > While the Request API patch series addresses all the core API
> > issues, there
> > are some high-level considerations as well:
> >
> > 1) H
Le mercredi 22 août 2018 à 16:52 +0200, Paul Kocialkowski a écrit :
> Hi,
>
> On Wed, 2018-08-15 at 09:57 -0400, Nicolas Dufresne wrote:
> > Le lundi 06 août 2018 à 10:16 +0200, Paul Kocialkowski a écrit :
> > > Hi Hans and all,
> > >
> > > On Sat, 201
Le jeudi 23 août 2018 à 10:05 +0200, Paul Kocialkowski a écrit :
> Hi,
>
> On Wed, 2018-08-22 at 14:33 -0300, Ezequiel Garcia wrote:
> > On Wed, 2018-08-22 at 16:10 +0200, Paul Kocialkowski wrote:
> > > Hi,
> > >
> > > On Tue, 2018-08-21 at 17:52 +0900, Tomasz Figa wrote:
> > > > Hi Hans, Paul,
>
Le jeudi 23 août 2018 à 16:31 +0200, Hans Verkuil a écrit :
> > I propose adding these capabilities:
> >
> > #define V4L2_BUF_CAP_HAS_REQUESTS 0x0001
> > #define V4L2_BUF_CAP_REQUIRES_REQUESTS0x0002
> > #define V4L2_BUF_CAP_HAS_MMAP 0x0100
> > #define V4L2_BUF_CAP_H
Le vendredi 07 septembre 2018 à 16:34 +0200, Hans Verkuil a écrit :
> Support for stateless codecs and Request API will hopefully be merged
> for
> 4.20, and the next step is to discuss how to organize the userspace
> support.
>
> Hopefully by the time the media summit starts we'll have some bette
Le lundi 10 septembre 2018 à 12:37 -0300, Ezequiel Garcia a écrit :
> On Mon, 2018-09-10 at 17:00 +0200, Hans Verkuil wrote:
> > From: Hans Verkuil
> >
> > state->info was NULL since I completely forgot to set state->info.
> > Oops.
> >
> > Reported-by: Ezequiel Garcia
> > Signed-off-by: Hans V
Interesting, I just hit this problem yesterday. Same module as Steve,
with MIPI CSI-2 OV5640 (on Sabre Lite).
Tested-By: Nicolas Dufresne
Le mardi 11 septembre 2018 à 15:48 +0200, Hugues Fruchet a écrit :
> This patch serie fixes some problems around exposure & gain in OV5640
&
Le jeudi 20 septembre 2018 à 16:42 +0200, Hans Verkuil a écrit :
> Some parts of the V4L2 API are awkward to use and I think it would be
> a good idea to look at possible candidates for that.
>
> Examples are the ioctls that use struct v4l2_buffer: the multiplanar support
> is
> really horrible,
Hello Hans,
Le lundi 01 octobre 2018 à 10:43 +0200, Hans Verkuil a écrit :
> It turns out that we have both JPEG and Motion-JPEG pixel formats defined.
>
> Furthermore, some drivers support one, some the other and some both.
>
> These pixelformats both mean the same.
>
> I propose that we settl
Le lundi 08 octobre 2018 à 13:53 +0200, Hans Verkuil a écrit :
> Hi all,
>
> I would like to meet up somewhere during the ELCE to discuss userspace support
> for stateless (and perhaps stateful as well?) codecs.
>
> It is also planned as a topic during the summit, but I would prefer to prepare
>
Le vendredi 19 octobre 2018 à 09:28 +0200, Hans Verkuil a écrit :
> On 10/18/2018 06:08 PM, Ezequiel Garcia wrote:
> > Set up a statically-allocated, dummy buffer to
> > be used as flush buffer, which signals
> > a encoding (or decoding) stop.
> >
> > When the flush buffer is queued to the OUTPUT
Le vendredi 19 octobre 2018 à 07:35 -0400, Nicolas Dufresne a écrit :
> Le vendredi 19 octobre 2018 à 09:28 +0200, Hans Verkuil a écrit :
> > On 10/18/2018 06:08 PM, Ezequiel Garcia wrote:
> > > Set up a statically-allocated, dummy buffer to
> > > be used as flush bu
Le lundi 22 octobre 2018 à 12:37 +0900, Tomasz Figa a écrit :
> Hi Philipp,
>
> On Mon, Oct 22, 2018 at 1:28 AM Philipp Zabel wrote:
> >
> > On Wed, Oct 03, 2018 at 05:24:39PM +0900, Tomasz Figa wrote:
> > [...]
> > > > Yes, but that would fall in a complete redesign I guess. The buffer
> > > >
Le vendredi 02 novembre 2018 à 12:52 -0300, Ezequiel Garcia a écrit :
> Add two new API helpers, v4l2_fill_pixfmt and v4l2_fill_pixfmt_mp,
> to be used by drivers to calculate plane sizes and bytes per lines.
>
> Note that driver-specific paddig and alignment are not yet
> taken into account.
>
>
Le jeudi 08 novembre 2018 à 16:45 +0900, Tomasz Figa a écrit :
> > In this patch we should consider a way to tell userspace that this has
> > been opt in, otherwise existing userspace will have to remain using
> > sub-optimal copy based reclaiming in order to ensure that renegotiation
> > can work
Le mercredi 14 novembre 2018 à 00:27 +0200, Sakari Ailus a écrit :
> Hi Philipp,
>
> On Tue, Nov 13, 2018 at 04:06:21PM +0100, Philipp Zabel wrote:
> > From: John Sheu
> >
> > Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding
> > buffers if the queue is of type V4L2_MEMORY
Le lundi 15 octobre 2018 à 19:13 +0900, Tomasz Figa a écrit :
> On Wed, Aug 8, 2018 at 11:55 AM Tomasz Figa wrote:
> >
> > On Tue, Aug 7, 2018 at 4:37 PM Hans Verkuil wrote:
> > >
> > > On 08/07/2018 09:05 AM, Tomasz Figa wrote:
> > > > On Thu, Jul 26, 2018 at 7:57 PM Hans Verkuil wrote:
> > >
Le jeudi 08 novembre 2018 à 09:42 +0100, Hans Verkuil a écrit :
> > +static int vdec_queue_setup(struct vb2_queue *q,
> > + unsigned int *num_buffers, unsigned int *num_planes,
> > + unsigned int sizes[], struct device *alloc_devs[])
> > +{
> > + struct amvdec_session *s
Le mercredi 14 novembre 2018 à 13:12 +0900, Alexandre Courbot a écrit :
> On Wed, Nov 14, 2018 at 3:54 AM Nicolas Dufresne wrote:
> >
> >
> > Le mar. 13 nov. 2018 04 h 30, Alexandre Courbot a
> > écrit :
> > > The last buffer is often
Le jeudi 15 novembre 2018 à 11:49 -0500, Nicolas Dufresne a écrit :
> Sending buffers with payload size to 0 just for the sake of setting the
> V4L2_BUF_FLAG_LAST was considered a waste. Specially that after that,
> every polls should return EPIPE. So in the end, we decided the it
>
Le lundi 12 novembre 2018 à 14:23 +0100, Hans Verkuil a écrit :
> On 10/22/2018 04:49 PM, Tomasz Figa wrote:
> > Due to complexity of the video encoding process, the V4L2 drivers of
> > stateful encoder hardware require specific sequences of V4L2 API calls
> > to be followed. These include capabili
Le jeudi 15 novembre 2018 à 15:34 +0100, Hans Verkuil a écrit :
> On 10/22/2018 04:48 PM, Tomasz Figa wrote:
> > Due to complexity of the video decoding process, the V4L2 drivers of
> > stateful decoder hardware require specific sequences of V4L2 API calls
> > to be followed. These include capabili
Le samedi 17 novembre 2018 à 12:43 +0100, Hans Verkuil a écrit :
> > > As far as I know all codecs have resolution/metadata in the stream.
> >
> > Was this comment about what we currently support in V4L2 interface ? In
>
> Yes, I was talking about all V4L2 codecs.
>
> > real life, there is CODEC
Le samedi 17 novembre 2018 à 12:37 +0100, Hans Verkuil a écrit :
> > > Does V4L2_CID_MIN_BUFFERS_FOR_CAPTURE make any sense for encoders?
> >
> > We do account for it in GStreamer (the capture/output handling is
> > generic), but I don't know if it's being used anywhere.
>
> Do you use this valu
Le jeudi 22 novembre 2018 à 17:31 +0900, Alexandre Courbot a écrit :
> On Fri, Nov 16, 2018 at 1:49 AM Nicolas Dufresne wrote:
> > Le mercredi 14 novembre 2018 à 13:12 +0900, Alexandre Courbot a écrit :
> > > On Wed, Nov 14, 2018 at 3:54 AM Nicolas Dufresne
> > > wro
Le lundi 03 décembre 2018 à 12:48 +0100, Philipp Zabel a écrit :
> Add a single imx-media mem2mem video device that uses the IPU IC PP
> (image converter post processing) task for scaling and colorspace
> conversion.
> On i.MX6Q/DL SoCs with two IPUs currently only the first IPU is used.
>
> The h
Le mardi 08 janvier 2019 à 16:30 +0100, Philipp Zabel a écrit :
> Hi Nicolas,
>
> On Mon, 2019-01-07 at 17:36 -0500, Nicolas Dufresne wrote:
> > Le lundi 03 décembre 2018 à 12:48 +0100, Philipp Zabel a écrit :
> > > Add a single imx-media mem2mem video device that uses th
Le jeudi 10 janvier 2019 à 00:42 +0800, Ayaka a écrit :
> > There is a UVC media device that supports P010 device. We're discussing
> > about adding support for it on media. The full thread is at:
> >
> > https://lore.kernel.org/linux-media/20190109121900.hbrpttmxz3gao...@valkosipuli.retiisi.org.u
Le mercredi 09 janvier 2019 à 15:28 -0200, Mauro Carvalho Chehab a
écrit :
> Em Wed, 09 Jan 2019 11:52:45 -0500
> Nicolas Dufresne escreveu:
>
> > Le jeudi 10 janvier 2019 à 00:42 +0800, Ayaka a écrit :
> > > > There is a UVC media device that supports P010 device. We&
Le vendredi 11 janvier 2019 à 12:37 +0100, Hans Verkuil a écrit :
> v4l2_compliance gave a warning for the S_PARM test for output streams:
>
> warn: v4l2-test-formats.cpp(1235): S_PARM is supported for buftype 2, but not
> for ENUM_FRAMEINTERVALS
>
> The reason is that vivid mapped s_parm for ou
Le mardi 08 janvier 2019 à 16:30 +0100, Philipp Zabel a écrit :
> > # To demonstrate (with patched gst-plugins-bad
> > https://paste.fedoraproject.org/paste/rs-CbEq7coL4XSKrnWpEDw)
> > gst-launch-1.0 videotestsrc ! video/x-raw,format=YUY2 ! v4l2convert !
> > video/x-raw,format=xRGB ! kmssink
>
>
Le lundi 21 janvier 2019 à 11:59 +0100, Philipp Zabel a écrit :
> On Fri, 2019-01-18 at 14:37 +0100, Michael Tretter wrote:
> > Add device-tree bindings for the Allegro DVT video IP core found on the
> > Xilinx ZynqMP EV family.
> >
> > Signed-off-by: Michael Tretter
> > ---
> > Changes since v1:
Le jeudi 24 janvier 2019 à 18:06 +0900, Tomasz Figa a écrit :
> > Actually I just realized the last point might not even be achievable
> > for some of the decoders (s5p-mfc, mtk-vcodec), as they don't report
> > which frame originates from which bitstream buffer and the driver just
> > picks the mo
Le mercredi 23 janvier 2019 à 19:02 +0900, Tomasz Figa a écrit :
> On Sun, Nov 18, 2018 at 10:34 AM Nicolas Dufresne
> wrote:
> > Le samedi 17 novembre 2018 à 12:37 +0100, Hans Verkuil a écrit :
> > > > > Does V4L2_CID_MIN_BUFFERS_FOR_CAPTURE make any sense for encod
Le mercredi 23 janvier 2019 à 12:28 +0100, Hans Verkuil a écrit :
> On 01/23/19 11:00, Tomasz Figa wrote:
> > On Sat, Nov 17, 2018 at 8:37 PM Hans Verkuil wrote:
> > > On 11/17/2018 05:18 AM, Nicolas Dufresne wrote:
> > > > Le lundi 12 novembre 2018 à 14:
Le mercredi 23 janvier 2019 à 14:04 +0100, Hans Verkuil a écrit :
> > > Does this return the same set of formats as in the 'Querying
> > > Capabilities' phase?
> > >
> >
> > It's actually an interesting question. At this point we wouldn't have
> > the OUTPUT resolution set yet, so that would be
Le mardi 29 janvier 2019 à 16:44 +0900, Alexandre Courbot a écrit :
> On Fri, Jan 25, 2019 at 10:04 PM Paul Kocialkowski
> wrote:
> > Hi,
> >
> > On Thu, 2019-01-24 at 20:23 +0800, Ayaka wrote:
> > > Sent from my iPad
> > >
> > > > On Jan 24, 2019, at 6:27 PM, Paul Kocialkowski
> > > > wrote:
Le lundi 28 janvier 2019 à 16:38 +0900, Tomasz Figa a écrit :
> > > Nope, that's not what is expected to happen here. Especially since
> > > you're potentially in non-blocking IO mode. Regardless of that, the
> >
> > OK, how to handle that when userspace (for example gstreamer) hasn't
> > support
Le mardi 22 janvier 2019 à 12:53 +0200, Stanimir Varbanov a écrit :
> This ixes an issue when setting the encoder framerate because of
ixes -> fixes
> missing precision. Now the frameinterval type is changed to
> TYPE_CONTINUOUS and step = 1. Also the math is changed when
> framerate property is
Hi Hans,
Le mercredi 23 janvier 2019 à 11:44 +0100, Hans Verkuil a écrit :
> > + if (*nplanes != 0) {
> > + if (vq->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
> > + if (*nplanes != 1 ||
> > + sizes[0] < channel->sizeimage_encoded)
> > +
Le mercredi 23 janvier 2019 à 15:17 +0100, Michael Tretter a écrit :
> > I have a patch pending that allows an encoder to spread the compressed
> > output over multiple buffers:
> >
> > https://patchwork.linuxtv.org/patch/53536/
> >
> > I wonder if this encoder would be able to use it.
>
> I don
Le vendredi 25 janvier 2019 à 12:27 +0900, Tomasz Figa a écrit :
> On Fri, Jan 25, 2019 at 4:55 AM Nicolas Dufresne wrote:
> > Le jeudi 24 janvier 2019 à 18:06 +0900, Tomasz Figa a écrit :
> > > > Actually I just realized the last point might not even be achievable
&g
Le mercredi 30 janvier 2019 à 12:38 +0900, Tomasz Figa a écrit :
> > Yes, unfortunately, GStreamer still rely on G_FMT waiting a minimal
> > amount of time of the headers to be processed. This was how things was
> > created back in 2011, I could not program GStreamer for the future. If
> > we stop
Le vendredi 25 janvier 2019 à 12:59 +0900, Tomasz Figa a écrit :
> On Fri, Jan 25, 2019 at 5:14 AM Nicolas Dufresne wrote:
> > Le mercredi 23 janvier 2019 à 14:04 +0100, Hans Verkuil a écrit :
> > > > > Does this return the same set of formats as in the 'Querying
Le mercredi 30 janvier 2019 à 08:47 +0100, Hans Verkuil a écrit :
> On 1/30/19 4:41 AM, Nicolas Dufresne wrote:
> > Hi Hans,
> >
> > Le mercredi 23 janvier 2019 à 11:44 +0100, Hans Verkuil a écrit :
> > > > + if (*nplanes != 0) {
&
Le mercredi 30 janvier 2019 à 15:17 +0900, Tomasz Figa a écrit :
> > I don't remember saying that, maybe I meant to say there might be a
> > workaround ?
> >
> > For the fact, here we queue the headers (or first frame):
> >
> > https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master
Le vendredi 10 mai 2019 à 14:30 +0200, Hans Verkuil a écrit :
> On 5/10/19 2:24 PM, Laurent Pinchart wrote:
> > Hi Hans,
> >
> > On Fri, May 10, 2019 at 02:17:32PM +0200, Hans Verkuil wrote:
> > > On 5/10/19 1:28 PM, Laurent Pinchart wrote:
> > > > On Fri, May 10, 2019 at 10:57:26AM +0200, Hans Ve
Le vendredi 10 mai 2019 à 16:07 +0200, Hans Verkuil a écrit :
> On 5/10/19 3:51 PM, Nicolas Dufresne wrote:
> > Le vendredi 10 mai 2019 à 14:30 +0200, Hans Verkuil a écrit :
> > > On 5/10/19 2:24 PM, Laurent Pinchart wrote:
> > > > Hi Hans,
> > > >
> &
Le lundi 13 mai 2019 à 11:36 +0200, Hans Verkuil a écrit :
> On 4/30/19 10:31 AM, Hans Verkuil wrote:
> > This RFC patch adds support for the V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF flag.
> > It also adds a new V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability and
> > a v4l2_m2m_release_capture_buf(
Le mercredi 15 mai 2019 à 12:09 +0200, Paul Kocialkowski a écrit :
> Hi,
>
> With the Rockchip stateless VPU driver in the works, we now have a
> better idea of what the situation is like on platforms other than
> Allwinner. This email shares my conclusions about the situation and how
> we should
Le mercredi 15 mai 2019 à 19:42 +0200, Paul Kocialkowski a écrit :
> Hi,
>
> Le mercredi 15 mai 2019 à 10:42 -0400, Nicolas Dufresne a écrit :
> > Le mercredi 15 mai 2019 à 12:09 +0200, Paul Kocialkowski a écrit :
> > > Hi,
> > >
> > > With the Rockchip
Le lundi 25 février 2019 à 14:34 +0900, Tomasz Figa a écrit :
> On Fri, Feb 15, 2019 at 9:06 AM Ezequiel Garcia
> wrote:
> > On Wed, 2019-02-13 at 21:35 -0500, Nicolas Dufresne wrote:
> > > Le mer. 13 févr. 2019 à 16:23, Ezequiel Garcia
> > > a écrit :
> > &
Le mercredi 13 février 2019 à 18:15 -0300, Ezequiel Garcia a écrit :
> From: Pawel Osciak
>
> These controls are to be used with the new low-level decoder API for VP8
> to provide additional parameters for the hardware that cannot parse the
> input stream.
>
> Signed-off-by: Pawel Osciak
> [eze
Le mercredi 15 mai 2019 à 22:59 +0200, Paul Kocialkowski a écrit :
> Hi,
>
> Le mercredi 15 mai 2019 à 14:54 -0400, Nicolas Dufresne a écrit :
> > Le mercredi 15 mai 2019 à 19:42 +0200, Paul Kocialkowski a écrit :
> > > Hi,
> > >
> > > Le mercredi 15
Le jeudi 16 mai 2019 à 20:45 +0200, Paul Kocialkowski a écrit :
> Hi,
>
> Le jeudi 16 mai 2019 à 14:24 -0400, Nicolas Dufresne a écrit :
> > Le mercredi 15 mai 2019 à 22:59 +0200, Paul Kocialkowski a écrit :
> > > Hi,
> > >
> > > Le mercredi 15 mai 20
Le samedi 18 mai 2019 à 12:29 +0200, Paul Kocialkowski a écrit :
> Hi,
>
> Le samedi 18 mai 2019 à 12:04 +0200, Jernej Škrabec a écrit :
> > Dne sobota, 18. maj 2019 ob 11:50:37 CEST je Paul Kocialkowski napisal(a):
> > > Hi,
> > >
> > > On Fri, 2019-05
owski
> > > wrote:
> > > > Hi,
> > > >
> > > > Le mercredi 15 mai 2019 à 10:42 -0400, Nicolas Dufresne a écrit :
> > > > > Le mercredi 15 mai 2019 à 12:09 +0200, Paul Kocialkowski a écrit :
> > > > > > Hi,
> > > > > >
Le mardi 21 mai 2019 à 17:43 +0200, Thierry Reding a écrit :
> On Wed, May 15, 2019 at 07:42:50PM +0200, Paul Kocialkowski wrote:
> > Hi,
> >
> > Le mercredi 15 mai 2019 à 10:42 -0400, Nicolas Dufresne a écrit :
> > > Le mercredi 15 mai 2019 à 12:09 +0200, Paul Koc
t; wrote:
> > > > Hi,
> > > >
> > > > Le mercredi 15 mai 2019 à 10:42 -0400, Nicolas Dufresne a écrit :
> > > > > Le mercredi 15 mai 2019 à 12:09 +0200, Paul Kocialkowski a écrit :
> > > > > > Hi,
> > > > > >
>
Le mercredi 22 mai 2019 à 10:20 +0200, Boris Brezillon a écrit :
> On Wed, 22 May 2019 09:29:24 +0200
> Boris Brezillon wrote:
>
> > On Wed, 22 May 2019 15:39:37 +0900
> > Tomasz Figa wrote:
> >
> > > > It would be premature to state that we are excluding. We are just
> > > > trying to find one
Le mercredi 22 mai 2019 à 11:29 +0200, Paul Kocialkowski a écrit :
> Le mercredi 22 mai 2019 à 10:32 +0200, Thierry Reding a écrit :
> > On Wed, May 22, 2019 at 09:29:24AM +0200, Boris Brezillon wrote:
> > > On Wed, 22 May 2019 15:39:37 +0900
> > > Tomasz Figa wrote:
> > >
> > > > > It would be p
Le mercredi 22 mai 2019 à 13:39 +0200, Thierry Reding a écrit :
> On Wed, May 22, 2019 at 11:29:13AM +0200, Paul Kocialkowski wrote:
> > Le mercredi 22 mai 2019 à 10:32 +0200, Thierry Reding a écrit :
> > > On Wed, May 22, 2019 at 09:29:24AM +0200, Boris Brezillon wrote:
> > > > On Wed, 22 May 2019
Le mercredi 22 mai 2019 à 12:08 +0200, Thierry Reding a écrit :
> > 3. Does the HW do support single interrupt per frame (RK3288 as an
> > example does not, but RK3399 do)
>
> Yeah, we definitely do get a single interrupt at the end of a frame, or
> when an error occurs. Looking a bit at the re
Hi Mauro,
Le mercredi 29 mai 2019 à 08:28 -0300, Mauro Carvalho Chehab a écrit :
> Em Tue, 28 May 2019 14:02:19 -0300
> Ezequiel Garcia escreveu:
>
> > From: Boris Brezillon
> >
> > Users can define custom sizeimage as long as they're big enough to
> > store the amount of pixels required for a
Le mercredi 29 mai 2019 à 19:19 -0300, Fabio Estevam a écrit :
> Hi Sven,
>
> On Wed, May 29, 2019 at 5:55 PM Sven Van Asbroeck wrote:
>
> > I am now running 5.2-rc2 with Philipp's non-plus imx6q patch.
> >
> > Performance is still much worse than the Freescale baseline.
> >
> > I am not at al
Le mercredi 29 mai 2019 à 16:55 -0400, Sven Van Asbroeck a écrit :
> Philipp and Fabio,
>
> On Wed, May 29, 2019 at 12:53 PM Fabio Estevam wrote:
> > Does this patch from Philipp fix the problem?
> > https://git.pengutronix.de/cgit/pza/linux/commit/?h=imx-drm/fixes&id=137caa702f2308f7ef03876e164b
Le mercredi 29 mai 2019 à 16:55 -0400, Sven Van Asbroeck a écrit :
> Philipp and Fabio,
>
> On Wed, May 29, 2019 at 12:53 PM Fabio Estevam wrote:
> > Does this patch from Philipp fix the problem?
> > https://git.pengutronix.de/cgit/pza/linux/commit/?h=imx-drm/fixes&id=137caa702f2308f7ef03876e164b
Le mercredi 29 mai 2019 à 19:52 -0400, Nicolas Dufresne a écrit :
> Le mercredi 29 mai 2019 à 16:55 -0400, Sven Van Asbroeck a écrit :
> > Philipp and Fabio,
> >
> > On Wed, May 29, 2019 at 12:53 PM Fabio Estevam wrote:
> > > Does this patch from Philip
Le vendredi 31 mai 2019 à 12:07 -0400, Sven Van Asbroeck a écrit :
> Hello Nicholas, thank you so much for investigating.
>
> On Fri, May 31, 2019 at 11:34 AM Nicolas Dufresne
> wrote:
> > Now, if that pipeline was live, this would be a problem.
>
> This is where my
Hi,
Le vendredi 31 mai 2019 à 12:40 -0300, Mauro Carvalho Chehab a écrit :
> Hi all,
>
> For a long time, we were running an old Patchwork version. The thing is that
> we had applied some patches on the top of it, and the upgrade was not
> trivial.
>
> Today, we upgraded it to its latest stable
Le vendredi 31 mai 2019 à 12:40 -0300, Mauro Carvalho Chehab a écrit :
> Hi all,
>
> For a long time, we were running an old Patchwork version. The thing is that
> we had applied some patches on the top of it, and the upgrade was not
> trivial.
>
> Today, we upgraded it to its latest stable versi
Le lundi 03 juin 2019 à 13:24 +0200, Thierry Reding a écrit :
> On Wed, May 15, 2019 at 12:09:45PM +0200, Paul Kocialkowski wrote:
> > Hi,
> >
> > With the Rockchip stateless VPU driver in the works, we now have a
> > better idea of what the situation is like on platforms other than
> > Allwinner.
Le lundi 03 juin 2019 à 14:54 +0200, Hans Verkuil a écrit :
> On 5/31/19 10:55 AM, Philipp Zabel wrote:
> > This should enable MPEG-2 decoding on the Hantro G1 and JPEG encoding on
> > the Hantro H1 on i.MX8MM.
>
> That's the i.MX8M Mini, right? I think that's the official name for this
> SoC.
>
Le lundi 03 juin 2019 à 14:59 -0400, Nicolas Dufresne a écrit :
> Le lundi 03 juin 2019 à 14:54 +0200, Hans Verkuil a écrit :
> > On 5/31/19 10:55 AM, Philipp Zabel wrote:
> > > This should enable MPEG-2 decoding on the Hantro G1 and JPEG encoding on
> > > the Hantro H1
Le lundi 03 juin 2019 à 23:48 +0200, Jernej Škrabec a écrit :
> Dne ponedeljek, 03. junij 2019 ob 13:09:45 CEST je Boris Brezillon napisal(a):
> > The driver only supports per-slice decoding, and in that mode
> > decode_params->num_slices must be set to 1 and the slice_params array
> > should conta
Le mardi 04 juin 2019 à 10:12 +0200, Thierry Reding a écrit :
> On Mon, Jun 03, 2019 at 07:55:48PM -0400, Nicolas Dufresne wrote:
> > Le lundi 03 juin 2019 à 23:48 +0200, Jernej Škrabec a écrit :
> > > Dne ponedeljek, 03. junij 2019 ob 13:09:45 CEST je Boris Brezillo
Le jeudi 06 juin 2019 à 08:51 +0200, Boris Brezillon a écrit :
> On Thu, 6 Jun 2019 12:53:57 +0900
> Tomasz Figa wrote:
>
> > On Thu, Jun 6, 2019 at 1:46 AM Boris Brezillon
> > wrote:
> > > CAP_M2M_MPLANE means the device supports _MPLANE formats for both
> > > capture and output. Adjust the che
Le vendredi 07 juin 2019 à 16:58 +0300, Laurent Pinchart a écrit :
> Hi Marek,
>
> On Fri, Jun 07, 2019 at 03:55:05PM +0200, Marek Szyprowski wrote:
> > On 2019-06-07 15:40, Hans Verkuil wrote:
> > > On 6/7/19 2:47 PM, Hans Verkuil wrote:
> > > > On 6/7/19 2:23 PM, Hans Verkuil wrote:
> > > > > On
Le vendredi 07 juin 2019 à 16:39 +0200, Marek Szyprowski a écrit :
> Hi Hans,
>
> On 2019-06-07 16:11, Hans Verkuil wrote:
> > On 6/7/19 3:55 PM, Marek Szyprowski wrote:
> > > On 2019-06-07 15:40, Hans Verkuil wrote:
> > > > On 6/7/19 2:47 PM, Hans Verkuil wrote:
> > > > > On 6/7/19 2:23 PM, Hans
Le mardi 11 juin 2019 à 13:24 +0300, Laurent Pinchart a écrit :
> Hi Nicolas,
>
> On Fri, Jun 07, 2019 at 03:38:39PM -0400, Nicolas Dufresne wrote:
> > Le vendredi 07 juin 2019 à 16:58 +0300, Laurent Pinchart a écrit :
> > > On Fri, Jun 07, 2019 at 03:55:05PM +0200
Le mardi 11 juin 2019 à 13:56 +0200, Marek Szyprowski a écrit :
> Hi Hans,
>
> On 2019-06-11 09:52, Hans Verkuil wrote:
> > On 6/7/19 9:43 PM, Nicolas Dufresne wrote:
> > > Le vendredi 07 juin 2019 à 16:39 +0200, Marek Szyprowski a écrit :
> > > > Hi Hans,
Le mardi 11 juin 2019 à 20:12 -0400, Nicolas Dufresne a écrit :
> Le mardi 11 juin 2019 à 13:56 +0200, Marek Szyprowski a écrit :
> > Hi Hans,
> >
> > On 2019-06-11 09:52, Hans Verkuil wrote:
> > > On 6/7/19 9:43 PM, Nicolas Dufresne wrote:
> > > > Le
Le mercredi 12 juin 2019 à 11:17 +0300, Laurent Pinchart a écrit :
> Hi Nicolas,
>
> On Tue, Jun 11, 2019 at 08:09:13PM -0400, Nicolas Dufresne wrote:
> > Le mardi 11 juin 2019 à 13:24 +0300, Laurent Pinchart a écrit :
> > > On Fri, Jun 07, 2019 at 03:38:39PM -0400
Hi Dave,
Le jeudi 27 juin 2019 à 20:55 +0200, Stefan Wahren a écrit :
> From: Dave Stevenson
>
> H264 header come from VC with 0 timestamps, which means they get a
> strange timestamp when processed with VC/kernel start times,
> particularly if used with the inline header option.
> Remember the
Le jeudi 27 juin 2019 à 20:56 +0200, Stefan Wahren a écrit :
> From: Dave Stevenson
>
> There is an awkward situation with H264 header bytes. Currently
> they are returned with a PTS of 0 because they aren't associated
> with a timestamped frame to encode. These are handled by either
> returning
1 - 100 of 331 matches
Mail list logo
