Re: Adding a control for Sensor Orientation

[Hans de Goede <hdegoede@redhat.com>]

Adam Baker wrote:
> Hi all,
> 
> Hans Verkuil put forward a convincing argument that sensor orientation 
> shouldn't be part of the buffer flags as then it would be unavailable to 
> clients that use read()

Yes and this is a bogus argument, clients using read also do not get things 
like timestamps, and vital information like which field is in the read buffer 
when dealing with interleaved sources. read() is a simple interface for simple 
applications. Given that the only user of these flags will likely be libv4l I 
*strongly* object to having this info in some control, it is not a control, it 
is a per frame (on some cams) information about how to interpret that frame, 
the buffer flags is a very logical place, *the* logical place even for this!

The fact that there is no way to transport metadata about a frame like flags, 
but also timestamp and field! Is a problem with the read interface in general, 
iow read() is broken wrt to this. If people care add some ioctl or something 
which users of read() can use to get the buffer metadata from the last read() 
buffer, stuffing buffer metadata in a control (barf), because of read() 
brokenness is a very *bad* idea, and won't work in general due to 
synchronization problems.

Doing this as a control will be a pain to implement both at the driver level, 
see the discussion this is causing, and in libv4l. For libv4l this will basicly 
mean polling the control. And hello polling is lame and something from the 
1980-ies.

Please just make this a buffer flag.

Thank you,

Hans