On Tue, 2018-06-12 at 10:42 -0400, Nicolas Dufresne wrote: > Le mardi 12 juin 2018 à 07:48 -0300, Ezequiel Garcia a écrit : > > As discussed on IRC, memory-to-memory need to be modeled > > properly in order to be supported by the media controller > > framework, and thus to support the Request API. > > > > This RFC is a first draft on the memory-to-memory > > media controller topology. > > > > The topology looks like this: > > > > Device topology > > - entity 1: input (1 pad, 1 link) > > type Node subtype Unknown flags 0 > > pad0: Source > > -> "proc":1 [ENABLED,IMMUTABLE] > > > > - entity 3: proc (2 pads, 2 links) > > type Node subtype Unknown flags 0 > > pad0: Source > > -> "output":0 [ENABLED,IMMUTABLE] > > pad1: Sink > > <- "input":0 [ENABLED,IMMUTABLE] > > > > - entity 6: output (1 pad, 1 link) > > type Node subtype Unknown flags 0 > > pad0: Sink > > <- "proc":0 [ENABLED,IMMUTABLE] > > Will the end result have "device node name /dev/..." on both entity 1 > and 6 ? No. There is just one devnode /dev/videoX, which is accepts both CAPTURE and OUTPUT directions. > I got told that in the long run, one should be able to map a > device (/dev/mediaN) to it's nodes (/dev/video*). In a way that if we > keep going this way, all the media devices can be enumerated from > media > node rather then a mixed between media nodes and orphaned video > nodes. > Yes, that is the idea I think. For instance, for devices with multiple audio and video channels, there is currently no clean way to discover them and correlate e.g. video devices to audio devices. Not that this series help on that either :)
