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