<!-- 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>
hverkuil: <u>sailus</u>: we'll just assign all the action items to you :-)
sailus: Hmm. It looks like that I'll be able to attend after all. :-)
hverkuil: meeting?
sailus: Meeting.
mchehab: hi all
hverkuil: From v4l chat:
<br> (08:48:43) hverkuil: mchehab: sailus: pinchartl: Can you look at this reply to the cover letter of the first properties RFC: https://www.spinics.net/lists/linux-media/msg138637.html
<br> (08:49:03) hverkuil: And to the cover letter of the RFCv2 of the same patch series: https://www.spinics.net/lists/linux-media/msg138637.html
<br> (08:49:33) hverkuil: Specifically of the two proposals at the end of the RFCv2 cover letter.
mchehab: https://www.spinics.net/lists/linux-media/msg138637.html is my reply to RFCv1
hverkuil: Also this (unrelated) RFC: https://www.mail-archive.com/linux-media@vger.kernel.org/msg134053.html
mchehab: I actually missed RFCv2 :-)
<br> will try to review it today, after finishing reviewing requests API... just started looking on it today
hverkuil: <u>mchehab</u>: ah, great! You're reviewing v17, right?
mchehab: yes
<br> still on patch 1 :-)
<br> btw, one of the things I noticed there is something I also commented at the maintainers ML: licensing
<br> we should really fix the FDL licensing ASAP
<br> I'm still waiting for the SOBs from all sub-maintainers
hverkuil: You have my SoB for that.
mchehab: ok, please answer to the e-mail then (if you didn't already)
<br> as I commented to sailus in priv:
<br> (08:40:31) mchehab: I got already the most relevant acks: Gerd (past V4L2 maintainer and author of original V4L2 spec), the Metzler brothers (DVB doc authors) and Johannes (the past DVB maintainer).
<br> (08:40:31) mchehab: That - together with the SOBs from all sub-maintainers - seems enough to me, as we're the "book editors"
<br> (08:41:43) mchehab: by adding our SOBs we're implying that nobody asked for invariant parts to be added - or if someone ever asked - we didn't merge it
hverkuil: One question: part of the documentation is made with my cisco.com address (i.e. with Cisco copyright), part of it is older and done before I worked at Cisco (and Tandberg before it was acquired by Cisco) and has my personal copyright. Should I give two SoBs? One from cisco.com, one from xs4all.nl? Or is that not necessary?
mchehab: we're not changing the license... we're just explicitly saying that we're not allowing to have invariant sections
<br> I don't think it matters
hverkuil: OK.
mchehab: as I said, we're not changing the license
hverkuil: right
mchehab: just saing explicitly that invariant sections are not allowed
<br> as reviewers, my understanding is that we have the right to do that
<br> specially after having the SoBs from the original document authors
<br> my proposal (and this touches the request API and all other new document files we add) is that we should start doing dual-license there
<br> SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sessions
<br> and add a no-invariant-sessions document at LICENSES/exceptions/
<br> after that, I'll likely review all document files I wrote myself (without importing from DocBook), changing them to this dual-licensing model
<br> the ones imported from DocBook will be a lot more painful to change
<br> I might do some day for the texts I wrote there - or maybe not -- too much work
<br> pinchartl, sailus, syoung ^ any concerns with regards to the above discussed?
pinchartl: <u>mchehab</u>: I'm totally fine with the proposed change for the documentation patch
<br> as explained in an e-mail I don't think SoB is the right tag though, but I don't care much
hverkuil: So you want me to use that dual license SPDX identifier for the request documentation?
mchehab: yes... I'll comment it on my reply to patch 01/34
hverkuil: OK, then I'll make that change for v18.
mchehab: (that's said, if I don't find anything weird, I would prefer to have changes on newer patches)
<br> I'll probably opt to merge whatever we have on a topic branch, in order to avoid the pain of looking into a /34 patch series all the time we change a comma there :-)
<br> but I'm still on patch 01... I might change my mind while reviewing it :-D
hverkuil: <u>mchehab</u>: in a nutshell: my plan for 4.20 is to merge the request API + the cedrus staging driver. This does require that this RFC is discussed first: https://www.mail-archive.com/linux-media@vger.kernel.org/msg134053.html. It's easy to implement, but we need to agree on it.
mchehab: yeah, I saw that RFC... wanted to review the /34 patchset before answering to it
hverkuil: you will probably find some things when reviewing, so expect a v18 anyway. But getting that in a topic branch is probably a good idea. The cedrus driver can be added there as well once v4.19-rc1 is released.
mchehab: anyway, freezing the /34 patchset is probably the best thing to do... it is very painful to review a /34 patchset that changes on every review
<br> yeah, we wil only ask for pulling from it after having everything OK there
sailus: <u>mchehab</u>: I'm fine with the new approach in document licensing.
mchehab: <u>pinchartl</u>: AFAIKT, only SoB has a precise legal definition
<br> acked/reviewed don't have such things...
hverkuil: <u>mchehab</u>: just check with me before you make a topic branch. My git repo is slightly different from the posted patch series (fixed a kbuild test robot issue in docbook comments)
sailus: <u>hverkuil</u>: I'd like to talk about interaction between uAPI S_CTRL and requests.
mchehab: there, we're talking as the ones responsible to get stuff into the Kernel - or to deny
sailus: Would tomorrow work for that?
mchehab: a SoB makes it stronger
hverkuil: tomorrow or today, either works for me
sailus: I'm more or less out of time today, so tomorrow.
hverkuil: ok
mchehab: with regards to patches, I finished already the warning fixes merging.... except for the VSP1 fix
<br> I really want it to be fixed on 4.19... that warning is bothering me since Kernel 4.18 (at least)
<br> so, if nobody comes up with a better way to shut up smatch on that, I'll likely apply that single-line patch
<br> there are still several warnings that smatch complains when a database is built
hverkuil: I also have a heads-up about an upcoming new utility for v4l-utils: https://git.linuxtv.org/hverkuil/v4l-utils.git/log/?h=qvidcap
<br> It's been in my tree for ages, but I never got the time to dig into the remaining Qt and openGL/openGL ES issues. A colleague of mine did a lot of work on it and it is now almost ready for a first release.
<br> It's a viewer that can use video devices, read from a raw file or from a socket over the network, or use the test pattern generator. Ideal for testing, especially if you do not get the video format you were expecting.
<br> We've used it for that at Cisco, but it was too buggy for a long time.
<br> It also has nice shader code that I plan to use in qv4l2 as well: it handles many pixelformats and understands colorspaces etc.
sailus: I need to leave. Happy IRC meeting continuum!
hverkuil: I think we're done anyway?
mchehab: nice
<br> btw, I fixed Camorama those days... it were still using V4L version 1 API!
<br> patches are already upstream
<br> https://github.com/alessio/camorama
hverkuil: good.
mchehab: I added a logic there to use ENUM_FRAMESIZES and show all camera supported resolution (if the camera has a discrete range)
<br> the V4L2 control code there is still too simple (it presents a set of up to 4 controls only), but it should do its job
<br> by control I'm meaning G_EXT_CTRL & friends
<br> After all those years, I got the sensation that we had finally got rid of V4L1
<br> its gost is still rounding us
<br> I'm wandering how many apps would stop work if we get rid of libv4l1
<br> s/wandering/wondering/
<br> anything else for the today's discussions?
hverkuil: not from me
pinchartl: sorry, had to reboot
<br> no, nothing from me either
<br> I'll review the pending patches
<br> and then go back to my patchwork backlog
<br> (I managed to cut it in half roughly)
mchehab: good!
mkrufky: hey, my apologies,
<br> i dont think i will be around next week either, but i will be back regularly again after that
mchehab: <u>mkrufky</u>: please look and send your SOB for that patch from Ben Hutchings <ben@decadent.org.uk>
<br> <u>Subject</u>: [PATCH] Documentation/media: uapi: Explicitly say there are no Invariant Sections
mkrufky: ok, will take a look
<br> oh, wow
<br> i cant just sign this today quickly, it needs for me to really double check
<br> there were lots of things that Johannes et al always needed to make sure never broke
<br> maitaining compatibility with a userspace abi from over a decade ago thats burned into many devices in agreements with convergence, the company that actually produces the linux-dvb subsystem
<br> so
<br> im just saying, i need to be sure that it's ok before I send a s-o-b .... and I am leaving for a vacation today. so i wont be able to sign that for at least a week and a half :-/
<br> i will do my investigation when i return. i have a few days before i have to return for work
<br> in the meanwhile , mchehab, if you already have s-o-b from convergence team members, such as Johannes, it would help
<br> for this, it may be worth reaching out to them
<br> s/may be/certainly is/1
mchehab: <u>mkrufky</u>: I have their sobs
<br> JS, Ralph, Markus
mkrufky: i dont see that on the ml
mchehab: they sent me in priv
<br> I'll reply to the public thread with their SOBs, c/c them
syoung: hverkuil, mchehab: I could do a small status update on remote controllers. Probably it will be 5 minutes, and cover what's been accomplished and future work
mchehab: <u>mkrufky</u>: email sent, with all collected SoBs
syoung: if there is interest, of course
mchehab: I received two acked-by (from pinchartl and sailus), but, IMO, it should be SoB
<br> <u>syoung</u>: feel free to do it
<br> hmm... is vger dead?
<br> just sent two emails there... didn't arrive
<br> <u>mkrufky</u>: I'm forwarding the last e-mail I sent to the public ML with the SoBs I received so far
<br> hopefully, they'll appear at the ML in a while
<br> if not, I'll forward them later
<br> they arrived bugs.debian.org: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698668
<br> probably just a transitory condition at VGER
<br> emails arrived there
<br> <u>mkrufky</u>: email with their sobs are already at the ML
***: hverkuil has quit IRC (Quit: ZNC 1.7.0+deb1+b1 - https://znc.in)
mkrufky: s-o-b sent
***: ChanServ sets mode: +v hverkuil
mchehab: <u>mkrufky</u>: thank you!
mkrufky: you're welcome. now this is one less task for me when i return :-)
mchehab: lost my comments to patch 01/34... grr.... claws-mail really sucks when changing the source ID... it removes everything behind signature
<br> and sometimes it thinks that the entire e-mail is a signature
<br> comments to request api patch 01/34 sent
<br> moving forward...
<br> btw, I may be repeating myself... I don't remember anymore what I commented in the past