[07:56] *** svarbanov has quit IRC (Ping timeout: 245 seconds)
[08:22] <jhautbois> Hi kbingham will you be at ELCE in Edimburgh ?
[08:35] <hverkuil> jhautbois: yes, he'll be there :-)
[08:36] <jhautbois> hverkuil, cool :)
[08:40] <kbingham> jhautbois, Yes, I will be there all week. Happy to meet up if you like.
[09:13] <jhautbois> kbingham, yep, I will be there until Thursday
[09:13] <jhautbois> we will discuss FPD-Link if you wish ;)
[09:14] <kbingham> jhautbois, Sounds great :)
[09:28] <kbingham> griffinp, "<mchehab> just remember that we're already full for the media summit... if a developer is interested on joining it, please ping me, after registering for ELCE"
[09:30] <griffinp> kbingham: ta :-)
[09:57] <pinchartl> kbingham: that's a real problem :-(
[09:57] <pinchartl> we're full with half of the registered attendees who won't show up
[09:58] <pinchartl> preventing other people with a legitimate interest to join
[09:58] <kbingham> griffinp, Here's the announcement mail with the current agenda https://www.mail-archive.com/linux-media@vger.kernel.org/msg135383.html
[09:59] * pinchartl still believes we should have used a separate registration system
[09:59] <kbingham> griffinp is in (or almost running I think?) the linaro home media team currently and is interested in media encoders/decoders and automated testing.
[10:00] <kbingham> pinchartl, Indeed. griffinp believed he was 'in' because he registered on the conference registration, hence bringing it up here for him.
[10:00] <griffinp> kbingham: yes thanks :)
[10:00] <griffinp> kbingham: pinchartl maybe I'm in the half which is already on the list ;-)
[10:04] <hverkuil> griffinp: you're in.
[10:05] <kbingham> hverkuil, Thanks for confirming :)
[10:06] <kbingham> I see the tinto room can hold 40 people. It will be a busy room :)
[10:06] <kbingham> (in boardroom config ?)
[10:06] <hverkuil> BTW, I don't think anyone will check anyway (that never happened in the past), so as long as there is room it should be OK.
[10:07] <hverkuil> kbingham: in a different configuration it can hold a lot more people. 100 seats in round table configuration.
[10:07] <hverkuil> (at least, that's what they claim)
[10:08] <kbingham> :D
[10:10] <griffinp> hverkuil: ah brilliant, thanks :)
[10:56] <hverkuil> Now, if everyone would just stop posting to linux-media, then maybe, just maybe I might have a chance to catch up! :-)
[11:03] <pinchartl> hverkuil: could everybody stop working for 6 months
[11:48] <kbingham> pinchartl, I can stop for six months if you like ...  :D
[11:49] <pinchartl> kbingham: not you, everybody else :-)
[11:49] <pinchartl> or rather stopping new development
[11:49] <pinchartl> we should all work on the backlog only
[11:51] <sailus> ribalda: Replied to the imx driver patch.
[11:51] <sailus> Small nits.
[11:51] <sailus> Plus a question on the exposure control.
[11:52] <sailus> ribalda: I can make the tiny fixes while applying the patch, but please answer the question. :-)
[11:53] <ribalda> sailus: hola hola
[11:54] <ribalda> I thought v4l2_ctrl_handler_setup()  was needed to be called allways at probe
[11:54] <ribalda> :)
[11:55] <ribalda> regarding the exposure time: of course, if I get access to proper doc I will fix it. and I plan to fix it allowing changing the fps
[11:55] <sailus> You don't need documentation to fix this; just see when the fps starts changing.
[11:57] <ribalda> not really.... on my app I need to get "extended exposure time"
[11:58] <ribalda> I think we will get access to the doc for the imx378 (full version).
[11:58] <sailus> Nice!
[11:58] <ribalda> and maybe I can extrapolate some of the info
[11:58] <ribalda> something like: s_param() modifying the range of exposure
[11:59] <ribalda> that is what I want to achieve. But right now I prefer that the eposure changes the fps
[12:04] <sailus> ribalda: If an application wishes to change the exposure without affecting the frame rate, how does it do that?
[12:05] <ribalda> going within a range that is not specified anywhere :)
[12:05] <sailus> The other drivers have a stable frame rate AFAIK.
[12:05] <sailus> You could easily figure out what it is.
[12:05] <sailus> Albeit we don't have a control to choose the behaviour.
[12:06] <sailus> In that driver, the only way to get to know the frame rate is through seeing the time between the frames. That's not very nice.
[12:06] <ribalda> sailus: hate you, you allways convince me to do the right stuff :)
[12:07] <ribalda> will experiment with the exposure until the framerate changes
[12:07] <ribalda> then substract 2% to the max range to be on the safe side
[12:07] <ribalda> sounds like a good plan?
[12:08] <sailus> ribalda: The edge is sharp, no need to subtract anything.
[12:08] <sailus> Substract.
[12:09] <ribalda> sailus: not sure I understand you. What I was planning to do was to run yavta and look at the fps. When the fps moves then I have reached the max exposure. the problem is that yavta is not pixel accurate
[12:09] <ribalda> also, can I do this as a separated patch? That way I can simply not commit that change to my tree
[12:10] <ribalda> and I can use the commit message to explain what I did
[12:11] <sailus> ribalda: There's enough precision to notice even a slight change, isn't there?
[12:12] <sailus> A separate patch is fine IMO.
[12:12] <ribalda> Not really:
[12:12] <ribalda> 1 (1) [-] none 1 2592000 B 1504.833982 1504.834276 30.010 fps ts mono/EoF
[12:12] <ribalda> 2 (2) [-] none 2 2592000 B 1504.867306 1504.867474 30.008 fps ts mono/EoF
[12:12] <ribalda> 3 (3) [-] none 3 2592000 B 1504.900630 1504.900884 30.008 fps ts mono/EoF
[12:12] <ribalda> 4 (0) [-] none 4 2592000 B 1504.933957 1504.956357 30.006 fps ts mono/EoF
[12:13] <sailus> Seems good enough to me.
[12:14] <pinchartl> ribalda: oohhh yavta :-)
[12:14] <sailus> The difference is around 1/7500.
[12:14] <ribalda> Let me run it longer
[12:15] <ribalda> pinchartl: the fps official meassurement
[12:17] <ribalda> 30.047:  So I am .3% off
[12:17] <ribalda> sailus:  seems good enough
[12:21] <ribalda> 3184 seems to be the max
[12:21] <sailus> What's the frame height?
[12:22] <sailus> Analogue crop, that is.
[12:22] <ribalda> the real height is 2304
[12:22] <ribalda> the vertical blanking I have no idea
[12:24] <sailus> There's a lot of it. :-)
[12:25] <sailus> ribalda: Shall you send a new version, or should I pick this one, fixing the nits?
[12:25] <ribalda> I send it myself
[12:25] <ribalda> with the doc patch and the exposure patch
[12:25] <ribalda> so all have the same v8
[12:25] <ribalda> will look better on patchwork
[12:27] <ribalda> sailus: one last thing
[12:27] <sailus> I might squash them.
[12:27] <ribalda> regarding: "goto done is fine here. One line less."
[12:27] <sailus> Yes?
[12:27] <ribalda> is ok to call v4l2_fwnode_endpoint_free(&bus_cfg);
[12:27] <ribalda> if alloc failed?
[12:28] <ribalda> please dont squash them, I think there will be some value on the commig msg :P
[12:28] <sailus> https://hverkuil.home.xs4all.nl/spec/kapi/v4l2-fwnode.html#c.v4l2_fwnode_endpoint_free
[12:28] <sailus> The latest fwnode patches aren't in yet, but the idea is the same.
[12:29] <ribalda> thanks!
[12:35] <sailus> ribalda: I'd need Rob H.'s ack on the DT binding patch.
[12:36] <ribalda> I will put him on cc on this v8
[12:37] <sailus> He usually reads the DT list and responds quickly.
[12:38] <sailus> The v4 is unchanged so you could try to ping him as well on irc. Up to you, of course.
[12:39] <hverkuil> sailus: quite amazing really, I wonder if that's all Rob's doing. It sometimes seems that way!
[12:52] <ribalda> btw, do you know his irc name?
[12:53] <sailus> ribalda: You have two modes for the sensor. Is the exposure limit the same for both?
[12:54] <ribalda> sailus: havent tried
[12:54] <sailus> ribalda: I'd guess he's not online now.
[12:54] <sailus> ribalda: Please do.
[12:54] <ribalda> I guess so, since both have the same framerate
[12:54] <sailus> I'd think so as well.
[12:54] <sailus> The third patch begs to be squashed. :-)
[12:55] <pinchartl> sailus: I was going to say the same
[12:55] <ribalda> hehehe, you are both evil
[12:55] <ribalda> :P
[12:58] <ribalda> sailus: both modes confired to have 0xc70 as max
[13:41] <sailus> mchehab: Can you post the two patches from your experimental branch to the list for review, please?
[13:41] <sailus> https://git.linuxtv.org/mchehab/experimental.git/commit/?h=mc-centric-flag-v9&id=36c28cfd59757585e04738d65afdc833de7b8042
[13:41] <sailus> That and the other one.
[13:41] <mchehab> sailus: those got posted
[13:42] <mchehab> let me seek for the thread
[13:42] <sailus> Hmm. Why can't I find them?
[13:43] <mchehab> https://patchwork.linuxtv.org/patch/51301/
[13:44] <mchehab> https://patchwork.linuxtv.org/patch/52250/
[13:45] <mchehab> https://patchwork.linuxtv.org/patch/52249/
[13:45] <mchehab> the last two ones
[13:45] <mchehab> 52250 and 52249
[13:46] <mchehab> they were attached on reply messages to pinchartl
[13:46] <sailus> mchehab: Those are already merged, aren't they?
[13:46] <mchehab> no, they shouldn't
[13:47] <mchehab> let me double check if I didn't merge by mistake, but I guess I didn't
[13:47] <sailus> At least some are.
[13:48] <sailus> c1a37dd5e87dc6a4c37e5fc68d7b26fb4a3ef097
[13:48] <mchehab> 51301 is a different thing... i posted it wrong
[13:48] <mchehab> the ones that are new are  52250 and 52249
[13:49] <sailus> How about this one:
[13:49] <sailus> https://git.linuxtv.org/mchehab/experimental.git/commit/?h=mc-centric-flag-v9&id=36c28cfd59757585e04738d65afdc833de7b8042
[13:49] <mchehab> this is: https://patchwork.linuxtv.org/patch/52249/
[13:50] <mchehab> not applied
[13:50] <mchehab> the last patch touching dvbdev is older:
[13:50] <mchehab> commit f3efe15a2f057d699d4f2d252e6bfc347abd7368
[13:50] <mchehab> Author: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
[13:50] <mchehab> Date:   Tue Jul 31 12:43:39 2018 -0400
[13:50] <mchehab> git log drivers/media/dvb-core/dvbdev.c
[13:51] <mchehab> 52250 depends on it too and also touches dvbdev.c
[13:51] <mchehab> so, neither 52250 or 52249 were applied upstream yet
[13:51] <mchehab> I'm waiting for those to be reviewed
[13:52] <mchehab> both were posted at the ML for review
[13:53] <sailus> This is odd.
[13:53] <mchehab> as reply to some late comments from pinchartl at a (version 1) /13 series
[13:53] <sailus> I can't find that on the list.
[13:53] <mchehab> (the version 2 of that specific series was the one actually applied)
[13:53] <sailus> The patch has the same commit message as the one that is merged.
[13:54] <mchehab> if patchwork received, it was broadcasted by VGER mailman
[13:54] <mchehab> no, it is a reply. patchwork keeps the name of the thread as the subject
[13:54] <mchehab> instead of getting the name of the actual patch
[13:54] <mchehab> you should seek for the last message with this subject:
[13:55] <mchehab> [03/13] v4l2-mc: switch it to use the new approach to setup pipelines
[13:55] <mchehab> in order to find the 52250 patch
[13:55] <sailus> I only see those posted on 15th September.
[13:56] <mchehab> I'll bounce both to you
[13:57] <mchehab> please check if you received both on your mailbox
[13:58] <mchehab> I bounced the e-mails I received myself from vger
[13:58] <mchehab> Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
[13:58] <mchehab>         id S1727171AbeI0Q60 (ORCPT <rfc822;mchehab@infradead.org>);
[13:58] <mchehab>         Thu, 27 Sep 2018 12:58:26 -0400
[14:23] <sailus> mchehab: Ah, I actually got the patch but it was lurking in a thread.
[14:24] <sailus> I'll review them.
[14:25] <sailus> mchehab: Looks good.
[14:25] <sailus> Please add:
[14:25] <sailus> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
[14:26] <mchehab> thanks!
[14:33] <ribalda> sailus: When you have some time please take a look to https://www.mail-archive.com/linux-media@vger.kernel.org/msg135201.html ?
[14:47] *** benjiG has left 
[15:05] *** prabhakarlad has left 
[15:17] <sailus> ribalda: That's the hard one.
[15:23] <svarbanov> hverkuil: can you take this https://patchwork.linuxtv.org/patch/52323/ in next pull request (if any)
[15:32] <mchehab> pinchartl: could you please also review those two patches? It would be great to add it together with the /13 series
[15:32] <mchehab>  52250 or 52249
[15:32] <mchehab> 52250 *and* 52249
[15:33] <mchehab> https://patchwork.linuxtv.org/patch/52249/
[15:33] <mchehab> https://patchwork.linuxtv.org/patch/52250/
[15:37] <hverkuil> svarbanov: I had no plans to make a new pull request. So this will slip to 4.21.