Hi Jacek, Jacek Anaszewski wrote: > Hi Hans, Sakari, > > On 02/17/2015 12:32 PM, Sakari Ailus wrote: >> Hi Hans, >> >> Hans Verkuil wrote: >> ... >>>> Unfortunately, it only works one time, because the next time the >>>> user writes >>>> a zero to the control cluster_changed returns false. >>>> >>>> I think on volatile controls it is safer to run s_ctrl twice than >>>> missing a >>>> valid s_ctrl. >>>> >>>> I know I am abusing a bit the API for this :P, but I also believe >>>> that the >>>> semantic here is a bit confusing. >>> >>> The reason for that is that I have yet to see a convincing argument for >>> allowing s_ctrl for a volatile control. >> >> Well, one example are LED flash class devices which implement V4L2 flash >> API through a wrapper. The user may use the LED flash class API to >> change the values of the controls, and V4L2 framework has no clue about >> this. The V4L2 controls are volatile, and the real values of the >> settings are stored in the LED flash class. >> >> This is the current implementation (not merged yet); an alternative, a >> more correct one, would be to use callbacks to tell about the changes in >> control values. I haven't pushed for that, primarily because the >> patchset is already quite complex and I've seen this as something that >> can be always implemented later if it bothers someone. >> >> Cc Jacek. >> > > Actually this will be not an issue for v4l2-flash sub-device anymore. > In the next version of the patch set the v4l2-flash sub-device > will be synchronizing the flash device registers with the > state of the controls on open. Ah, right --- you're preventing the use of the LED flash class whilst the V4L2 sub-device is opened? I'm not fully certain whether that'd be really useful, as the V4L2 sub-device can also be opened by multiple users at the same time. However the applications that would access the LED class API are mostly different ones and for different purposes; I don't really have a strong opinion either way here. -- Regards, Sakari Ailus sakari.ailus@xxxxxxxxxxxxxxx -- 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
