<!-- 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>

   headless: <u>ndufresne</u>: :-)
   pinchartl: <u>ndufresne</u>: or possibly today :-)
   <br> <u>ndufresne</u>: the idea is that we need a device node that is global to a media device to perform operations that span multiple subdevs and video nodes
   <br> and the media controller device fits that requirement
   ndufresne: pinchartl, but then drivers that didn't need a media controller before will bee one just to implement requests
   <br> And all userspace need to figure-out the media node for a video node
   <br> Do we have a plan to make at least the second easier ?
   pinchartl: <u>ndufresne</u>: I think it should be the other way around. userspace should start from the media device and go to video nodes
   <br> a media device represents a device in the user sense of the term
   <br> a webcam, a TV capture card, a camera in a smartphone, a video codec, ...
   <br> in some cases thoses devices are controlled through a single video node, but in many cases there are several video nodes and possibly subdevs too
   <br> it would be way more user-friendly to expose to users concepts such as a smartphone camera with its front and back cameras instead of /dev/video*
   ndufresne: ok, I guess we can do that
   <br> does the media controller gives some clue about audio too ?
   pinchartl: yes and no
   <br> it's designed to
   <br> but the designed has never been finalized
   <br> so it doesn't now as ALSA drivers don't implement it
   <br> but it should
   ndufresne: so in theory you could have a "Note subtype ALSA ..."
   pinchartl: there should be MC entities for ALSA devices, yes
   <br> and MC should show how they're connected to video
   <br> s/connected/related/
   ndufresne: hmm, it's funny how /dev/snd/by-id/ suffer similar bug to v4l one, it does not show up everything
   <br> pinchartl, another question, how do you represent M2M as MC entity ? I thought this was just not supported
   <br> it's kind of needed immediatly to merge the rockchip and allwinner codecs no ?
   pinchartl: the request API is needed for stateless codecs
   ndufresne: (yes, that's the case for Rockchip CODEC)
   pinchartl: as for how to represent M2M devices, I haven't tried it yet :-)
   ndufresne: first look it'S just a type Node subtype V4L, with a src and sink pad, but if there is any kind of generic sw using it, it might be surprised ;-P
   <br> (what does flags 1 means in the topology dump)
   <br> actually I got that wrong
   <br> it's probably without any pads right ?
   -: ndufresne still figuring out this old system ;-P
   pinchartl: I think you can have a subdev with a sink and a source pad, each connected to a video node
   <br> it would require a video node with two pads, which we don't support yet I think
   -: ndufresne is under the impression that this request api is not going to be useful before a long time ;-P
   ndufresne: Does Alexandre Courbot is aware of these bumps ?
   <br> His RFC was not very verbose on anything
   pinchartl: he should be :-)
   <br> I haven't read the RFC yet
   ndufresne: it's .... short
   <br> at the same time, it enables vim2m, but I haven't built it to see if the topology is usable for generic software
   <br> for enumerating devices, it will be quite fun to have to enumerate /dev/media*, keep a list of /dev/video, and then enumerate over the /dev/video that haven't bee included yet ;-P
   <br> but thinking about it, the distro method is to use udev, right now media node don't show up, and if they do, well, you'll have both dev path in there, no choice