meeting in 5...
mchehab: sailus: pinchartl: syoung: snawrocki: ping
Hyvää iltapäivää!
EHLO
mchehab: pinchartl: syoung: snawrocki: pingalingaping!\
It seems to take more and more effort to get people to join in on time. That's not good.
hello
All it takes is to set a reminder in whatever calendar you are using.
Hi there
FYI: from December 4th until March 4th Helen Koike and myself will be mentoring Outreachy intern Dafna Hirschfeld. She will work on adding stateless codec support to vicodec, and adding the required tests to v4l2-compliance.
She'll start out by finishing the stateful codec support in vicodec/v4l2-compliance.
So be nice to her :-)
On another note: we just found that a vb2 patch was backported to 4.4 and 4.9 where it introduced a regression (it should never have been backported to kernels < 4.14).
pong
The stable maintainers are more aggressive when it comes to picking up patches to backport. We need to double check more closely what they are doing, and if we fix something introduced in an earlier patch we need to remember to add a Fixes: tag.
That tag should hopefully prevent the stable maintainers from trying to backport it to kernels that do not contain that original patch that was fixed.
I'm still jetlegged
good to know about Dafna
hverkuil: Ack on both.
It's really scary how patches are being applied to stable kernels somewhat mindlessly without any testing, I guess we will need a tag soon like "Do not backport to stable"
I also recently sent some patches to Greg a bit too early, before they had reached Linus's tree.
snawrocki: I haven't seen scary stuff going in myself, but OTOH I have seen a lot of stuff that makes no difference whatsoever.
yeah, we should take care of waiting for patches to be merged upstream before sending stuff to stable
It indeed looks like quite opportunistic.
mchehab: Speaking of upstream, when do you expect to be handling pull requests next time?
hverkuil: agree about the "Fixes" tag
I plan to pay more attention when I am CC-ed about patches being backported to older kernels. If we see more attempts to backport dubious patches due to aggressive backporting, then we need to talk with the stable team about it.
snawrocki: perhaps, if we have this case, we could do:
something at the c/c staging like: # don't backport this one
no need to use an special tag
IMHO
from my side, I intend to apply pending PR today or tomorrow
sailus: what do you mean?
mchehab: be aware that there are several pull request for v4.20. Nothing big, but definitely things we want in.
mchehab: yes, if we indicate a point where a patch can be backported up to there should be less issues I'd say
mchehab: https://patchwork.linuxtv.org/patch/53047/
(If it won't be today, I'll cancel that and send a new one with more patches.)
(10:20:29) mchehab: from my side, I intend to apply pending PR today or tomorrow
anyway, if you want to cancel and apply more stuff, feel free to do so
Oh, I completely missed that line. :-) Thanks for the confirmation.
I'll do that.
I'll probably try to get a snap after the meeting...
I'm completely screwed this time
I posted an RFCv4 series for the MC properties API. I would like feedback about it. If this is what people are looking for, then I'll add documentation etc. and post a non-RFC series.
(I went to bed 4am)
so, my plan is to apply patches by afternoon
There are a LOT of PRs :-)
btw, I'll likely skip PRs with new drivers (if any), applying first the more trivial ones
by "skip" I'm actually meaning that I'll put them after the other ones
hopefully, we'll have all of them merged up to Friday
I think there is only one PR for a new driver (SECO CEC)
ok. CEC drivers are usually not complex
everything else is all fixes/improvements
mchehab: Resent.
ok
syoung: could you please check if are there any DVB patches that would need to be merged?
I think that's about it from my side. Once my outstanding PRs are merged I'll probably post some more fixing syzkaller issues.
I probably won't be able to go through individual patches untill too late during the merge window
feel free to ping mkrufky or brad if you want a second opinion
hverkuil: just noticed a gspca regression fix...
someone reported recently an issue related to a gspca driver
that appeared unrelated to this.
that could be a regression
yeah, unrelated
it seems that two resolutions are not working
on one specific driver
Logitech QuickCam USB detected by Linux, but not user space applications
yep, this one :-)
actually that's the same webcam (I think) that I have been testing the regression fix with.
actually, I guess this is one of the cameras that have multiple versions with the same brand name
all I know is that it is also based on spca561
need to check if it has the same idVendor=046d, idProduct=092e
Mine was 046d:092c
does your camera work on 160x120 and 176x144 resolutions?
yes
It has V4L2_PIX_FMT_SPCA561 and a Bayer format. The latter didn't work (that was the regression).
ah
V4L2_PIX_FMT_SPCA561 had higher resolutions since its compressed.
perhaps that was the problem reported by the user. It doesn't hurt to ask him to test it again with your fixup patch applied
I'll mail him.
I'm almost sure that libv4l will expose both bayer ant spca561 resolutions as RGB to apps
so, they'll just won't care if it is spca561 or bayer
and will show all possible res
Right, that explains it.
that's said, I'm wander why someone would still be using a camera that it is so old :-)
s/wander/wonder/
yeah, weird.
the quality of those cameras are far from good :-)
anyway, anything else?
mchehab: yes, there a few DVB patches I wanted to look at
not from me
I have a question about https://patchwork.linuxtv.org/patch/52835/
this patch is for building v4l-utils in ancient userspace
I am not sure if we should care. There was a discussion on this on the mailinglist, let me dig it out..
define 'ancient'?
debian 7
hmm... we're already copying bpf.h
https://www.spinics.net/lists/linux-media/msg142769.html
what kernel does it use?
does bpf_common.h exist on newer Kernels?
kernel 3.2 I think.
bpf_common.h seems to contain BPF bytecode
I don't see any problems having it c/c to v4l-utils, provided that we's also needing to c/c bpf.h
bpf_common.h has existed for a long time. This is for the original bpf
In general I am OK with it: if v4l-utils is using public linux kernel headers that change over time, then it is a good idea to copy them, I don't think there is anything wrong with it.
It should be possible to compile v4l-utils independent of whatever kernel you are running.
ok
We still use it on a product with a 2.6.39 kernel :-(
right. Wow.
ok, in that case, I will merge it.
yep
thanks
the thing is that, on embedded devices, older Kernels are frequently used
it is unfortunate, but that happens
(and there are LTS distros like Debian)
Yep. Believe me, it's not by our choice that we're on that old kernel for that one product.
ok one last thing. The v4l-utils package on Fedora is missing BPF dependencies. Who do I ask to get that fixed?
(something a bit more contemporary!)
I probably can handle this one
or you could ping hdedoede
I guess he is the official maintainer
I have access to it too
you mean hdegoede?
Hans de Goede?
yes, sorry for the typo
anyway, did we update the v4l-utils version? I guess not
it was updated a few days ago
ah, ok
ok. I'll write a patch and get in touch, thanks
I'm also waiting for a patch from the openbsd maintainer due to bad sysmacros.h handling.
it probably makes sense to package v4l-utils-1.16.1 on Fedora
v4l-utils-1.16.2
https://src.fedoraproject.org/rpms/v4l-utils/blob/master/f/v4l-utils.spec needs elfutils-libelf-devel clang
as BuildRequires
just that?
yes, assuming the build works then :)
I'm doing a mockbuild here
if this is the only missing stuff, I can merge it
mchehab: thank you
syoung: it built
    BPF IR Decoders:           : yes
 
