<!-- 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>
***: BrianG61UK has joined #linux-media
<br> x[m] has joined #linux-media
<br> eelstrebor has quit IRC (Quit: Ex-Chat)
<br> Ampera has joined #linux-media
<br> darkapex has quit IRC (Remote host closed the connection)
<br> darkapex has joined #linux-media
<br> jm_h has joined #linux-media
<br> darkapex1 has joined #linux-media
<br> darkapex2 has joined #linux-media
<br> darkapex has quit IRC (Ping timeout: 480 seconds)
<br> darkapex1 has quit IRC (Ping timeout: 480 seconds)
<br> ao2 has joined #linux-media
<br> tailinchu has quit IRC (Remote host closed the connection)
<br> gouchi has joined #linux-media
<br> gouchi has quit IRC (Remote host closed the connection)
<br> GBenji has joined #linux-media
<br> svarbanov has joined #linux-media
<br> djrscally has joined #linux-media
<br> djrscally has quit IRC (Ping timeout: 480 seconds)
<br> djrscally has joined #linux-media
<br> lexano has joined #linux-media
<br> darkapex2 is now known as darkapex
<br> eelstrebor has joined #linux-media
<br> ao2 has quit IRC (Quit: Leaving)
pratyush: Does the media graph walk API consider the graphs as directed? Is there any way to walk the graph in "reverse" order? That is, from destination to source.
***: eelstrebor has quit IRC (Ping timeout: 480 seconds)
<br> GBenji has left
pinchartl: <u>pratyush</u>: no, it's not directed, and not limited to linear graphs. it's breadth-first or depth-first, can't remember which one
***: gouchi has joined #linux-media
<br> [LOGGER] starts logging #linux-media at Tue Oct 05 17:13:26 2021
<br> [LOGGER] has joined #linux-media
<br> eelstrebor has joined #linux-media
pratyush: <u>pinchartl</u>: It is depth first, at least that is what it is supposed to be. I am playing around with graph traversal on top of tomba's multistream patches and I don't get the traversal I would expect. No matter which starting pad I pick it always starts from the top of the graph, the camera node
***: [LOGGER] starts logging #linux-media at Tue Oct 05 18:17:21 2021
<br> [LOGGER] has joined #linux-media
ndufresne: <u>pratyush</u>: perhaps dump it in a dot file ? sometimes a picture helps
<br> there is very little validation in the kernel, so its easy to endup with a broken link
***: [LOGGER] starts logging #linux-media at Tue Oct 05 18:40:56 2021
<br> [LOGGER] has joined #linux-media
ndufresne: <u>pratyush</u>: media-ctl --print-dot
<br> then use dot -Tpng my.got > my.png
<br> you can also -Tsvg
pratyush: <u>ndufresne</u>: Thanks!
ndufresne: <u>pratyush</u>: I personally use a small script that compile, open eog (gnome viewer) and remove the svg, https://paste.centos.org/view/2dee8e02
pratyush: This is what the graph looks like: https://usercontent.irccloud-cdn.com/file/XM2Regvz/graph.png
<br> And this is what the traversal looks like: https://www.irccloud.com/pastebin/ZwXc3Smw/
<br> Doesn't look like depth first search to me ;-)
ndufresne: its funny that pinchartl said it's not directed, but the generated dot it directed ...
<br> I don't know how many time we'll say that, but kernel dev should really work out names that are both unique and means something to human being ...
<br> ovXXX I can guess, but ds90...
***: [LOGGER] starts logging #linux-media at Tue Oct 05 19:20:23 2021
<br> [LOGGER] has joined #linux-media
ndufresne: <u>pratyush</u>: I would expect the walk order to indeed be depth first, but there is no define order on which leaf will be visited first apparently, that depends on which order the links have been passed
<br> also, notice that leaf might be skipped if MEDIA_LNK_FL_ENABLED was not set
pratyush: <u>ndufresne</u>: It jumps from 'ds90ub913a 9-0047':1 (right most serializer) to 'ov10635 12-0030':0 (second from right sensor). These two nodes are not even connected. I would expect the next jump to be ds90ub960 node.
<br> All the links shown in the graph are enabled
ndufresne: thinking out loud, that looks like what has been implemented
pratyush: I am not quite clear on what media_graph_walk_iter() does. The rest looks fine to me
ndufresne: media_graph_walk_iter() will push, assuming left to right order, ovXX-10, ds90ub913a 9-0044, ovXX-12, ds90ub913a 9-0045, and so on
<br> <u>pratyush</u>: if I read it right, it will push entity till a leaf is met, e.g. no more unvisited links, and pop and try to visite more links, and pop and try to visite more links again
<br> it memorise which links have been visited, so the order you get is .... meaningless I could say ?
<br> but it is depth first from the point of view of currently visite links and your starting point
<br> not sure what folks do with such an API, it looks funky to me, specially that these are directed graph, but perhaps cycles are allowed ...
<br> so I think all this does is a way to iterate over all entity that are attache to a starting point
<br> with no specific ordering
pratyush: I am trying to use it for some basic pipeline validation. The CSI-2 Rx IP I have can only do very limited format conversions. For the rest, output format needs to be exactly the same as input format. So it would start at the bottom, work its way up to the top until it hits the first subdev that implements get_fmt. It will use that for the format checks
<br> But maybe its place is not in the driver at all, and I should leave it up to the application to configure everything correctly. If they don't, expect things to break. Dunno...
pinchartl: <u>pratyush</u>: applications are supposed to configure everything correctly, but the kernel should validate the configuration
<br> this is mostly handled by the core though
<br> using graph traversal indeed
<br> the order doesn't really matter
<br> <u>tomba</u>: you may have an opinion on this
pratyush: <u>pinchartl</u>: It does though. Say the sensor sends out YUV but the deserializer (or the ISP) converts it to RGB or some other format. The CSI-2 Rx driver doesn't care about what the sensor outputs. It only cares about what it is receiving. To know that, it needs to find out which subdev last touched the format (bridges for example might not touch it at all). The order matters here.
pinchartl: userspace is supposed to set the format on the CSI-2 RX input, and that format is supposed to match the format on the output of the source
<br> pipeline validation will only check that formats on the two ends of a link or identical
<br> this isn't about propagating formats through the pipeline, only about validating the configuration
pratyush: <u>pinchartl</u>: Who is supposed to validate format propagation through the pipeline? Userspace?
pinchartl: userspace propagates formats between subdevs, kernelspace validates the pipeline configuration at VIDIOC_STREAMON time
<br> for instance
<br> if you have subdevs A and B
<br> connected as [ A |0] -> [0| B ]
<br> (pad 0 of A connected to pad 0 of B)
<br> userspace will call VIDIOC_SUBDEV_S_FMT on A:0 and on B:0
<br> it can set different incompatible formats
<br> and the drivers shouldn't complain
<br> until VIDIOC_STREAMON is called
<br> then the kernel will validate the pipeline, and realize that the formats on the two ends of that link don't match. that will result in VIDIOC_STREAMON returning -EPIPE
***: jm_h has quit IRC (Remote host closed the connection)
<br> eelstrebor has quit IRC (Remote host closed the connection)
pratyush: <u>pinchartl</u>: Okay, got it. So I think what I really need to do is implement get/set fmt on bridge subdev (and just expect same input/output formats) so that the chain of validation is done properly. Did I understand you correctly?
pinchartl: yes, I think so
<br> the model really splits format propagation within the pipeline in two parts
<br> - userspace is responsible for propagating formats across links. if it gets it wrong, it's caught at STREAMON time only, subdev drivers won't complain in .set_fmt()
***: eelstrebor has joined #linux-media
pinchartl: - subdev drivers are responsible for propagating formats *inside* the subdev. when userspace calls VIDIOC_SUBDEV_S_FMT on an input pad of a subdev, the driver will automatically update the format on the output pad(s) if needed
<br> so the state of a subdev is guaranteed to always be consistent
<br> but consistency across the whole pipeline is only checked at streamon time
***: djrscally has quit IRC (Quit: Konversation terminated!)
<br> sailus has quit IRC (Ping timeout: 480 seconds)
<br> djrscally has joined #linux-media
<br> gouchi has quit IRC (Remote host closed the connection)
<br> sailus has joined #linux-media
<br> sailus has quit IRC ()
pratyush: pinchartl ndufresne Thanks for all the help :-)
***: svarbanov has quit IRC (Ping timeout: 480 seconds)
<br> djrscally has quit IRC (Ping timeout: 480 seconds)