RFC: Where to store camera properties (upside down, needs sw whitebalance, etc). ?

We came to the conclusion that having a table in the kernel only for the purpose of userspace being able to query it, is not very efficient, and in general is not a good idea.

So for the table of upside down webcam's we came to the following conclusion:
-if the driver can do the rotation itself (in hw) then the table should be in the driver and it should invert the meaning of its hflip and vflip controls, (iow off is flip, on is do not flip) so that usserspace won't notice the cam being upside down in anyway
-if the driver can not do the rotation libv4l will do it, and the table of cams which need this (such as certain uvc models) will be part of libv4l

So I started thinking about my proposal to add read-only controls (CID's) to drivers which libv4l can query to find out if it would be a good idea to do things like software white balance for a cam.

On second thought this is a bad idea for all the same reasons, having a table in the kernel, just so that userspace can query it makes little sense. Better to just put the table in userspace.

So this mail mainly is a retraction of my earlier proposal (instead I will completely handle this in libv4l). But there are 2 special cases libv4l will still need some userspace <-> kernel API for:

1) With some bridges it is common to not have a usbid per bridge / sensor combi, but cams with the same usb-id can have different sensors (the driver finds out which one by probing the i2c bus between the bridge and sensor). Since things like whitebalance and autogain are often done in the sensor, in these cases libv4l will need a way to find out the sensor (the bridge it can deduct from the usb-id). So we need a userspace API to query which sensor a bridge is connected too.

I would like to suggest to use one of the 4 reserved __u32's in the v4l2_capability struct for this. We could then make a very large enum with all known sensors and store that there, but instead I would suggest to make this a driver specific field, so v4l2_capability would then look like this:

2) With some cams the upside down ness may actually be stored in an eeprom, or in some cases even determined by a switch (so the cam can be rotated manually by the user and the the switch indicates the position)

In these cases we need a userspace API to find this out too. Since this is a per frame thing for some cams (one frame could be upright, the next upside down). I would like to suggest to define some V4L2_BUF_FLAG_ 's for this which can be used by drivers to indicate that the picture in the buffer is vflipped or hflipped (with upside down being both together).