Hi Gilles, On Monday 09 February 2009 01:20:15 Gilles GIGAN wrote: > 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.
Your understanding is correct. An application should be able to create a usable GUI from information retrieved from the driver. Now, if the application wants to make the GUI more userfriendly, or deal with some rare corner cases, I expected some controls will have to be handled in a non-generic way. This should remain an exception though. > 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), For the sake of correctness, the controls are reported as integers by the uvcvideo driver because they have been configured as such by the userspace uvcdynctrl utility based on the information provided by the logitech.xml configuration file. > 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. Agreed. > 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 ? As stated in my previous mail, the camera itself reports erroneous values :-/ > 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 ? The control should in my opinion be removed completely. Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
