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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