syoung: I'm running the builds for f29 and rawhide
Building v4l-utils-1.16.2-2.fc30 for rawhide
Created task: 31055443
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=31055443
Building v4l-utils-1.16.2-2.fc29 for f29-candidate
Created task: 31055454
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=31055454
Once done, please test. If Ok, I'll ask to add them to Fedora's testing repo
syoung: build failed on non-x86 archs
Not sure if this is an specific issue with Fedora or not. If this is Fedora-only issue, i'll fix by making the dependencies only for x86
but if this is because bpf/clang only works on x86, the v4l-utils build system needs to be fixed
I added a logic at the source file to only add the BPF dependencies for x86
new Fedora 29 task: https://koji.fedoraproject.org/koji/taskinfo?taskID=31056407
mchehab: I've tested the x86_64 build, and that looks good. However the ppc and other architectures failed to buil
build
https://koji.fedoraproject.org/koji/taskinfo?taskID=31056407
here it says it passed
syoung: ^
The other build also completed fine:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1166315
Added it on Bodhi: https://bodhi.fedoraproject.org/updates/v4l-utils-1.16.2-2.fc29
feel free to login at fedoraproject and add your testing comments
ah you added a commit for only enabling bpf on x86
yes
syoung: we can later add bpf support for other archs on Fedora...
assuming that we can make the build to work somehow
yet, I think that we likely need to fix something at v4l-utils build
but didn't really investigate why BPF build failed on all other archs
is it a Fedora packaging issue? is it a broken clang builder? is it due to some troubles at v4l-utils autoconf stuff?
mchehab: I've written a fix. https://github.com/rpm-software-management/rpm/pull/604
the rpm build scripts try to extract a build id from any elf file, but relocatable files do not have a build id
I guess they were not expecting relocatable files in the package
We could work around it in v4l-utils but might as well wait for this pull request
Hmm.. I see
yeah, making rpm builder smarter to handle with it seems the right way to fix it
yeah, let's wait for rpm maintainers to handle this issue
after this patch arrives Fedora upstream, we can revisit
I'm not sure why x86 worked, it gets the same error but does not fail
yes, sounds good
yeah, that's something that looks weird to me too
why it was not an issue on x86?
I'm not sure. Worth investigating, I'll have a look