*udev
pinchartl, hverkuil: I'll be pushing today the patches for media-ctl to work with DVB
at v4l-utils
in order to sync with the current Kernel
interesting coincidence, I wanted to discuss DVB+MC with Hans and you on IRC :-)
I have 30 minutes now
or more time in an hour
I have some time now.
i also have some time now
pinchartl, hverkuil, let's do it now, then ;)
ok
15 minutes left for me :-)
so
we've discussed MC + DVB in San Jose
and pretty much agreed on changes that needed to be made to the API that Mauro has merged already
the question I have is, what's the next step, and who should work on it ?
from what we got on etherpad:
- The Satellite Equipment Control (SEC) should be an entity, linking them to the connector
- Deprecated osd, teletext, video and audio device nodes are only used in av7110. The av7110 driver uses lots of deprecated stuff, we should move this to staging and deprecate the whole driver and see who starts yelling.
- Document the high-level overview of DVB (Mauro). Layout needs to be changed to be in line with the other APIs (Hans?).
- Mauro will rename "frontend" entity to "demod" at the Media Controller, as the frontend is actually a set of elements.
- Laurent will prepare a proposal of reporting device nodes via a new entity properties API addition
right
when do we need to get that in mainline ?
to put it differently, how much latitude do we have to change the API you have committed ?
well, nothing is set into an stone until 4.1
so, we can change what's needed during -rc3 to -rc6
that's 3 weeks
yes. we should focus on things that need to be changed, if any
I won't be adding SEC entity right now, as this could be added latter
well, yes, changes are very much needed :-)
I'm in Taiwan right now
deprecating av7110 can also be for 4.2 or even latter...
and I'm not sure if I could find time this week
Hello!
so the DVB API documentation is not urgent...
Just got out of a meeting...
sailus: so you've just volunteered to propose an entity properties API ? :-)
I don't think I'll be involved in this at all. I might do some work on the DVB API, but there's no urgency for that part.
the "frontend" -> "demod" is a trivial patch. shouldn't be hard to do it
Hmm, well, yes. But first we should define the scope. What does this have to do with DVB in practice?
The part that I *would* like to tackle is adding VIDIOC_SUBDEV_QUERYCAP support and how to find the media device from a v4l node.
(I'll be on holiday for a week in the near future.)
sailus: have you read the San Jose notes ?
hverkuil: have you looked at my MC enumeration library ?
pinchartl: No, I haven't. I'll do that after the meeting.
sailus: in a nutshell, Mauro has committed patches to add DVB support to MC
they will land in v4.1
pinchartl: didn't that go the other way? I.e. here is the media device, find the others?
I'll publish the San Jose notes today at the News on Linuxtv.org... since nobody asked to change it, I'm assuming that everything is OK on the draft I sent
and we've concluded after quite lengthy discussions in San Jose that the API needs to be changed
one dependency is MC entity properties API to report devnodes for DVB
hverkuil: yes, but I wonder whether it could be used from v4l2(subdev) to mc as well
with a few changes
pinchartl: Extended information on entities, that's been discussed previously?
sailus: several times for a couple of years
:-)
:-)
I'd be glad to.
I have a telco in 3 minutes, let's discuss it afterwards
ok
pinchartl: I still think it is awfully inefficient. My proposal was to just implement MEDIA_IOC_DEVICE_INFO for any entity, and have the major and minor number of the MC included in struct media_device_info. Works everywhere and is easy to do (including for DVB).
hverkuil: let me think a bit more about it
my brain is still in the Finnish time zone
which means that it woke up way too early today, not that it's enjoying the end of the afternoon :-)
hverkuil: I'm adding right now the media summit report at:
http://linuxtv.org/news.php?entry=2015-05-05.mchehab
I need to send the presentations to linuxtv.org
did you send the last version of your slide decks to me?
yes, you should have it.
mailed to you March 27
didn't arrive to me
sent to you osg samsung account
looked at both infradead and samsung mailboxes
I'll mail again
hmm... found one
march 26
Date: Thu, 26 Mar 2015 19:14:37 -0700
updates2.odp
that's the one.
ok, thanks!
Ah, I sent it from the US, so when I look at it here in Oslo the dates is shifted.
ah
ok, I think this is now in good shape:
http://linuxtv.org/news.php?entry=2015-05-05.mchehab
please check
mchehab: "Mauro presented a set of slides (add link)"...
Do you have the link? :-)
sailus, please refresh the page ;)
can you export my odp as a pdf and use that? I can make a pdf as well if you like.
mchehab: Thank you. :-)
hverkuil: sure. do you want me to keep the odp file there, or just the pdf?
(just the pdf is probably better, IMHO)
just the pdf
ok
done
nice, thanks.
bbiab
mchehab: I don't really recall why you wanted to specify the final entity for media_entity_pipeline_start()
neither what we have decided about that :-/
pinchartl: you said it was ok to add support for it...
mchehab: Could you shed a little light on what you two are talking about? :-)
the idea was to be able to start/stop just the frontend part of the pipeline...
as, on DVB, the streaming is done via a separate devnode
For what purpose? So you could reconfigure it and not stop the rest until restarting the frontend?
sailus: it is like that by design...
the frontend devnode controls the tuning part of the pipeline
(SEC, demod, tuner, LNA, LNBf)
the demux devnode controls the streaming part (DMA engine, MPEG TS filtering and output devnode)
can I let you two discuss that ? it's 1:15am here and I really need to sleep
11~.
pinchartl: get some sleep ;)
obrigado :-)
So you'd like to stop, reconfigure and restart one without the other?
Or what?
g'night
hyva:a: yo:ta:
pinchartl: Bonne nuit!
and however they say that in Taiwan :-)
X-)
hmm. media_entity_init() ends up calling kzalloc() with size=0 if num_pads=0 and extra_links=0 - that doesn't sound correct
shuah: In that case kmalloc() returns ZERO_SIZE_PTR.
I believe the code (or at least that part of it) is correct.
The links array naturally won't be used in that case.
I hope so :)
There are a few calls with num_pads=0 and extra_links=0
shuah: as3645a does that, for example.
right a few others as3645a_probe(), lm3560_subdev_init() etc. I think we are okay as long as entity->links isn't accessed
kfree in media_entity_cleanup() is a no-op for ZERO_SIZE_PTR
mchehab: just to make sure there's no misunderstanding, the MC+DVB API that will land in v4.1 will be considered as experimental, and could be changed in v4.2 without any worry about breaking userspace, right ?