On Friday 11 September 2009 21:54:03 Mauro Carvalho Chehab wrote: > Em Fri, 11 Sep 2009 21:08:13 +0200 > Hans Verkuil <hverkuil@xxxxxxxxx> escreveu: <snip> > > OK, so instead we require an application to construct a file containing a new > > topology, write something to a sysfs file, require code in the v4l core to load > > and parse that file, then find out which links have changed (since you really > > don't want to set all the links: there can be many, many links, believe me on > > that), and finally call the driver to tell it to change those links. > > As I said before, the design should take into account how frequent are those > changes. If they are very infrequent, this approach works, and offers one > advantage: the topology will survive to application crashes and warm/cold > reboots. If the changes are frequent, an approach like the audio > user_pin_configs work better (see my previous email - note that this approach > can be used for atomic operations if needed). You add at a sysfs node just the > dynamic changes you need. We may even have both ways, as alsa seems to have > (init_pin_configs and user_pin_configs). How frequent those changes are will depend entirely on the application. Never underestimate the creativity of the end-users :-) I think that a good worst case guideline would be 60 times per second. Say for a surveillance type application that switches between video decoders for each frame. Or some 3D type application that switches between two sensors for each frame. Of course, in the future you might want to get 3D done at 60 fps, meaning that you have to switch between sensors 120 times per second. One problem with media boards is that it is very hard to predict how they will be used and what they will be capable of in the future. Note that I am pretty sure that no application wants to have a media board boot into an unpredicable initial topology. That would make life very difficult for them. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
