Hi, > > Yes. As long as the sensors are implemented as sub-devices (see > Documentation/video4linux/v4l2-framework.txt) then you can add lots of custom > controls to those subdevs that can be exposed to userspace. Writing directly > to sensor registers from userspace is a no-go. If done correctly using the > control framework (see Documentation/video4linux/v4l2-controls.txt) this shouldn't > take a lot of code. The hardest part is probably documentation of those controls. > Well, we could generate all the control handlers from XML by writing appropriate style sheets, but the point is that there are by now a few hundreds of registers covered up in the current driver. Putting this into the kernel would horribly bloat it, and this again is a no go on our embedded system. Documentation is also generated per property, BTW (as long as the user fills in the <info> node) Just to outline again what we're doing: The access to the registers (at least to the SPI control interface) is in fact in kernel space, just the handlers (and remember, there are a few 100s of them) are not. This keeps the kernel layer lean and mean. For machine vision people, most of the typical v4l2 controls are irrelevant, but for things like video format, we just pass ioctl calls to user space via kernel events, handle them, and pass the register read/write sequence back to the kernel. What problem do you see doing it this way? There seem to be various uio based drivers out for v4l2 devices. For i2c, we access the registers even through the /dev/i2c-X. So far I see no problem with that, it turned out to provide better latencies (for the video acquisition) in some scenarios that way. This does not allow to switch configs in real-time, but this is a hacky task for i2c anyhow. > ... > > That's why you want to always go through a kernel driver instead of mixing > kernel and userspace. > > However, at the moment we do not have the ability to set and active a > configuration at a specific time. It is something on our TODO list, though. > You are not the only one that wants this. > If we're adapting our stuff to the new framework, it will likely be opensource, too. Just a few people will need to be convinced.. Cheers, - Martin -- 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
