pinchartl: before I forget during our meeting: can you try to review this patch series this week/early next week? https://www.mail-archive.com/linux-media@vger.kernel.org/msg134920.html
im having some issues moving the pgp keys from the macbookpro i brought to the conf last year over to my kernel-dev box
anybody have any pointers?  O:-)
there are a bunch of DVB patches from the past few weeks that I have queued here
pinchartl: another subject unrelated to the meeting: it seems that the uvcdriver is now exporting two devnodes... the second one fails to stream (and v4l2-compliance goes to an endless loop if -s flag is used)
https://pastebin.com/aUSUt1ka
(I suspect that the caps flag there are wrong, as it says it supports both video and metadata capture
hverkuil: I will
I suspect it supports only the latter
mchehab: the second node is for metadata only
or maybe v4l2-compliance has something wrong
mchehab: you should look at the device caps: that only sets the metadata capture. Not sure why v4l2-compliance fails on it.
it doesn't actually fail... it keeps running endlessly
running endlessly, or is it just waiting for metadata to arrive?
Can you stream just metadata, or do you also have to stream video at the same time?
you have to stream video at the same time
So v4l2-compliance is likely in a blocking wait.
mchehab: does running v4l2-ctl --stream-mmap at the same time make v4l2-compliance -s work?
no
Hello!
hi all
hi!
hi!
mchehab: still waiting for the cedrus driver to be merged to the request_api branch, any ETA for that?
I'll likely be merging stuff on Monday
OK
maybe tomorrow, if I finish some work today
mchehab: Could you check the fwnode patches then, too?
Pull request, I mean.
yeah, sure. I saw the pull request... got a little afraid by the "BIG" on it :-p
I usually place big pull requests at the end of my pull requests queue
:-D
I wanted to have applied it already, but got sidetracked by other things
Ok.
It's not _that_ complicated.
:-)
In terms of new functionality, there isn't all that much.
It's mostly cleaning up and fixing things.
yeah, but it is something that usually requires a more deep analysis, as this is core stuff
I usually want to do such reviews early in the morning
What makes it big is that there are very many patches in order to make meaningful changes while keeping things functional.
I see
but the thing is, when I start handling a PR, I want to not be interrupted by other things
Ack.
specially when they're related
*especially
:-)
(i know mauro loves it when i correct the English)
that remings that I need to replace this keyboard again... keys are getting stuck
*reminds
mchehab: How old is your keyboard?
1,5 years, I guess
maybe 2 years
I bought mine in 1994 and I'm begining to think I might need to replace it after the next ten years.
I have a newer one at the office, though.
those logitech wireless keyboards are more fragile
Working from home today... the keyboard at the office is from 1995, but I bought it at a flea market. X-)
after a while, keys start to glue when pressed
:-o
That sounds like a quality problem.
I'd bring it back to the place that sold it!
that sounds like a vendor that wants to make easy money :-D
I only buy US keyboards
I rate Brazilian layout
Now that BPF keymaps are implemented in ir-keytable, I was hoping for a new v4l-utils release. Thoughts?
I don't have any big changes on v4l-utils on my side
I can email Gregor Jasny unless there are objections
from my side, no objections
does Brazil has a different keyboard layout than portugal?
There is some good new stuff for v4l-utils, so a new release would be good.
syoung: yes, it is completely different
Portuguese keyboards seem to be even weirder :-)
mchehab: it would be nice if https://patchwork.linuxtv.org/patch/52092/ is merged soon, then I can sync up v4l-utils and replace AdobeRGB by opRGB in v4l-utils.
It would be good to have that done before a new release is made.
yeah, when pulling stuff, I'll start with it
I have a small and a big topic for this meeting, let me know when I can start
yeah, getting rid of the legacy term is something that we should do earlier than later
pinchartl: from my side, go ahead
small topic first
mchehab: could you reply to https://www.spinics.net/lists/linux-media/msg140133.html ?
(doesn't have to be now)
big topic then
sorry, I missed that
will answer after the meeting
mchehab: you mentioned that you may delay pull requests to Linus (well, Greg now) until the maintainers summit
what's your plan ?
hverkuil: ok
I'll keep receiving patches as usual
but my understanding is that, the way the CoC is, we should either ask everybody with a non-SOB email there for an explicit ack on using the emails
(well, maybe we're not yet bound to it, as we didn't picked back from -rc4)
(meeting, back soon)
but anyway, my plan is to keep doing our job as usual, but before sending stuff upstream, I want to be covered from legal standpoint
so what's your specific plan for the v4.20 merge window, given that you haven't pulled -rc4 in your tree ?
the next merge window will likely be together with the Maintainer's Summit
it will very likely overlap with Edinburgh, yes
(yet, I hope that people will have good sense and fix the FUD before that)
(although given that Greg is now in charge, a glitch is possible)
you have merged patches that I would like to see in v4.20. in the event that the maintainer's summit doesn't give you the desired outcome, what will you do ?
anyway, I'm actually asked some help from US office for them to help reviewing the CoC from legal standpoint
Let's see then
sure, I understand you want time before making a decision, but what are the possible outcomes ?
I need to prepare for the case where you wouldn't send a pull request upstream for v4.20
(and I don't think I would be the only one)
I can't foresee. I really want to talk to an US-legislation versioned  lawyer
in order to make my plans
I'll do it before the Maintainer's Summit
let's put it differently. is there a risk that the patches you currently have queued for v4.20 will not make it upstream in the next merge window ?
currently, no
can such a risk materialize between now and the merge window ? :-)
There are always risk... I mean, if I die, I won't be able to send pull requests :-P
but I don't think there's any risk for 4.20
than it was before the CoC
ok
thank you for the answer
IMHO, the big issue is when we accept the terms of this new non-GPL contract
with happens when we pull back from upstream
that's for everybody to decide individually of course
and I won't try to influence you one way or another
yes
but regardless of your decision, I'll still have V4L2 patches that I will want to get merged upstream
Providing that Greg would be inflexible on fixing the CoC, perhaps there are some ways to keep working without accepting those new terms
back (sorry about that)
but anyway, I almost sure that we won't reach this point
most probably not
and we'll find a way to get past of this for the next -rc cycle
v4.20-rc1 will be past-Edinburgh, I expect the situation to be clearer then
(without any assumption on the result, but at least it should be clearer)
mchehab: are you also talking to Greg KH about this?
I'm not on the lkml so I have no idea what is happening there.
hverkuil, I'm discussing it at KS mailing list. I suspect, however, this is the kind of thing that I suspect people will wait for Linus before addressing
wow, i am catching up on the news right now
it sounds like this will be an interesting year at the conferences
anything else?
not from me