Support for configuration files

[otaku42]

It would be helpful to have support for saving the current configuration of a device to a file, and/or to load a previously saved configuration from a file and apply it to a device.

This could be achieved by adding something like save_config() and load_config() methods to the Device class. However, it appears to me that having support for this functionality in a submodule in its own class might be a better choice - it adds a bit of flexibility, since this way one doesn't have to carry this stuff around if it's not used.

Using toml for this purpose would be nice, but support for this format just recently has been added to Python (as PEP-0680 in v3.11). Several external libraries like tomlkit exist, but they introduce additional dependencies. On the other hand, ConfigParser is part of the standard library and seems to be tweakable towards our needs. So let's try the included batteries and see how far they carry us.

The config file should be kind of meaningful for humans, too, and could be something like:

### v4l2py device configuration file ###

[device]
driver = uvcvideo
card = Integrated IR Camera: Integrate
bus_info = usb-0000:00:14.0-5
version = 6.0.12

[controls]
9963776 = 128   # brightness
9963777 = 32    # contrast
9963778 = 64    # saturation
9963779 = 0     # hue
9963788 = 1     # white_balance_automatic
9963792 = 120   # gamma
9963795 = 1     # gain
9963800 = 0     # power_line_frequency
9963802 = 4000  # white_balance_temperature
9963803 = 2     # sharpness
9963804 = 1     # backlight_compensation
10094849 = 3    # auto_exposure
10094850 = 156  # exposure_time_absolute
10094851 = 0    # exposure_dynamic_framerate

The section [device] contains information about the device the configuration has been obtained from, and allows for some kind of upfront check of whether the parameters will be relevant for the device it is going to be applied to. The keys used in this section directly relate to what can be found in class Info.

The section [controls] contains the actual control settings. As it seems to be possible that different drivers may use different naming schemes for the same type of control, it might make sense to use the control IDs as keys in this section. The name of that control can be added as an inline comment, so that humans could still make sense of the settings.

On the other hand, a configuration file is meant to be re-applied to the same device again, and it's very unlikely that this device / its driver changes the naming scheme for controls all of a sudden. Thus it shold be safe to use config_name as key rather than id - that way we could get away without the use of inline comments.

One thing I'm uncertain of is how to deal with inactive controls. Without having a working code example I just assume that it might make sense to record all controls and their current values, regardless if they are active or not at the time of creation of the configuration file.

When applying the settings back to the device, we would have to make sure, however, not to write to inactive controls. But then... such a check would rely on the current state of the controls, which might give a wrong picture:

Looking at the above example, there is white_balance_automatic and white_balance_temperature. At the time of creation of this example, white_balance_automatic was set to 1, which made white_balance_temperature become inactive. However, when applying the configuration back to the same device at a later time, it might be that white_balance_automatic is disabled and thus our check might come to find white_balance_temperature to be active. Setting white_balance_automatic to 1 as per the configuration file would change white_balance_temperature to be inactive; if we relied on the results of check done beforehand and thus tried to write a value to white_balance_temperature this would fail.

In other words, we have to check the status of each control one after another and right before trying to writing to it - hoping that such status changes become visible immediately and without requiring us to actively re-read the current status of the device in question after every change to a control. I think this should be the case, but I have to double-check that.

In case it turns out that changing controls in a serial manner is problematic: there was "something" "somewhere" that it might be possible to "bulk change" controls. I'm not sure if that just relates to the fact that v4l2-ctl accepts multiple controls to be set in the same call, or if there actually is something like a dedicated ioctl for such bulk changes. Would have to be investigated.

[otaku42]

On the other hand, a configuration file is meant to be re-applied to the same device again, and it's very unlikely that this device / its driver changes the naming scheme for controls all of a sudden. Thus it shold be safe to use config_name as key rather than id - that way we could get away without the use of inline comments.

That would be something like:

### v4l2py device configuration file ###

[device]
driver = uvcvideo
card = Integrated IR Camera: Integrate
bus_info = usb-0000:00:14.0-5
version = 6.0.12

[controls]
brightness = 128
contrast = 32
saturation = 64
hue = 0
white_balance_automatic = 1
gamma = 120
gain = 1
power_line_frequency = 0
white_balance_temperature = 4000
sharpness = 2
backlight_compensation = 1
auto_exposure = 3
exposure_time_absolute = 156
exposure_dynamic_framerate = 0

Yep, let's try that.