While testing the LED / flash API integration patches
I noticed that the v4l2-controls marked as volatile with
V4L2_CTRL_FLAG_VOLATILE flag behave differently than I would
expect.
Let's consider following use case:
There is a volatile V4L2_CID_FLASH_INTENSITY v4l2 control with
following constraints:
min: 1
max: 100
step: 1
def: 1
1. Set the V4L2_CID_FLASH_INTENSITY control to 100.
- as a result s_ctrl op is called
2. Set flash_brightness LED sysfs attribute to 10.
3. Set the V4L2_CID_FLASH_INTENSITY control to 100.
- s_ctrl op isn't called
This way we are unable to write a new value to the device, despite
that the related setting was changed from the LED subsystem level.
I would expect that if a control is marked volatile, then
the v4l2-control framework should by default call g_volatile_ctrl
op before set and not try to use the cached value.
Is there some vital reason for not doing this?
--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
