Hi Paulo, I had a look at guvcview. I think it s a great app, full of features beyond a simple frame view/capturing. Great work. I am trying to write an application that properly displays V4L controls from any driver, and I have tested with pwc and uvcvideo so far. Digging into guvcview's source code confirmed what the point I made in my previous post: img_controls.c, which draws controls on the screen, is full of if..else if statements which do a lot more than just checking the control type. There are also some hardcoded menu values for the raw pixel order. This is precisely what I think should be done differently: In my opinion, when enumerating V4L controls, user applications should NOT have to check what a control DOES, ie trying to make sense of either the v4l2_queryctrl.name or v4l2_queryctrl.id field (which is what guvcview does), in order to draw this control on the screen. Doing this ties your application to a specific driver/implementation/version/... and will require more coding when any of these changes. An application should only have to check what TYPE the control is (v4l2_queryctrl.type field, and possibly enumerate over the different menu values if it is a menu), to decide how to best draw it in a GUI. The driver shoud be responsible for filling in the struct v4l2_queryctrl correctly with meaningful & sensible values, and provide a menu for controls that require one. Let me know if my understanding is flawed somewhere in here.
The V4L2 spec lists the Pan Reset and Tilt Reset as Booleans, which is already a bit better than Integer (what uvcvideo does so far), although I stick to my comment in my previous post: I really think these should be reported as Buttons for the obvious reason that resetting the pan or tilt is a one-shot action, not a continuous one which holds a value over time (this fits the definition of V4L2_CTRLTYPE_BUTTON in the specs). Using a button type makes it clear that trying to get its value is pointless, and it also makes sense when drawing this control on a GUI. I will bring this up on the V4L mailing list but I thought I d throw this one here first and see what people think. The V4L2 spec says the step value "gives the smallest change of an integer control actually affecting hardware". Calling ioctl(VIDIOC_G_CTRL) on the Pan or Tilt Relative control with a value of 1, as per reported step value, does not do anything. Both guvcview and luvcview get around that by defining a macro set to 64. Do applications really have to guess/do that, or can the driver simply report 64 as a step value ? The Pan/Tilt Reset control is a bit of a tricky one, because it is a collection of buttons (Pan reset, Tilt reset or both). Since we already have dedicated controls for both Pan Reset and Tilt Reset, is it a good idea change this one to "Pan & Tilt Reset" only, so it can be presented as a button ? If not, can this control have a menu explaining the different acceptable values ? Cheers, Gilles On Sun, Feb 8, 2009 at 11:28 PM, Paulo Assis <[email protected]> wrote: > Gilles, > Please have a look at guvcview code: http://guvcview.berlios.de > There is an implementation in a GTK GUI of these controls. > > Best regards > Paulo > > 2009/2/8 Gilles GIGAN <[email protected]>: > > Hi, > > I have checked out the latest v4l code from the mercurial repository on > > linuxtv.org, and successfully compiled and loaded the uvcvideo module, > which > > I tested with a logitech quickcam sphere af (046d:0994). I have comments > and > > questions regarding the V4L2 controls to pilot the pan and tilt motors: > > After mapping the dynamic controls (with uvcdynctrl), the following > controls > > become available: > > - Pan Reset: min: 0, max: 1, step: 1, type: integer > > - Tilt Reset: min 0, max: 1, step: 0, type: integer (note the step value > of > > 0 which should really be 1 here) > > - Pan (Relative): min: 4480, max: 4480, step: 1, type: integer > > - Tilt (Relative): min: 1920, max: 1920, step: 1, type: integer > > - Pan/tilt Reset: min: 0, max: 3, step: 1, type: integer > > Creating a user interface based on these controls is quite hard because > of > > their types and step values: > > Trying to set a value of 0 on any of the Reset controls fails, even > though 0 > > is reported as an acceptable value. > > Setting a value of 1 on either Pan (Relative) or Tilt (Relative) succeeds > > but results in no movement. > > Keeping the GUI up-to-date is not possible because calling > > ioctl(VIDIOC_G_CTRL) on any of these controls fails (which makes sense > when > > you know what the controls are). But from a programming point of view, if > > you try to create an interface that will work with any controls, the way > > these are reported (integers) makes it almost impossible to keep track > of. > > I have a couple of suggestions to improve this, and would appreciate > > comments on them: > > - Reporting the Pan/Tilt Reset control as a menu and Pan Reset and Tilt > > Reset as buttons instead of integers, will solve the previously mentioned > > issues. > > - Change the Pan (Relative) and Tilt (relative) step value to one that > > actually results in a slight movement of the camera. > > Is there a way to make these changes when mapping the controls, or do > they > > have to be coded in the driver itself ? > > Thanks > > Gilles > > > > > > _______________________________________________ > > Linux-uvc-devel mailing list > > [email protected] > > https://lists.berlios.de/mailman/listinfo/linux-uvc-devel > > > > > _______________________________________________ > Linux-uvc-devel mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/linux-uvc-devel >
_______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
