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
--
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
