<!-- 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: Hi all!
mchehab: hi all
syoung: Hello!
<br> <u>mchehab</u>: thanks for your help
mchehab: anytime
<br> I already started handling pull requests...
<br> this is a short week for me, as it started only yesterday afternoon
<br> anyway, my plan is to keep handling pull requests today and tomorrow
<br> <u>mkrufky</u>: there are a number of dvb patches from brad... are you reviewing those?
hverkuil: I've been trying the whole day to get a pull request with random bug fixes together, but I keep getting interrupted by people :-(
mchehab: problems usually come from people :-p
hverkuil: If I can't get it done today, then it will slip to Monday (I'm off tomorrow).
mchehab: ok
mkrufky: i reviewed his first set but i never pushed any to git myself, havent had time for linuxtv since december unfortunately. i have some time set aside this coming sunday to test the latest dvb mmap changes and i'd like to also get through the remaining brad patches but not sure how many are outstanding
hverkuil: <u>sailus</u>: thanks for looking at the request API patches. I had no time at all to look at those myself.
mkrufky: i have not yet reviewed his latest patches , but ill do my best to get through what i can before end of sunday
mchehab: ok
<br> please let me know if you left anything pending
<br> I may take a look myself at the remaining ones
hverkuil: <u>mchehab</u>: please review https://www.spinics.net/lists/linux-media/msg128653.html
<br> I'd like to spin a new version of this on Monday, esp. since there are dependencies (clearing reserved fields) with the s_parm cleanup series.
mchehab: ok, will add it to my todo list
<br> errr it is already there
<br> as I said, this was a short week here...
<br> Carnaval's holidays
hverkuil: I'm done with the v4l2-compat-ioctl32.c mess, so I can finally move on to other things...
mchehab: I usually work those days, but this time, I had several personal appointments
<br> great!
<br> you did a very good job there
<br> with all those backports
<br> sailus, alan & Intel still have stuff on their todo lists with regards to atomisp
<br> I hope they could work this year towards solving the issues there in order to move the driver out of staging
hverkuil: Personally I would like to see some real commitment towards this driver within the next (say) 6 months. Otherwise it should be kicked out IMHO.
<br> BTW, Jasmin is doing a good job helping out with media_build.
mchehab: there are a lot of work to be done there... I doubt that 6 months is enough to finish, but, I agree with you: I'd like to see big changes in the next 6 months or so
<br> great news
<br> we really needed someone with time and interest there
hverkuil: It doesn't have to be ready in 6 months, but I want to see some real progress and not just cleanup patches.
mchehab: anything else for today's discussions?
hverkuil: Not from me.
mchehab: <u>mkrufky</u>: my plan is to apply dvb mmap api patches next week... its build is currently broken. I don't want to keep it this way. I'll likely put it into a topic branch, and pull it on both -fixes and master branches
<br> based against 4.16-rc1
<br> and send it to 4.17-rc3
mkrufky: im a little confused ... i thought everything for dvb-mmap was already merged
mchehab: (of course, if nobody points an issue preventing it)
<br> yes, but I ended merging wrong versions of two patches
mkrufky: ah
<br> the email you sent me has the latest branches that i should try, correct?
mchehab: yes
mkrufky: ok, then thats what counts to me :-)
mchehab: Arnd actually made a patch fixing one of the issues (replacing #if DVB_MMAP to #if CONFIG_DVB_MMAP)
<br> the other one I applied on that tree
<br> it was also related to make DVB_MMAP an optional feature
mkrufky: my plan was to test on a pcie board and some usb sticks, but i didn't plan to look deep at the low level like you did ... what i want to do is add support for mmap to my own userspace application lib and see what problems i find that you havent seen yet
mchehab: OK
mkrufky: hopefully vet out any weird differences before the world finds bugs
<br> making it an optional feature will only be for one or two kernel versions probably, right?
mchehab: yes, that's the plan
mkrufky: does it make sense to have it optional in the long term? or only now while its new?
<br> ok good
mchehab: yet, I'm thinking on adding a caps flag somewhere to indicate if the feature is available
<br> not sure about that yet (as long term, it won't be optional)
mkrufky: once merged and enabled (or made non-optional, either way) it will be a cap of EVERY device, right?
<br> i dont think the cap makes sense in this case because it will become a feature of the new api version
<br> and i believe we had an api bump recently you mentioned ?
mchehab: yes
<br> api bumped to 5.11
mkrufky: so this period right now, userspace devs try mmap and if it fails, then fall back to read() .... but next api version, devs may safely remove read() support
<br> *in my opinion, assuming all goes well)
mchehab: (actually due to a DVB-S2X change that is also coming for 4.16)
<br> <u>mkrufky</u>: actually, it will fail at open()
mkrufky: ^ userspace devs may safely remove read() support, i meant
<br> great, fail at open()
mchehab: for mmap to work, DVR should be opened in R/W mode
mkrufky: so, i dont think the cap is really needed then, right?
mchehab: (or demux, if streaming on demux)
<br> no, not really
<br> it will also return a different error code
<br> EOPNOTSUPP (or something like that)
mkrufky: if a userspace tries to mmap on a old driver, you mean?
mchehab: no, if it opens in R/W mode with an old Kernel
mkrufky: ^ this is exactly what i meant
mchehab: and the device is not a CA module with both read/write ops
mkrufky: ah, i didnt think of ca
mchehab: (there is a caps bidirectional for this case)
<br> I guess only one driver, in staging, currently does that, but didn't really check
mkrufky: heh, im going to build this kernel now - you said the right things to make me need to try it today
<br> LOL
mchehab: (it is in staging just because we never discussed this "weird" API)
<br> :-)
mkrufky: this is a ca driver? which driver is that?
mchehab: cxd2099
mkrufky: ok
mchehab: instead of a "normal" CA, connected to the frontend...
<br> this CA receives encrypted data via write() syscalls...
<br> and returns decripted ones via read()
<br> (as far as I remember)
<br> as this is not an "official" usage of CA API, it ended by going to staging
<br> I have a board with it, but no CAM - and my board stopped working a few years ago
<br> I need to setup some environment here to test CA
<br> but it is not easy to do that in Brazil - as CAM are not sold here
mkrufky: ca is something i never really played with. we dont have it in the states .
mchehab: we have here, but cable/sat operators only sell dedicated hardware
<br> no CAM
mkrufky: ah we dont have those either in the states
mchehab: and they bind the services to the MAC address of the dedicated hardware
mkrufky: the link in your email is `https://git.linuxtv.org/mchehab/experimental.git/log/?h=dvb-mmap-v2` but i see you have a dvb-mmap-v3 branch
<br> i should stick with v2 or v3?
mchehab: so, I would likely need to buy a big dish, point to an EU satellite, and buy a CA while in Europe
<br> v3 has minor changes
<br> mostly documentation stuff
<br> it is newer than v2
<br> but API should be the same
mkrufky: so i will use v3, since i am going to build now
mchehab: if you didn't try yet, try v3 :-D
mkrufky: exactly :-)
<br> oh! i have Kconfig cleanups for you
<br> i did this last time but didnt commit ... ill send with any related fixes after my tests
<br> ok, first mkrufky commit of 2018 coming up
mchehab: :-)
mkrufky: https://git.linuxtv.org/mkrufky/dvb.git/commit/?h=dvb-mmap-v3
mchehab: :-)
mkrufky: i'll wait for more and send a pr on sunday like i said earlier
mchehab: OK
pinchartl: <u>mchehab</u>: don't hold your breath. Intel has no plan to move atomisp out of staging, and Sakari in particular has no plan to do so
<br> (replying to your earlier comment)
hverkuil: <u>mchehab</u>: why did this patch not turn up in patchwork: https://www.spinics.net/lists/linux-media/msg128042.html
<br> it looks ok to me, so that's weird.
mchehab: <u>hverkuil</u>: perhaps it got mangled?
<br> <u>hverkuil</u>: yeah, it looks that the emailer from the sender broke long lines
<br> diff -uprN linux.orig/drivers/media/radio/si470x/radio-si470x-common.c
<br> linux/drivers/media/radio/si470x/radio-si470x-common.c ---
<br> linux.orig/drivers/media/radio/si470x/radio-si470x-common.c
<br> 2018-01-15 21:58:10.675620432 -0500 +++
<br> linux/drivers/media/radio/si470x/radio-si470x-common.c
hverkuil: Ah, I missed that. Thanks!
mchehab: <u>pinchartl</u>: if neither Intel, sailus, acox or anyone else is intestested at atomisp driver, then it should go to /dev/null
<br> anyway, before taking any decision, we need to ask people, publicly
<br> if no answer, make it depend on BROKEN
<br> and remove after a couple Kernel versions
pinchartl: <u>mchehab</u>: I think that's what will happen, but there no hurry. let's give them some time, warn them it will be removed, and if no work is done, drop it
<br> we can give them a year or so
mchehab: sounds fine to me
***: hverkuil has left