On Saturday 07 February 2009 18:15:24 Adam Baker wrote: > Hi All, > > Now that the SQ-905 driver has been accepted into the gspca tree it is > time to consider how best to address passing the sensor orientation from > the driver to libv4l. > > For this camera the approach taken so far of knowing what orientation is > needed based on the USB ID won't work as there are variants of the camera > with different sensor orientation but the same ID. The driver can detect > this based on some initialisation messages but needs to tell libv4l. > > For SQ-905 the orientation will remain fixed but we know there exist > cameras that provide some form of tilt switch to detect orientation so > the adopted solution should be able to cope with those too. > > Olivier Lorin has proposed a solution to this problem that involves using > 2 new bits in v4l2_buffer->flags and has offered a patch for libv4l to > add support for the 180 degree rotation case. > > Does anyone have a suggestion for a better way to address this problem? > If not I'll prepare a patch to add the flags to include/linux/videodev2.h > and one to set them in sq905.c. Well, since you ask :-) I think doing this in the v4l2_buffer flags is not quite the right place. Basically a high-level property (sensor orientation) is reported in a very low-level flags field. Personally I would prefer to see a SENSOR_ORIENTATION (or something similar) read-only control that libv4l could read X seconds or so when capturing. Besides, using v4l2_buffer will not work if you use the read() interface. And as an end-user I am actually interested in seeing what the orientation is. Regards, Hans > After that I'll work on expanding Olivier Lorin's patch to > 1) Ignore the flag from the driver for cameras listed in v4lconvert_flags > (otherwise as the kernel driver doesn't currently set the flag for those > cameras the change would be incompatible with current kernels for those > cameras). > 2) support independent setting of HFLIP and VFLIP (some SQ-905 cameras > need only VFLIP). > > And finally add the flags in the kernel drivers for the cameras listed in > v4lconvert_flags so that eventually (once we are confident no-one running > 2.6.29 will want a new libv4l) that functionality can be removed from > libv4l. > > What is the preferred version of libv4l to prepare patches against? Is it > http://linuxtv.org/hg/~hgoede/v4l-dvb > > Adam Baker > -- > 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
