| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | ChanServ sets mode: +v mchehab | [11:01] |
| mchehab | hi all
hmm... meeting will be in +1hour bbl | [11:02] |
| ............ (idle for 59mn) | ||
| hverkuil | Hi guys! | [12:01] |
| mchehab | hi | [12:01] |
| mkrufky | hi | [12:02] |
| sailus | Hello!! | [12:02] |
| mchehab | I'm travelling tomorrow to spend 2 weeks at the office | [12:02] |
| syoung | Hello | [12:03] |
| mkrufky | mountain view? | [12:03] |
| mchehab | 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 | [12:03] |
| mkrufky | understood | [12:03] |
| mchehab | 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 | [12:04] |
| hverkuil | I posted one pull request for 4.16 earlier this week. That's the only thing I have. | [12:05] |
| mchehab | if the fix there is acceptable, I'd like to submit it to 4.16 | [12:05] |
| hverkuil | 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. | [12:06] |
| syoung | mchehab: My last rc pull request contains urgent fixes for v4.16 | [12:06] |
| mchehab | Subject: [GIT PULL FOR v4.16] RC fixes
Date: Sun, 7 Jan 2018 17:03:24 +0000 ? | [12:06] |
| sailus | 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)? | [12:07] |
| mchehab | hverkuil: ok. anyway, this is something that we can do late during the merge window
sailus: please let me know when you submit it | [12:07] |
| sailus | mchehab: Ack. | [12:08] |
| syoung | mchehab: that's it | [12:08] |
| mchehab | ok, I'll handle yours and hverkuil's pull requests today or tomorrow | [12:09] |
| hverkuil | 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? | [12:09] |
| mchehab | hverkuil: good question
I don't have an answer. I only heard about that yesterday | [12:09] |
| hverkuil | anyway, I like that it gets rid of KERNEL_DS since I never understood what it did :-) | [12:10] |
| mchehab | yep | [12:11] |
| hverkuil | 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. | [12:12] |
| mchehab | from my side, I'm still working with the kernel 4.9 regression | [12:12] |
| mkrufky | i had some technical issues here, but i have finally rebuilt my dev box! | [12:12] |
| mchehab | I suspect that the issue is actually not at URB handling, but, instead, on write() flush logic | [12:12] |
| mkrufky | 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 | [12:13] |
| hverkuil | 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. | [12:13] |
| mkrufky | 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 | [12:13] |
| mchehab | 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 | [12:14] |
| mkrufky | ok | [12:15] |
| mchehab | btw, I guess we may expect some noise on 4.15 due to kPTI - it may badly affect media, as latencies should increase | [12:16] |
| mkrufky | I guess the usb issue will remain open for this kernel release ? | [12:16] |
| mchehab | yes
it is there since 4.9 so, no urgency there's a RFC series addressing it | [12:16] |
| mkrufky | ok | [12:17] |
| mchehab | 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 | [12:17] |
| mkrufky | i saw your mails about it
very exciting :-) | [12:17] |
| hverkuil | 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 :-( | [12:17] |
| mchehab | heh
hverkuil: I was thinking that maybe the better would be to change the way we generate media_build | [12:18] |
| hverkuil | sailus: pinchartl: any patches I should review? | [12:18] |
| mchehab | 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 | [12:18] |
| hverkuil | 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. | [12:20] |
| mchehab | yes, that won't help you
but will reduce the pressure for updates | [12:20] |
| hverkuil | True | [12:21] |
| mchehab | anything else for today's discussion? | [12:22] |
| hverkuil | not from me. | [12:22] |
| mkrufky | [OT] can you point me to your dvb_mmap kernel & userspace branches again? | [12:22] |
| hverkuil | Oh, yes: who else beside me will attend the ELC this year? | [12:23] |
| mchehab | hverkuil: didn't decide yet | [12:23] |
| sailus | hverkuil: Not on my side at the moment. | [12:23] |
| mchehab | mkrufky: kernel: all patches were merged | [12:23] |
| mkrufky | oh! nice
ok then, that makes things easier mkrufky pulls the latest | [12:23] |
| mchehab | 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 | [12:24] |
| mkrufky | dvb mmap isnt yet merged to linus, is it? | [12:25] |
| mchehab | 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 | [12:25] |
| mkrufky | ok | [12:26] |
| mchehab | 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 | [12:30] |
| mkrufky | yes i understand, and it makes sense | [12:32] |
| mchehab | 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 | [12:32] |
| mkrufky | 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 | [12:33] |
| ........... (idle for 51mn) | ||
| mchehab | 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) | [13:24] |
| ............................................................................................. (idle for 7h40mn) | ||
| *** | ChanServ sets mode: +v mchehab` | [21:06] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |