Laurent, Thanks for the quick feedback. Sorry if my previous email caused confusion. What I meant was that the daemon subscribes to events from video0 device, and sends out ioctl commands to control the hardware based on these events. So the kernel driver isn't proactively communicating with the daemon. But your comments about libv4l and daemon raise a good point. I will take a look at libv4l, and see how it fits with daemon in my case. Regards, Shuzhen -----Original Message----- From: Laurent Pinchart [mailto:laurent.pinchart@xxxxxxxxxxxxxxxx] Sent: Wednesday, November 24, 2010 3:05 PM To: Shuzhen Wang Cc: linux-media@xxxxxxxxxxxxxxx; 'Hans de Goede' Subject: Re: Zooming with V4L2 Hi Shuzhen, On Wednesday 24 November 2010 20:58:33 Shuzhen Wang wrote: > Hello, Laurent, > > About using daemon, we have proprietary image processing and optimization > code that needs to sit between application and driver. That's a pretty common requirement, and there's nothing seriously wrong there (apart from the fact the code should be open, but that's another story :-)). > I wasn't working on V4L2 at the time, but this constraint was discussed > in the 2010 mini summit. And it was mentioned in section (1) of > http://www.linuxtv.org/news.php?entry=2010-06-22.mchehab. The proprietary image processing code should, as you mentioned, sit between the application and the driver. It can be implemented a a libv4l plugin, or as a daemon that a libv4l plugin talks to. I got the impression from your last e-mail that the application was communicating directly with the driver, which then communicates with a userspace daemon. That's something you want to avoid. Apologies if I got it wrong. -- Regards, Laurent Pinchart -- 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
