[03:29] *** ChanServ sets mode: +v mchehab
[12:01] <hverkuil1> sailus: ping
[12:01] <sailus> hverkuil1: Pong.
[12:01] <hverkuil1> Ah, I wasn't sure if you were on ine.
[12:04] <hverkuil1> mchehab: ping
[12:08] <hverkuil1> meeting? Hello?
[12:09] <sailus> EHLO
[12:09] <pinchartl> hverkuil1: if you stopped replying to v4l2-ctrls messages in #v4l it might help :-)
[12:10] <mchehab> hi all
[12:10] <mchehab> sorry, got distracted wit controls :-)
[12:10] <sailus> Controls, it goes both ways...
[12:11] <hverkuil1> Any patches we should review?
[12:11] <hverkuil1> Two from me: https://patchwork.linuxtv.org/patch/42953/ and https://patchwork.linuxtv.org/patch/42954/
[12:11] <mchehab> the first one is OK
[12:12] <mchehab> I didn't like the second one...
[12:12] <sailus> I have a few patches for the V4L2 LED flash class:
[12:12] <hverkuil1> Yeah, I'll get back to you on the second one.
[12:12] <sailus> http://www.spinics.net/lists/linux-media/msg119733.html
[12:12] <mchehab> I'll propose an alternative to it
[12:13] <sailus> I'll update my async sub-notifier RFC set based on review comments. It's here:
[12:13] <sailus> http://www.spinics.net/lists/linux-media/msg118764.html
[12:13] <hverkuil1> Just in case it wasn't made fully clear: this is the place to ask for review of core patches. Don't expect that other developers will have seen it, so be pro-active if you want a quick and timely review by others.
[12:13] <sailus> I believe Niklas has some of the same patches in his set and there are likely some conflicts as well. I'll sort that out with him.
[12:14] <hverkuil1> sailus: that's the old async series, right? I was waiting for a new series before reviewing after you've sorted out the differences with Niklas. Is that OK?
[12:15] <sailus> There's no new one yet, largely due to my holidays.
[12:15] <sailus> That's fine.
[12:15] <sailus> I also have two patches making fwnode fields const in a few places, based on review comments I got some half a year ago. I'll repost them.
[12:15] <mchehab> sailus: when you send the new async series, ping me. I'll add it to my review TODO list too
[12:15] <sailus> mchehab: Ack.
[12:16] <syoung> 2017-08-10T06:46:55: Error: E-NHT-102-069: [WorkPoolThread]: Failed to send HTTP response back to client 'sig-9-145-162-35.de.ibm.com' (9.145.162.35) on socket '51'. (-19:General failure)
[12:16] <syoung> oops
[12:16] <sailus> The fwnode patches depend on other patches in linux-pm tree. Rafael put these patches to a separate branch on -rc1 so we could possibly merge them for 4.14.
[12:16] <syoung> ignore that :)
[12:16] <mchehab> I didn't check the backlogs from last weeks' meeting... anything for me to review?
[12:17] <mchehab> it has been a little bit crazy here, as I'm about to move to a new place... lots of things to organize
[12:18] <mchehab> btw, I guess we can also use the submaintainers ML for core changes that need everybody to review
[12:19] <hverkuil1> sailus: will that new series include support for partial configuration in case one or more subdevs are not found/dead? If so, then I'd like to discuss that beforehand. (For the record: we need that functionality, just how it is implemented is something I'd like to talk about).
[12:19] <sailus> mchehab: Or just cc people? Then everyone knows who's been explicitly informed.
[12:19] <mchehab> for uAPI, I like the idea to always c/c the API ML, but that doesn't apply to kAPI changes
[12:19] <hverkuil1> mchehab: nothing to review from the past two weeks: you weren't the only one on vacation/gone.
[12:19] <sailus> I don't really have an opinion but I find myself using cc too seldom.
[12:19] <mchehab> :-)
[12:20] <mchehab> sailus: the problem with CC is that checkpatch.pl adds a lot of noise to the CC ML
[12:20] <mchehab> I receive a lot of "dirty" things there...
[12:20] <hverkuil1> I think mentioning it in the #v4l room is usually sufficient. When there is no reaction it can be repeated in this meeting.
[12:20] <mchehab> things like MAINTAINERS changes
[12:20] <sailus> mchehab: I meant using --cc option to git send-email, to individuals who should be reviewing.
[12:20] <mchehab> and random doc changes are C/C to me, because I ever touched on those patches
[12:21] <sailus> There aren't that many after all.
[12:21] <mchehab> I guess I receive ~40-50 patches per day, due to that
[12:21] <mchehab> (most of them don't require any special action from me)
[12:22] <mchehab> so, just CC doesn't help me to identify what I need to proritize
[12:23] <mchehab> *prioritize
[12:23] <sailus> Ok.
[12:23] <sailus> #v4l then.
[12:24] <hverkuil1> I would like to pick a day and time to discuss https://patchwork.linuxtv.org/patch/42793/ and https://patchwork.linuxtv.org/patch/42794/
[12:25] <mchehab> (yesterday, it was 79 patches c/c to me)
[12:25] <hverkuil1> I.e. introducing a QUERYCAP for v4l-subdevX devices, and how (or if) to get the associated entity/media device information from a v4l-subdevX or video node.
[12:25] <hverkuil1> Discussing this on the mailinglist is a bit too slow, and I really have no strong feeling about how it should be implemented, just that we do need something like that.
[12:25] <sailus> hverkuil1: We don't have that for video devices either.
[12:26] <sailus> So will it be useful for sub-devices?
[12:26] <hverkuil1> Ideally I'd like that for both.
[12:26] <pinchartl> and I'd like that for none :-)
[12:27] <sailus> I think the two matters are separate (QUERYCAP for subdevs and how to get the media entity / device info).
[12:27] <hverkuil1> So would tomorrow or Monday work?
[12:27] <hverkuil1> (yes, separate matters)
[12:27] <sailus> And to be addressed separately.
[12:27] <sailus> Right?
[12:28] <sailus> I'd prefer Monday.
[12:28] <pinchartl> I'm not available tomorrow
[12:28] <mchehab> Monday may work for me, but will largely depend on what will happen today or tomorrow
[12:29] <sailus> How about Tuesday then?
[12:29] <mchehab> I guess it works for me
[12:29] <mchehab> hmm... maybe not
[12:30] <mchehab> I'll have another travel next week
[12:31] <sailus> Is Monday then next week the best foreseeable option, unless we postpone by a week?
[12:31] <sailus> mchehab: ?
[12:31] <hverkuil1> The week after? I don't care when, but some time in the next two weeks would be good.
[12:31] <mchehab> let's try Monday
[12:31] <mchehab> I'll let you know if something bad happens on my side
[12:31] <hverkuil1> Time? 2pm (UTC+2)?
[12:32] <sailus> hverkuil1: I have a meeting at that time.
[12:32] <sailus> One hour earlier?
[12:32] <hverkuil1> fine by me.
[12:32] <sailus> I have another meeting but I was planning to skip that one anyway. :-D
[12:32] <mchehab> btw, I won't likely be available for next meeting (well, we may postpone the next meeting to Friday)
[12:33] <mchehab> :-)
[12:33] <hverkuil1> sailus: Now you have a good excuse.
[12:33] <hverkuil1> mchehab: Friday would be OK for me.
[12:33] <sailus> Works for me, too.
[12:33] <hverkuil1> mchehab: does Monday 1pm (UTC+1) work for you? (at least for now)
[12:34] <mchehab> ok, so next #media-maint meeting will be on Friday, 18, same time as today
[12:34] <mchehab> works for me
[12:35] <hverkuil1> OK, noted in my calendar.
[12:35] <mchehab> (in principle... I'll let you know if I have any issues)
[12:35] <hverkuil1> of course.
[12:35] <mchehab> any other subjects for discussing today?
[12:36] <hverkuil1> The underlying reason is that the lack of a unique always present ioctl in the v4l-subdevX API makes it hard to reliably identify other than by the device name (and udev rules can rename that). Adding a querycap ioctl would solve that, and in general it is something I find useful regardless.
[12:37] <sailus> hverkuil1: You get more information from the media device.
[12:37] <mchehab> yes, I remember some discussions we had in the past on a media summit
[12:37] <sailus> If you're just interested in association with the media device, that is.
[12:37] <sailus> If we add that, it'd be best to do the same for video devices.
[12:38] <mchehab> let's postpone such discussions for Monday ;-)
[12:38] <sailus> Sub-device nodes only exist with the media device, don't they?
[12:38] <sailus> :-)
[12:38] <hverkuil1> Let's discuss this further on Monday (hopefully). As I said, I have no strong feelings on what solution to use, as long as there is one.
[12:39] <mchehab> ok, if there's no other subject, let's finish this meeting
[12:39] <hverkuil1> Actually subdevs can exist without the media device, but there are very few drivers that do that (pinchartl had a list) and I agree with him that we probably should block that use.
[12:39] <hverkuil1> OK, until Monday. Thanks!
[12:40] *** ChanServ sets mode: +o mchehab
[12:40] *** mchehab changes topic to: NEXT MEETING: Friday, 18 12:00 (UTC) - Use this channel only for media maintainership discussions. For everything else: #linuxtv (DVB only) or #v4l. Channel logs: https://linuxtv.org/irc/irclogger_log/media-maint
[12:41] *** ChanServ sets mode: -o mchehab