Jacek Anaszewski wrote:
Hi Hans, Sakari,
On 02/17/2015 12:32 PM, Sakari Ailus wrote:
Hans Verkuil wrote:
Unfortunately, it only works one time, because the next time the
a zero to the control cluster_changed returns false.
I think on volatile controls it is safer to run s_ctrl twice than
I know I am abusing a bit the API for this :P, but I also believe
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.
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.