[12:01] <hverkuil> hi all
[12:02] <hverkuil> last meeting before my Christmas vacation, next time I'll be here for the meeting will be Jan 10.
[12:02] <mchehab> hi all
[12:02] <mkrufky> hi
[12:03] <mchehab> our last fixes pull request was not merged yet... from https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/, the last PR handled ws 3 days ago
[12:04] <mchehab> s/ws/was
[12:06] <hverkuil> I don't have anything more pending for 4.21.
[12:06] <mchehab> pinchartl: are you happy with IPU v4 PR?
[12:07] <hverkuil> I'm waiting for the 4.20 fixes to be merged and backported to 4.20. I'll respin the codec-timestamp-handling series at that time.
[12:07] <pinchartl> mchehab: happy, no, but I can live with it assuming my Reviewed-by got dropped :-)
[12:07] <mchehab> ok
[12:07] <mchehab> well, this is staging... quality doesn't need to be perfect
[12:08] <sailus> Hello!
[12:08] <mchehab> we need to make sure that whatever issue it has will be fixed when moving it out of staging
[12:08] <mchehab> (and that it won't be changing the uAPI on a way it would cause us problems)
[12:09] <sailus> mchehab, pinchartl: I believe the TODO file helps with that, and it's easier to track what's going on with the driver when it's in the staging tree.
[12:09] <hverkuil> sailus: note my "Re: [v4l-utils PATCH 0/2] META_OUTPUT buffer type support for v4l2-compliance" reply. I need a patch for v4l2-ctl as well (should be quite easy).
[12:09] <sailus> hverkuil: I noticed that but I haven't had the time to send a patch yet.
[12:10] <sailus> The accidental Reviewed-by tags were removed in v4; pinchartl's Reviewed-by: can be found in the last patch only.
[12:11] <mchehab> sailus: on what tree that fdf8298f7ff167e4e7522465a3c6e6b908cdb2af got merged?
[12:12] <sailus> mchehab: The documentation tree I think.
[12:12] <sailus> It's in linux-next; I'll figure out...
[12:12] <mchehab> I don't think it is there
[12:13] <sailus> Let me check...
[12:13] <mchehab> maybe the patch got rebased and changed its ID?
[12:14] <mchehab> not seeing at next either (on my local copy with is supposed to be updated)
[12:14] <sailus> mchehab: Yes.
[12:14] <sailus> 3d9bfb19bd705f503ac7afc2776d5d56dab88858
[12:15] <sailus> "scripts/kernel-doc: Fix struct and struct field attribute processing"
[12:15] <mchehab> ok, I see it now
[12:15] <sailus> So it seems to be in rc4.
[12:17] <mchehab> that is at docs-next branch
[12:17] <mchehab> with should be stable
[12:17] <mchehab> ok
[12:18] <mchehab> anything for the today's meeting?
[12:19] <hverkuil> Not from me.
[12:19] <hverkuil> Oh yes, one thing:
[12:19] <mchehab> sailus: just answered to your PR with the correct changeset... as a remind for myself when merging it :-)
[12:19] <mchehab> bbiab
[12:19] <hverkuil> mchehab, if you can review the '[PATCHv5 0/8] vb2/cedrus: use timestamps to identify buffers' series, then that would be great.
[12:20] <hverkuil> I'd like to have that ready for merging in our tree when 4.21-rc1 is released.
[12:20] <sailus> mchehab: I know the ImgU set isn't perfect, but I think there are tangible benefits from having it in the staging tree. I'll also address the pending checkpatch.pl warnings soonish.
[12:21] <hverkuil> FYI: the guys working on libreelec are already using the cedrus driver successfully (and yes, they know the API is not stable yet)
[12:28] <mchehab> back
[12:29] <mchehab> hverkuil: that is scary
[12:29] <mchehab> if libreelec users complain upstream about API breakages, we'll need to roll back the changes
[12:29] <hverkuil> I told them that it will change. They know this.
[12:30] <mchehab> I'll try to look into the timestamp patchset this week
[12:30] <hverkuil> It's good that they do this, that way the driver gets tested in real-world scenarios.
[12:30] <mchehab> yes, but having this on a distro probably means we won't be able to change the API after 4.21
[12:31] <mchehab> users of libreelec may complain if stuff stops working
[12:33] <hverkuil> libreelec is not a distro like debian. As I understand it it is a complete image and if you want to upgrade your HTPC you download and install a new image.
[12:33] <mchehab> actually you may upgrade stuff there too
[12:33] <mchehab> I have one libreelec image here on a RPi3
[12:34] <hverkuil> But yes, we do need to get this sorted out soon.
[12:39] <mchehab> ok. anything else?
[12:40] <hverkuil> 80 column vs parenthesis alignment.
[12:41] <mchehab> this deserves an specific meeting... I doubt we'll be able to solve it on the 20 mins left
[12:41] <mchehab> (and I won't be able to extend it after that time)
[12:41] <hverkuil> Yeah. For now I'm going with ( alignment as long as it doesn't look overly silly. And if it does, then look for alternative ways of solving it.
[12:42] <mchehab> looking for alternative ways is always a good idea
[12:43] <mchehab> i mean, big lines is a hint that the logic is becoming too complex, or that variable/function names are too big
[12:43] <mchehab> (not always the case - still it doesn't hurt checking if there's an alternate way of doing it)
[12:44] <mchehab> anyway, perhaps we can continue discussing it via e-mail - provided that the email's subject would be renamed...
[12:45] <mchehab> I suspect that a subject like "IRC chat" doesn't help to atract discussions :-p
[12:50] <mchehab> it could be worth to drop an e-mail about that, with a proper subject at the linux-media ML
[12:51] <mchehab> yeah, this could be messier, as I'm pretty sure we'll have all sorts of different opinions over there...
[12:51] <pinchartl> hverkuil: speaking of alignment, is it me, or were you examples missing a line ?
[12:52] <mchehab> pinchartl: yeah, it seems so
[12:52] <hverkuil> The examples were for demonstration purposes only, it's not real code, I indeed removed one argument.
[12:53] <pinchartl> you were missing the function call :-)
[12:53] <pinchartl> it was
[12:53] <pinchartl> foo(bar),
[12:53] <pinchartl>    foo(bar2));
[12:53] <hverkuil> Oops.
[12:54] <pinchartl> which made it a bit difficult to understand what you meant
[12:54] <hverkuil> now I see it. Sorry about that.
[12:55] <pinchartl> no worries
[13:02] <mchehab> yeah, that looked like a c++ recursive function, with a second optional argument :-p
[13:04] *** ChanServ sets mode: +v mchehab`
[18:11] <mchehab> (10:19:59) hverkuil: mchehab, if you can review the '[PATCHv5 0/8] vb2/cedrus: use timestamps to identify buffers' series, then that would be great.
[18:12] <mchehab> hverkuil: ^ Just reviewed it... looks on on a quick glance
[18:13] <mchehab> didn't carefully analized the changes at the MPEG controls (patch 8 and the corresponding change at the driver)
[18:13] <mchehab>  looks *OK* on a quick glance
[18:15] <hverkuil> Great. I'll ask bootlin to test it with the cedrus.
[18:18] <mchehab> ok