<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
***: johanhelsing has quit IRC (Remote host closed the connection)
<br> kbingham[m] has quit IRC (Remote host closed the connection)
<br> wonchul[m] has quit IRC (Read error: Connection reset by peer)
<br> nldvos[m] has quit IRC (Write error: Connection reset by peer)
<br> john3voltas[m] has quit IRC (Read error: Connection reset by peer)
<br> dafna2 has quit IRC (Remote host closed the connection)
<br> suleiman has quit IRC (Ping timeout: 244 seconds)
svarbanov: Hi Mauro, would you take this https://patchwork.linuxtv.org/patch/56338/ for next rc cycle, it fixes a regression
bbrezillon: <u>tfiga</u>: ok
svarbanov: mchehab, ^^^
mchehab: <u>svarbanov</u>: if it is a regression, send to me in a PR with "[GIT FIXES]" at the subject
***: LazyGrizzly has left
bbrezillon: <u>hverkuil</u>: which branch should I rebase "media: v4l2: Make sure all drivers set _MPLANE caps in vdev->device_caps" on ?
hverkuil: The media_tree master. But wait a bit longer, mchehab is still merging PRs I think.
mchehab: yes, I am
<br> right now handling this:
<br> <u>From</u>: Boris Brezillon <boris.brezillon@collabora.com>
<br> <u>Date</u>: Tue, 28 May 2019 14:02:17 -0300
<br> <u>Subject</u>: media: v4l2-common: Fix v4l2_fill_pixfmt[_mp]() prototypes
bbrezillon: hverkuil, mchehab: no problem, I'll wait
mchehab: hmm... looking at v4l2-common: Support custom imagesize in fill_pixfmt()
<br> it seems wrong to let sizeimage to be any random value passed from userspace without any kind of upper limit check...
<br> not 100% sure that *all* open source apps zero it before doing an ioctl
<br> and a too big value can have bad effects at the machine
<br> I mean, what happens if someone sets sizeimage to, let's say, 1TB?
<br> that's probably a bad example, as alloc routines will return ENOMEM - yet, one could set to a big enough value to make the machine unstable
<br> bbrezillon, hverkuil: I opted to comment at the patch, via e-mail
hverkuil: <u>mtretter</u>: ping
bbrezillon: <u>mchehab</u>: I'm fine with the upper limit, though twice the minimum size sounds a bit restrictive
mchehab: perhaps we could add a callback for drivers to define the upper limit (being for example max_width * max_height + align)
<br> only letting the user to define sizeimage when such callback is present
bbrezillon: <u>hverkuil</u>: do we have existing users of "custom sizeimage"?
<br> <u>mchehab</u>: ^
hverkuil: <u>bbrezillon</u>: venus driver if I remember correctly. svarbanov?
<br> I think there was another one as well, exynos perhaps?
bbrezillon: ok, I'll check what they do
hverkuil: It seems that got merged without anyone realizing it.
bbrezillon: hence the need for more helpers to control what's being done :)
hverkuil: yeah, helpers are good.
svarbanov: hverkuil, bbrezillon, venus driver currently doesn't allow the user to set sizeimage but we need that feature
hverkuil: Ah yes, you needed it. But I'm sure it was used already in some driver.
svarbanov: hverkuil, yeah probably s5p-mfc
<br> or mediatek as well (not sure)
<br> mchehab, is [GIT FIXES] needs to be based on media/fixes
mchehab: the feature itself is ok... but we should really set an upper limit, in order to avoid problems with existing apps and abuses
<br> <u>svarbanov</u>: "need" is a strong word
<br> it shoud actually apply cleanly at the fixes branch
<br> (or with just trivial conflicts)
<br> my scripts are smart enough to recognize and properly handle the patch origin
svarbanov: mchehab, it applies cleanly on both, but I wanted to be sure :)
mchehab: getting just the patches, and not depending on the origin branch
mtretter: <u>hverkuil</u>: pong
hverkuil: I tried to enable the Allegro driver in a .config and I noticed that it depends on ARCH_ZYNCMP, but I see only ARCH_ZYNC.
<br> I'm not sure who is at fault here.
mchehab: <u>hverkuil</u>: some of your patches are causing checkpatch warnings because author != SoB:
<br> <u>media</u>: videobuf2-vmalloc: get_userptr: buffers are always writable
<br> <u>Author</u>: Hans Verkuil <hverkuil@xs4all.nl>
<br> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
<br> could you please fix this on next submissions?
hverkuil: Why don't I get those checkpatch warnings when I prepare a pull request?
mchehab: do you use --strict?
hverkuil: I will always forget this since if I post a patch manually (i.e. not using git-email) I would have to explicitly switch email user.
<br> I thought I used --strict. I'll double check.
mtretter: <u>hverkuil</u>: ARCH_ZYNQMP is ARCH=arm64
hverkuil: <u>mchehab</u>: I had --strict in one git hook script, but not the other. That might be the cause.
mchehab: perhaps. not sure if this warning is enabled only with --strict
bbrezillon: <u>mchehab</u>: I could pass an extra max_sizeimage arg to the fill_pixfmt() funcs
mchehab: $ git show --pretty=email|./scripts/checkpatch.pl -
<br> <u>WARNING</u>: Missing Signed-off-by: line by nominal patch author 'Hans Verkuil <hverkuil@xs4all.nl>'
<br> no, it shows even without it
<br> hmm... nice! --showtypes provide the name of the check that failed:
<br> $ git show --pretty=email|./scripts/checkpatch.pl - --show-types
<br> WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Hans Verkuil <hverkuil@xs4all.nl>'
hverkuil: <u>mchehab</u>: urgh, I had --no-signoff in my git hook scripts.
<br> I've removed it, I'll see what happens going forward.
<br> <u>mtretter</u>: oops, I tried to enable that driver for arm32 :-)
mchehab: I added --show-types to my scripts. that will help when reporting issues to identify what part of checkpatch is complaining
<br> perhaps you added --no-signoff to avoid double-signing a patch with different emails
hverkuil: I had some major problems when I was using my cisco email for patches, it might be a left-over from that time.
mchehab: perhaps.
<br> one thing you could do to fix such things is something like:
<br> git filter-branch -f --msg-filter 'cat|grep -v "Signed-off-by: My Name"; echo "Signed-off-by: My Name <myname@my.emal>"'origin/master..
<br> (I guess --msg-filter also catches Author, but not 100% sure)
<br> the grep -v would also remove duplicated SOBs
hverkuil: <u>mtretter</u>: posted a patch to fix a compile error for the allegro driver.
<br> Not sure why that wasn't seen before...
mtretter: <u>hverkuil</u>: I had ccflags-y += -I$(src) in the Makefile, which has been removed by mchehab
hverkuil: <u>mchehab</u>: can you pick up https://patchwork.linuxtv.org/patch/56432/ to fix the allegro build?
paulk-leonov: <u>hverkuil</u>: so I've been looking at using flags to get rid of padding fields, and it doesn't work out so well
<br> <u>hverkuil</u>: my preferred approach would be to keep padding fields as needed and u64 flags always
<br> (for the HEVC controls)
<br> I also don't like the idea of making random fields bigger than they should be
<br> since the HEVC spec puts precise constraints on the elements
<br> (range-wise)
<br> and I don't really see the issue with padding fields anyway
<br> <u>hverkuil</u>: at least I've updated to using proper flags now (instead of u8 *_flag fields) and checked that the structure is laid out the same using mripard's scripts
<br> (I'd rather we discuss this now instead of spinning another hevc iteration over this)
mchehab: <u>mtretter</u>: funny enough, it built here (i386)
<br> perhaps compile_test is not working?
<br> <u>hverkuil</u>: yeah, I'll pick it
mtretter: the driver is built for arm64 or if compile_test is enabled. Looks OK to me.
mchehab: yeah, tested here, it is building on i386
<br> let me cleanup cccache
<br> perhaps it is something related to ccache
<br> now, it is generating two sparse/smatch warnings:
<br> drivers/staging/media/allegro-dvt/allegro-core.c:drivers/staging/media/allegro-dvt/allegro-core.c:1849:36: warning: constant 0xffffffff00000000UL is so big it is unsigned long long
<br> drivers/staging/media/allegro-dvt/allegro-core.c:drivers/staging/media/allegro-dvt/allegro-core.c:865:24: error: incompatible types in comparison expression (different type sizes)
<br> a/drivers/staging/media/allegro-dvt/allegro-core.c
<br> +++ b/drivers/staging/media/allegro-dvt/allegro-core.c
<br> @@ -866 +866 @@ static ssize_t allegro_mbox_read(struct allegro_dev *dev,
<br> - (mbox->size - (head + sizeof(*header))));
<br> + (size_t)(mbox->size - (head + sizeof(*header))));
<br> @@ -1849 +1849 @@ static void allegro_copy_fw_codec(struct allegro_dev *dev,
<br> - (dev->firmware.paddr & 0xffffffff00000000UL) - MCU_CACHE_OFFSET;
<br> + (dev->firmware.paddr & 0xffffffff00000000ULL) - MCU_CACHE_OFFSET;
<br> need this to shut up the warnings
hverkuil: paulk-leonov: the problem with padding fields is that you then have to decide how they should be filled. If userspace sets such a control and it is identical to the current value, except for the padding field, is it then different or not? It just doesn't really fit into the way controls work.
paulk-leonov: <u>hverkuil</u>: mhh, does this have practical consequences that could be detrimental? I feel like codec controls should be expected to change often anyway.
hverkuil: I have no problem with increasing the type from u8 to u16 (or whatever is needed to avoid padding). With a comment explaining that it is done to avoid padding I think it's perfectly fine.
paulk-leonov: To me it looks really out of place
hverkuil: New codec controls are often added, but existing controls do not change (well, if it is a menu control new menu items can be added, but otherwise they are part of the ABI)
paulk-leonov: and there are cases where we need to increase by amounts that can be extended as types
<br> that cannot*
<br> <u>hverkuil</u>: not sure I get your point about existing controls that need to not change
hverkuil: Sorry, there may be some confusion there.
<br> Currently these compound codec controls are in staging and are not part of the uAPI. So we can change them. But once they become part of the uAPI it is no longer possible to make changes to e.g. the layout of a compound control.
paulk-leonov: right
hverkuil: The problem with padding fields is simply that it is not clear what the driver and what userspace should do with them. Are they part of the control's value? Should it be ignored?
<br> By choosing types to avoid having to pad you also avoid all these questions. And I see no downside.
paulk-leonov: I don't see how it is different than having extended fields where the extra bits are also not supposed to be used
<br> and more generally, the interpretation of padding fields can be specified as well
<br> I think I understand the issue at hand but I don't see how extending unrelated fields is a superior solution
<br> and padding fields are quite common in kernel UAPI anyway
<br> I wasn't under the impression that they caused any problem in particular
bbrezillon: <u>ndufresne</u>: oh, so you think custom/user-defined bytesperline/sizeimage is useful
hverkuil: But for many of the existing u8 fields you are not using all the 8 bits either. In an application you can just do ctrl.foo = 8, and whether foo is u8 or u16 doesn't matter. Whereas with padding you need to set foo AND set the padding field.
bbrezillon: <u>hverkuil</u>: or use the "struct bla = { /* only fill non-zero fields */ };" trick
hverkuil: In general I think padding fields are problematic. Since it requires extra work to define who should fill them with what value.
paulk-leonov: <u>hverkuil</u>: in any case, our controls have fields that can be unused (e.g. when the related flag that enables them is not set) so I think we need to solve the issue at this level as well
<br> so I think we would benefit from having a general guideline about it, instead of trying to make the issue disappear by hiding out the padding in other fields
bbrezillon: paulk-leonov: if their validity is controlled by a flag, that should be fine
paulk-leonov: <u>bbrezillon</u>: yes but how to fill the values when they are unused then?
<br> it's the same issue as padding fields
<br> which are *always* considered unused
bbrezillon: the only problem is when you have padding fields that can be later re-purposed to store something useful
hverkuil: They may not be the same if you compare controls in std_equal(). Right now that just does a memcmp for compound controls.
paulk-leonov: <u>bbrezillon</u>: right, this is a case where it becomes problematic, but we can just as well decide to disallow these cases
hverkuil: It has no knowledge of 'unused fields' or 'padding fields'.
paulk-leonov: <u>hverkuil</u>: so unused legit fields will have the same issue
<br> <u>hverkuil</u>: if that's the issue I'm up for doing something more fine-grained for codec controls there
bbrezillon: my comment was more general, for anything V4L related, you should trust hverkuil :)
paulk-leonov: <u>bbrezillon</u>: hehe I definitely trust hverkuil but I'm trying to understand the issue and why the solution makes sense
hverkuil: paulk-leonov: unused legit fields have the same issue, yes. I hadn't realized that. Do you have any idea how many of such fields there are?
ezequielg: <u>hverkuil</u>: bbrezillon: I just replied on the VPU discussion sugggesting to drop PATCH 3 and take the rest.
<br> sorry I'm late to the party, blame timezones.
bbrezillon: <u>ezequielg</u>: doesn't work unfortunately
paulk-leonov: <u>hverkuil</u>: well, given that the codec pipelines are highly configurable, I think we can expect them to be very common -- from a quick look at HEVC I'd say ~20 fields across all structures
bbrezillon: unless hverkuil is okay fixing that for us :)
ezequielg: <u>bbrezillon</u>: why?
<br> i'm blind.
bbrezillon: oh no, you're right
<br> the prototype didn't change
<br> but it still doesn't work
<br> 'cause I'm no longer calculating ->sizeimage in the rk driver
<br> I was relying on fill_pixfmt() for that
ndufresne: bbrezillon, sizeimage, not really, bytesperline, absolutly, since the width cannot represent all possible HW alignment requirement
<br> for vertical alignment, we adapt height simply
<br> this is what we are currently working on for the capture drivers on ZynqMP
<br> so the we can keep capture side allocation (needed for multiplexing), but adapts to the encoder requirement
bbrezillon: <u>ndufresne</u>: couldn't one want to have a bigger sizeimage to store extra meta-data in the buffer?
ndufresne: maybe, but I never had any use for this, usually that's a driver thing, not really userspace
<br> in userspace, we have other easy means to carry metadata
bbrezillon: <u>ezequielg</u>: see changes done to vidioc_try_fmt() in patch 10
ndufresne: bbrezillon, but as ezequielg said, it won't hurt to remove in the short term, we are do far from looking into zero-copy transcoding pipeline or anything complex like this
<br> but whenever you add helper with such limitation, it's so much more work later to add it ...
<br> specially that importation path in v4l2 isn't so nice atm
hverkuil: <u>bbrezillon</u>: I'm confused. Why would dropping patch 3 be a problem? v4l2_fill_pixfmt_mp is for uncompressed formats only, and there user-specified sizeimage values are not allowed.
<br> And you're not using that function for the compressed formats.
ndufresne: hverkuil, which paragraph explicitly disallow that ?
ezequielg: yeah, i'm also confused.
ndufresne: (again, I don't see much use of adapting through sizeimage, one can use height for that)
ezequielg: in any case, i'm building it to run some tests and look closer.
hverkuil: Ah, I thought the patch updating the spec was already applied, but I requested a new version of it which hasn't been posted yet.
<br> <u>svarbanov</u>: ping! ^^^^
bbrezillon: hverkuil, ezequielg: you're right, my bad
hverkuil: <u>ndufresne</u>: https://patchwork.kernel.org/patch/10898631/
bbrezillon: I thought this patch was also adding the sizeimage override
<br> but this was already done
ezequielg: running tests...
ndufresne: hverkuil, ok, you are not disallowing it, you simply document that the driver will (currently) always override it
hverkuil: I would really like to have svarbanov's patch (well, a v3 of it) being merged first before merging the rockchip series.
ndufresne: hverkuil, to me this nuance is important, because we can only be wrong when disallowing things
<br> as no one can read in the future
svarbanov: <u>hverkuil</u>: yep, I didn't posted a new version :(
<br> will try post it today
<br> hverkuil, I mostly was confused from Mauro's comment about libv4l and your comments "do we need this".
hverkuil: <u>ndufresne</u>: for uncompressed formats drivers will always set sizeimage, ignoring what userspace set. Doing anything else will very likely cause problems.
<br> <u>svarbanov</u>: yeah, you can ignore that. Since drivers already DO use this, it makes sense to just document it.
paulk-leonov: <u>hverkuil</u>: do you think it would be agreeable to specify that unused and padding fields must be set to zero, as to allow efficient memcmp? I would expect that most users memset 0 the ctrl structs anyway
ndufresne: hverkuil, until we discover a valid use case, it's always the same story ;-P
<br> but I don't see a use case either
<br> at the same time, I don't see any problems a bigger buffer can cause
<br> but inside drivers, it can be a mess when you have to maintain two sizes
paulk-leonov: <u>hverkuil</u>: (it's also very fine if you'd like more time to think about the issue, I can hold off the new H265 series version)
hverkuil: paulk-leonov: do we need h264/hevc support similar to this as well? https://git.linuxtv.org/media_tree.git/commit/?id=bfe819509f4eb58288796e1d3aefd7d18cc6d9af
<br> I suspect we need that.
paulk-leonov: <u>hverkuil</u>: yes that's very likely
hverkuil: Regarding unused/padding fields:
<br> normally when you set a control to the same value it already has, nothing happens. I.e. the s_ctrl op isn't called.
<br> But for compound controls changes in padding fields or unused fields will cause s_ctrl to be called, even though effectively nothing changed.
<br> There are two options, I think: either implement a compare in std_equal, or document this behavior so userspace can be smart about it and avoid unnecessary changes.
<br> I'm afraid that implementing a proper compare in std_equal will very quickly become messy, esp. as we add more of these compound controls.
<br> Hmm.
<br> How about adding code to std_validate that sets padding fields and unused fields to a fixed value?
<br> I think that will work and be fairly practical.
paulk-leonov: <u>hverkuil</u>: works for me and indeed, avoids some hassle down the line
mchehab: <u>bbrezillon</u>: as there are more discussions with regards to patch 3, I'll remove it from the PR and apply the others that won't depend on it
ezequielg: <u>mchehab</u>: that works for us, thanks.
tonyk: <u>hverkuil</u>: on vivid_thread_vid_out_tick, you say that "Only dequeue buffer if there is at least one more pending. This makes video loopback possible.". Why this is a condition to loopback frames?
mchehab: <u>ezequielg</u>: ok, patches applied (except for patch 3)
ezequielg: awesome!
hverkuil: <u>tonyk</u>: in vivid_copy_buffer() the loopback happens: and in order to loop video (i.e. copy an output buffer to a capture buffer) you need to have an output buffer available in the first place.
<br> If the output queue can go completely empty, then there wouldn't be anything to copy :-)
***: benjiG has left
tonyk: makes sense, thanks!
hverkuil: <u>mchehab</u>: nice! That cleaned out my todo list!
mchehab: good!
tonyk: <u>hverkuil</u>: but why we need that !list_is_singular(&dev->vid_out_active)? why vivid doesn't dequeue if there's a single on the list?
bbrezillon: <u>mchehab</u>: thanks
hverkuil: <u>tonyk</u>: if vivid would dequeue it, then vivid no longer owns that buffer can it cannot use it for video looping.
<br> The vb2_buffer_done function is basically a transfer of ownership of the buffer from the driver to the vb2 framework and from there to userspace when the application calls DQBUF.
koike: <u>hverkuil</u>: Hi Hans, so if I understand this part of the code correctly https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/vivid/vivid-kthread-out.c#L56 you need two buffers in the list to continue right?
<br> I didn't really get why two buffers are required. Can't it use one buffer? Dequeue it, copy the frame to the capture and mark that output buffer as done?
<br> we are asking it because tony is working on implement an output node, and he is searching the best design to do it, so comparing to vivid
hverkuil: in vivid the capture and output video devices operate independently. So in order for video loopback to work you need to have both a capture and an output buffer. The solution I chose was to just always keep one output buffer around so that there always is an image that can be copied to a capture buffer.
<br> Note that this is actually how video output device work anyway: you always want a buffer that the video transmitter can read from.
<br> If userspace can't provide new output buffers fast enough, then you can't just stop transmitting video. Instead you reuse the last buffer.
koike: right
shuah: <u>hverkuil</u>: Hi Hans! Any thoughts on the 5.2-rc1 vimc issues I reported?
<br> <u>koike</u>: same question for you. Streaming doesn't work - Hope I didn't miss something
hverkuil: <u>shuah</u>: no thoughts whatsoever :-) I haven't had any time to look at vimc.
<br> <u>koike</u>: if you can investigate, then that would be great. I'm away tomorrow and Friday, so having someone else looking at this would be very nice.
koike: yes, I'll take a look, I also need to review some other patches and I want to raise a discussion regarding the internal design, I'll send an email
hverkuil: thanks!
<br> I'm back on Monday, so if you want to discuss something we can do it then.
koike: ok
shuah: <u>hverkuil</u>: thanks
koike: <u>hverkuil</u>: just to make sure I understand. So, when the capture ticks, it goes to the output buf queue and get a frame. But when the output ticks, it just drops a buffer from the output buf queue (but leaves a buffer for the capture), is that correct?
mchehab: <u>ezequielg</u>: could you please make the kernelci reports less noisy? there's no sense on keep flooding the ML with "0 regressions" posts
<br> if one wants to get flooded by such crap, we could create some ML for such purpose, but at the main ML, please just report errors
-: mchehab is almost at the verge of adding a rule directing everything from kernelci.org to /dev/null on my fetchmail
ezequielg: <u>mchehab</u>: i'm on it - don't null them just yet
mchehab: ok, thanks!
<br> if you want, I can create a ML at linuxtv.org for the ones that may eventually want everything
ezequielg: np, sorry for the noise.
mchehab: np
hverkuil: <u>koike</u>: when the output ticks it checks that there are at least two buffers in the vid_out_active list. If that's not the case, it just returns, otherwise it returns the older buffer to vb2.
mchehab: <u>ezequielg</u>: do you know anything about this patch?
<br> s5p-jpeg: Add support for multi-planar APIs
<br> it was signed by Thierry Escande from Collabora, and it is there since 2017
<br> <u>Patchwork</u>: http://patchwork.linuxtv.org/patch/41612/
<br> (1 hunk fails to apply - the remaining ones apply cleanly)
ezequielg: <u>mchehab</u>: I don't have any more context about that patch. I will investigate. However, the feedback from Jacek makes sense to me.
gtucker: <u>mchehab</u>: there are some actual test failures in the report for v4l2-compliance-uvc
mchehab: it makes sense to me too. I just want to get rid of this patch from the patchwork's queue
gtucker: they are not reported as regressions because they never passed since we started running these tests
ezequielg: <u>mchehab</u>: can you please pick a state for the patch, that reflects the fact that time has passed and there was no follow-up?
mchehab: <u>gtucker</u>: I see. Yet, keep repeating that it is failing on 9 tests every time won't make it fixed
ezequielg: <u>mchehab</u>: oh, I found it on my queue. We've closed this.
gtucker: <u>mchehab</u>: true, of course it takes someone to fix the problem in the code
ezequielg: <u>mchehab</u>: so we don't care anymore. Obsolete or anything else.
gtucker: <u>mchehab</u>: so what we can do quickly is only send the reports to the regular list kernel-build-reports@lists.linaro.org and stop sending them to linux-media for now
mchehab: <u>ezequielg</u>: ok, I'll mark it as "Obsoleted"
koike: <u>hverkuil</u>: right, thanks! And when the capture ticks it just gets the first entry from the vid_out_active list and copies the frame, https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/vivid/vivid-kthread-cap.c#L270 , right, so if the capture ticks faster, it just copies the same frame
mchehab: <u>gtucker</u>: works for me.
<br> as I said before, it would be nice to get the reports there, but only when there is something that require actions
<br> like regressions, compilation breakages, new warnings, etc
gtucker: <u>mchehab</u>: you mean new regressions only then I guess? i.e. if a regression is not fixed in the next test run, don't report it again?
mchehab: (before = when we discussed about kernelci reports)
hverkuil: <u>koike</u>: correct.
koike: <u>hverkuil</u>: right, thanks
mchehab: in the specific case of v4l2-compliance tests, yes, that's what I meant
<br> keep reporting the same thing over and over will only make people ignore the reports as a hole
gtucker: <u>mchehab</u>: ok, then I guess it would require another report to say a regression has been fixed then?
mchehab: yeah, a regression fix warning makes sense to me
<br> s/warning/email/
gtucker: right, ok that makes sense, thanks
mchehab: thank you
gtucker: I have stopped the reports, the ones that just arrived for kernel v5.2-rc2-133-g64b42d8eee9b were the last one in the pipeline to be sent to linux-media
ezequielg: <u>gtucker</u>: thanks for the quick fix!
gtucker: np - hopefully we'll have a proper fix soon with improved reports
mchehab: <u>gtucker</u>: thanks!