Hi, <snip snip snip> Ok, thinking about this some more and reading Hans V's comments I think that the current code in Hans V's core8c branch is fine, and should go to 3.1 (rather then be delayed to 3.2). As for the fundamental question what to do with foo controls when autofoo goes from auto to manual, as discussed there are 2 options: 1) Restore the last known / previous manual setting 2) Keep foo at the current setting, iow the last setting configured by autofoo Although it would be great if we could standardize on one of these. I think that the answer here is to leave this decision to the driver: - In some cases this may not be under our control at all (ie with uvc devices), -in other cases the hardware in question may make it impossible to read the setting as configured by autofoo, thus forcing scenario 1 so that we are sure the actual value for foo being used by the device matches what we report to the user once autofoo is in manual mode That leaves Hans V's suggestion what to do with volatile controls wrt reporting this to userspace. Hans V. suggested splitting the control essentially in 2 controls, one r/w with the manual value and a read only one with the volatile value (*). I don't think this is a good idea, having 2 controls for one foo, will only clutter v4l2 control panels or applets. I think we should try to keep the controls we present to the user (and thus too userspace) to a minimum. I suggest that instead of creating 2 controls, we add a VOLATILE ctrl flag, which can then be set together with the INACTIVE flag to indicate to a v4l2 control panel that the value may change without it receiving change events. The v4l2 control panel can then decide how it wants to deal with this, ie poll to keep its display updated, ignore the flag, ... Regards, Hans *) Either through a special flag signalling give me the volatile value, or just outright making the 2 2 separate controls. -- 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
