Gilles, 2009/2/9 Gilles GIGAN <[email protected]>: > 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 ? >
You are absolutely right on every point, except for one thing: Pan/Tilt controls are extension controls, the driver just loads the values passed by applications, in this case logitech defines these has integers, unless the hardware accepts them as buttons or menu values then there is not much it can be done, I think. The good (maybe bad) thing is that so far only logitech cameras seem to support these extension controls, so not much code changes have been needed until now). PS: since today (10 minutes ago) svn head version of guvcview also allows for a control only window (just committed the changes), I've tested controlling the image in cheese and ekiga and it worked great, just start with: guvcview --control_only Best regards, Paulo _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
