Hi Richard, On Monday 14 April 2008, Richard Atterer wrote: > Hello, > > On Sun, Apr 13, 2008 at 11:25:38PM +0200, Laurent Pinchart wrote: > > On Saturday 12 April 2008, Richard Atterer wrote: > > > IMHO, the kernel driver could even provide the mapping 0x0000200e => > > > "Exposure, Auto Priority" without any maintenance problems. > > [...] > > > I'm not sure what you mean by a "mapping 0x0000200e => Exposure, Auto > > Priority". The driver can be queried to enumerate controls. For each of > > them it will return the control ID and name. This is part of the V4L2 > > API. > > I was thinking of additional, vendor-specific controls that are not part of > V4L2 (pan/tilt etc.) and how the driver makes them available. > > Basically, I'm not a fan of the concept of having a userspace tool set up > the mapping. From the experiences of the last months, I think it might be > less hassle to maintain extra controls in the driver. > > The userspace solution requires Linux distributions to ensure their > uvcdynctrl setups work with multiple kernel driver versions, and it also > means that if two different vendors implement e.g. pan/tilt differently, > the application will have to know about which IDs correspond to which > control - but the driver should abstract away from this and provide a > generic pan/tilt API.
The Linux UVC driver will map UVC controls to standard V4L2 controls when possible. As the UVC standard allows vendor-defined controls, the driver will sooner or later run into controls that have no corresponding V4L2 control ID. For those UVC controls the driver will have to use private V4L2 controls. Several vendor-defined UVC controls will be mapped to the same private V4L2 control when possible. Those mappings can either be hardcoded in the driver or provided by userspace tools. The first solution would be hard to maintain and would require frequent changes to the driver. This is why we went for the second solution. I'm sorry that recent versions of the driver had to break binary compatibility. This was unfortunately unavoidable, as V4L2 IDs for many controls were temporary and changed when we got them standardised in V4L2. This shouldn't happen anymore as those controls are now part of the V4L2 API. > Hmm, if it really *has* to be a userspace solution, the still-non-existent > generic v4l2 userspace library would be the place to set up the controls. > > :-/ > > In <http://lists.berlios.de/pipermail/linux-uvc-devel/2007-October/002257.html>, you wrote: > > Hardcoding all vendor-specific controls in the driver would soon become a > > maintenance nightmare. As most controls are quite simple, I decided to go > > for a userspace API that allows vendors to register new controls are > > runtime. > > This is what my "pleeease" was referring to - please change your mind, I > don't want to live with focus etc. controls on my Quickcam 9000 which break > at regular intervals! ;) They are not supposed to break at regular intervals :-) Binary incompatibilities are caused by the driver changing V4L2 control IDs combined with an application that hardcodes control IDs. The control mapping implementation (kernelspace vs. userspace) is irrelevant. To avoid breakages applications should avoid hardcoding private controls IDs when possible, and the control mapper should avoid changing control IDs for no reason. Now that the infrastructure is getting more stable there should be less binary compatibility issues. Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
