On Fri, 5 Aug 2011, Andrew Chew wrote: > > > One way to solve this can be to defer these I2C > > transactions in the image sensor driver all the way up > > > to the time the image sensor is asked to start streaming > > frames. However, it seems to me that this breaks > > > the spirit of the probe; applications will successfully > > probe for camera presence even though the camera > > > isn't actually there. Is this okay? > > > > > > Is there a better way to do this? Maybe a more general > > thing we can add to the V4L2 framework? > > > > Probing for the presence of the device hardware at driver > > init time seems > > to be the right thing to do, even when the LED blinks. PC > > keyboard LEDs > > also blinks during machine reset, and this is not really > > annoying. Even > > on some embedded devices like some cell phones, LEDs blink > > during the boot > > time. > > It's a bit different when the camera LED blinks, though. The whole > problem is that the user will have thought that the system took a > picture of them without knowing. What the user sees will potentially be > indistinguishable between expected behavior, and a system that has been > compromised to make use of that blink to actually take a picture, > leading to privacy concerns. > > > > So, as a general rule, I'd say that the better is to keep the > > capability of > > probing the hardware at init time, especially since the same > > sensor may > > eventually be used by non SoC drivers. > > I completely agree with you. I was just hoping that others have run > into this as well, and that there was an officially endorsed method to > solve this. Sounds like there isn't. > > > > One strategy that several drivers do, and that solves the > > issue of blinking > > after the device reset is to have a shadow copy of the > > register contents. > > This way, you can defer the device register writes to occur > > only when you're > > actually streaming. E. g. you'll still have the blink at > > probe time (probably > > a longer one), but, after that, the driver can just work with > > the cached > > values, up to the moment it will really start streaming. > > Yes, that's easy to do, and will completely solve the blink on open issue. This would require modifying each sensor driver. And not always these shadowing is desired. A simpler approach seems to be to only load the driver, when streaming is required. Yes, it would add a (considerable) delay to streaming begin, but you'd be completely honest to your user and privacy would be guaranteed. Another less secure approach would be to tie your LED to a different function, to one, that only activates, when actual data is transferred. Maybe you can tie it to one of sync or clock signals? Look whether your sensor has any pins, that only get activated, when video data is transferred. You can also trigger it from the software, but this might contradict your security policy. However, if you think about it, I don't think your users anyway have a chance to make really 100% sure, their privacy is not violated, so... Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
