On Saturday 14 February 2009 21:48:51 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() so it looks like implementing a read only control > is the only appropriate option. > > It seems that Sensor Orientation is an attribute that many cameras may > want to expose so it shouldn't be a private control. Olivier Lorin's > example patch created a new CAMERA_PROPERTIES class. I'm not sure that a > new class is really justified so would like to hear other views on where > the control should live (and also if everyone is happy with Hans > Verkuil's suggested name of SENSOR_ORIENTATION which I prefer to Olivier > Lorin's SENSOR_UPSIDE_DOWN as we want to represent HFLIP and VFLIP as > well as upside down (which as currently implemented means 180 degree > rotation.)) > > Assuming that it is considered inappropriate to add a new control as > an "Old-style 'user' control" then it is also, I presume, necessary to > extend gspca to support VIDIOC_G_EXT_CTRLS as at the moment it requires > all control access to use VIDIOC_G_CTRL. Would doing this conflict with > anything anyone else may be working on such as conversion to use > v4l2_device. > > Thoughts please. This is definitely a camera control, so I guess you need to add this new camera control and the g_ext_ctrls ioctl. It's a bit overkill, and I have lots of ideas on how to drastically improve control handling in drivers, but that's a few months in the future once all drivers are converted to v4l2_device. Hmm, if you are working in gspca anyway, are you interested in adding v4l2_device to it? It's trivial for that driver. Regards, Hans -- 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
