Hi! > >>> V4L2MEDIADESC > >>> 3 # number of files to open > >>> /dev/video2 > >>> /dev/video6 > >>> /dev/video3 > >> > >> This won't work. The video nodes numbers (or even names) can change. > >> Instead these should be entity names from the media controller. > > > > Yes, it will work. 1) will configure the pipeline, and prepare > > V4L2MEDIADESC file. The device names/numbers are stable after the > > system is booted. > > No, they are not. Drivers can be unloaded and reloaded, thus changing > the device nodes. The media device will give you the right major/minor > numbers and with libudev you can find the corresponding device node. > That's the right approach. Well, yes, drivers can be unloaded and reloaded. But at that point pipeline will need to be set up again, so we'll get new V4L2MEDIADESC file. > > Yes, but that would slow down v4l2_open() needlessly. I'd prefer to > > avoid that. > > It should be quite fast. BTW, v4l2-ctl has code to find the media device > node for a given video node. Ok, I'll take a look, but I'd still prefer fast & simple. > >> For that matter: what is it exactly that we want to support? I.e. where do > >> we draw the line? > > > > I'd start with fixed format first. Python prepares pipeline, and > > provides V4L2MEDIADESC file libv4l2 can use. You can have that this > > week. > > I'm not sure I want python. An embedded system might not have python > installed. Also, if we need to parse the configuration file in libv4l > (and I am 90% certain that that is what we need to do), then you don't > want to call a python script from there. No, I don't propose calling python from libv4l2. I propose "separate component configures the pipeline, and writes V4L2MEDIADESC file libv4l2 then uses to map controls to devices". For me, that component is currently python. In embededded world, I guess they could hard-code the config, or write it in whatever language they prefer. > > Media control is more than 5 years old now. libv4l2 is still > > completely uses on media control-based devices, and people are asking > > for controls propagation in the kernel to fix that. My proposol > > implements simple controls propagation in the userland. I believe we > > should do that. > > Your proposal implements one specific use-case. One piece of a > larger puzzle. Well, rather important piece, because it allows the complex cameras to be used at all. > >> A good test platform for this (outside the N900) is the i.MX6 platform. > > > > Do you have one? > > Yes. Although I would need to set it up, I still haven't done that. Ok. > But Steve Longerbeam is probably the right person to test this for you. > > What I have been thinking of (although never in any real detail) is that we > probably want to have an application that is run from udev when a media device > is created and that reads a config file and does an initial pipeline configuration. > > So once that's setup you should be able to do: 'v4l2-ctl --stream-mmap' and > get video. > > Next, libv4l will also read the same configuration file and use it to provide > a compatibility layer so applications that use libv4l will work better with > MC devices. Part of that is indeed control handling. Yep, that would be nice. And yes, control handling is important for me. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
