sailus: ping
hverkuil1: Pong.
Ah, I wasn't sure if you were on ine.
mchehab: ping
meeting? Hello?
EHLO
hverkuil1: if you stopped replying to v4l2-ctrls messages in #v4l it might help :-)
hi all
sorry, got distracted wit controls :-)
Controls, it goes both ways...
Any patches we should review?
Two from me: https://patchwork.linuxtv.org/patch/42953/ and https://patchwork.linuxtv.org/patch/42954/
the first one is OK
I didn't like the second one...
I have a few patches for the V4L2 LED flash class:
Yeah, I'll get back to you on the second one.
http://www.spinics.net/lists/linux-media/msg119733.html
I'll propose an alternative to it
I'll update my async sub-notifier RFC set based on review comments. It's here:
http://www.spinics.net/lists/linux-media/msg118764.html
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.
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.
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?
There's no new one yet, largely due to my holidays.
That's fine.
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.
sailus: when you send the new async series, ping me. I'll add it to my review TODO list too
mchehab: Ack.
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)
oops
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.
ignore that :)
I didn't check the backlogs from last weeks' meeting... anything for me to review?
it has been a little bit crazy here, as I'm about to move to a new place... lots of things to organize
btw, I guess we can also use the submaintainers ML for core changes that need everybody to review
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).
mchehab: Or just cc people? Then everyone knows who's been explicitly informed.
for uAPI, I like the idea to always c/c the API ML, but that doesn't apply to kAPI changes
mchehab: nothing to review from the past two weeks: you weren't the only one on vacation/gone.
I don't really have an opinion but I find myself using cc too seldom.
:-)
sailus: the problem with CC is that checkpatch.pl adds a lot of noise to the CC ML
I receive a lot of "dirty" things there...
I think mentioning it in the #v4l room is usually sufficient. When there is no reaction it can be repeated in this meeting.
things like MAINTAINERS changes
mchehab: I meant using --cc option to git send-email, to individuals who should be reviewing.
and random doc changes are C/C to me, because I ever touched on those patches
There aren't that many after all.
I guess I receive ~40-50 patches per day, due to that
(most of them don't require any special action from me)
so, just CC doesn't help me to identify what I need to proritize
*prioritize
Ok.
#v4l then.
I would like to pick a day and time to discuss https://patchwork.linuxtv.org/patch/42793/ and https://patchwork.linuxtv.org/patch/42794/
(yesterday, it was 79 patches c/c to me)
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.
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.
hverkuil1: We don't have that for video devices either.
So will it be useful for sub-devices?
Ideally I'd like that for both.
and I'd like that for none :-)
I think the two matters are separate (QUERYCAP for subdevs and how to get the media entity / device info).
So would tomorrow or Monday work?
(yes, separate matters)
And to be addressed separately.
Right?
I'd prefer Monday.
I'm not available tomorrow
Monday may work for me, but will largely depend on what will happen today or tomorrow
How about Tuesday then?
I guess it works for me
hmm... maybe not
I'll have another travel next week
Is Monday then next week the best foreseeable option, unless we postpone by a week?
mchehab: ?
The week after? I don't care when, but some time in the next two weeks would be good.
let's try Monday
I'll let you know if something bad happens on my side
Time? 2pm (UTC+2)?
hverkuil1: I have a meeting at that time.
One hour earlier?
fine by me.
I have another meeting but I was planning to skip that one anyway. :-D
btw, I won't likely be available for next meeting (well, we may postpone the next meeting to Friday)
:-)
sailus: Now you have a good excuse.
mchehab: Friday would be OK for me.
Works for me, too.
mchehab: does Monday 1pm (UTC+1) work for you? (at least for now)
ok, so next #media-maint meeting will be on Friday, 18, same time as today
works for me
OK, noted in my calendar.
(in principle... I'll let you know if I have any issues)
of course.
any other subjects for discussing today?
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.
hverkuil1: You get more information from the media device.
yes, I remember some discussions we had in the past on a media summit
If you're just interested in association with the media device, that is.
If we add that, it'd be best to do the same for video devices.
let's postpone such discussions for Monday ;-)
Sub-device nodes only exist with the media device, don't they?
:-)
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.
ok, if there's no other subject, let's finish this meeting
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.
OK, until Monday. Thanks!