On Wed, Jun 01, 2011 at 10:41:21AM -0300, Mauro Carvalho Chehab wrote: > > There are currently two use cases: Sakari's flash controller needs to > > report errors which are a bitmask of possible error conditions. It is way > > overkill to split that up in separate boolean controls, especially since > > apps will also want to get an event whenever such an error is raised. > > Hmm... returning errors via V4L2 controls don't seem to be a good implementation. > I need to review his RFC to better understand his idea. The "errors" are not errors in the traditional meaning --- they also are called faults. They signal that there's either a temporary or a permanent hardware problem with the flash controller. The user will be able to mitigate with many of these. Also the faults do arrive asynchronously, making traditional error handling unsuitable for them. For example, the LED controller may overheat in some situations which cause immediate LED shutdown, leading to only partially flash exposed frame. When this happens the user has to be notified of the condition, and to avoid reading a large set of controls, a single bitmask control telling directly the reason for the trouble is ideal. The full RFC may be found here: <USR:http://www.spinics.net/lists/linux-media/msg32030.html> Cheers, -- Sakari Ailus sakari dot ailus at iki dot fi -- 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
