hi all
hmm... meeting will be in +1hour
bbl
Hi guys!
hi
hi
Hello!!
I'm travelling tomorrow to spend 2 weeks at the office
Hello
mountain view?
not sure yet if I'll be able to join for the meetings but I'll likely find a way
no, in BR
SRBR office
understood
today, I rearranged the information at https://linuxtv.org/docs.php
there were several obsolete things there
please check if everything is ok
I should be handling next week any pending pull requests
are there anything urgent for 4.16?
hverkuil: please check that e-mail from Takashi
I posted one pull request for 4.16 earlier this week. That's the only thing I have.
if the fix there is acceptable, I'd like to submit it to 4.16
mchehab: I saw that email, it's on my to do list, but it will likely be next week before I get around to it.
mchehab: My last rc pull request contains urgent fixes for v4.16
Subject: [GIT PULL FOR v4.16] RC fixes
Date: Sun, 7 Jan 2018 17:03:24 +0000
?
mchehab: Nothing yet on my side. Perhaps a bug fix for CIO2. It's not on the list yet, so perhaps fixes would be the target (assuming it won't make it to master)?
hverkuil: ok. anyway, this is something that we can do late during the merge window
sailus: please let me know when you submit it
mchehab: Ack.
mchehab: that's it
ok, I'll handle yours and hverkuil's pull requests today or tomorrow
mchehab: I just need more time to review it. Also, the patch is old and likely no longer applies. And why was it never posted to the mailinglist?
hverkuil: good question
I don't have an answer. I only heard about that yesterday
anyway, I like that it gets rid of KERNEL_DS since I never understood what it did :-)
yep
Please all note the '[RFC PATCH] v4l2-event/dev: wakeup pending events when unregistering' patch I just posted and Michael Walz's email that reports the issue.
from my side, I'm still working with the kernel 4.9 regression
i had some technical issues here, but i have finally rebuilt my dev box!
I suspect that the issue is actually not at URB handling, but, instead, on write() flush logic
i havent had a box with a replaceable kernel in some time ....   pull request i said i would send last weekend will likely come out this weekend instead
I just tested that scenario with CEC and it's really broken there. And since I copied that from V4L2 I'm pretty sure it's broken in the same way for v4l2 and possibly rc/DVB.
if i miss the chance for 4.16, then its my fault, but i think the patches i have planned to send are simple enough
mkrufky: if Linus decide to have a -rc9, I'll consider for inclusion
no idea how retpoline tests are going
he may eventually delay another week depending on that
ok
btw, I guess we may expect some noise on 4.15 due to kPTI - it may badly affect media, as latencies should increase
I guess the usb issue will remain open for this kernel release ?
yes
it is there since 4.9
so, no urgency
there's a RFC series addressing it
ok
RFCv2 was not ok
we'e waiting for a v3
the mmap support for DVB comes handy
as it reduces a lot the context switches
i saw your mails about it
very exciting :-)
Note that the media_build is still broken. Sorry about that, lack of time. Every time I want to work on it I get something higher prio on my desk :-(
heh
hverkuil: I was thinking that maybe the better would be to change the way we generate media_build
sailus: pinchartl: any patches I should review?
I mean: maybe we can store somewhere at linuxtv.org the latest version that builds for each Kernel
for instance, if yesterday's media build works fine for Kernel 3.18, it will be stored somewhere there...
if the today's build fails, the yesterday's one is there
That will help the end-users of media_build, but not me. Someone still has to keep it up to date... I'd love to offload this to someone.
yes, that won't help you
but will reduce the pressure for updates
True
anything else for today's discussion?
not from me.
[OT] can you point me to your dvb_mmap kernel & userspace branches again?
Oh, yes: who else beside me will attend the ELC this year?
hverkuil: didn't decide yet
hverkuil: Not on my side at the moment.
mkrufky: kernel: all patches were merged
oh!  nice
ok then, that makes things easier
userspace: https://git.linuxtv.org/mchehab/experimental-v4l-utils.git/log/?h=dvb-mmap
it requires some work
btw, I added continuity checks at dvbv5-zap tool, while on monitor mode (upstream)
didn't merge those changes yet on my experimental branch
it now shows continuity errors per PID and total count
dvb mmap isnt yet merged to linus, is it?
I recommend using -X 100 parameter when using monitor mode for DVB-S/S2/C, as otherwise the number of PIDs it displays is too high to fit
no, it will go to 4.16
ok
I think we should add a sequence number there
as far as I checked, it doesn't use the ringbuffer on mmap mode. Data is written directly into the mmap buffers
so, an easy way to detect discontinuities due to slow CPU machines is by adding a sequence number, just like on V4L2
yes i understand, and it makes sense
IMHO, the better is to keep both types of detection: one in kernel space (buffers discarded - detected via sequence number) and another one on userspace (due to CRC errors or other similar stuff that would cause a single PID to have discontinuities)
need to go
bbl
just, any documentation about this discontinuity value should stress thats its is a discontinuity generated due to slow machines, as other discontinuities are easily detected via TS discontinuity counter in each packet header
mkrufky: yeah, sure
well, those are also detected via TS discontinuity - at least on some PIDs
s/some PIDs/most packets/
there are some packets that don't have discontinuity checks
(the ones with discontinuity flagged)
and NULL packets and packets without payload (but those are irrelevant, anyway)