On Wed, 14 Jan 2009, Mauro Carvalho Chehab wrote: [...] > > I can see some troubles here: > > 1) The bus info helps to identify the place where you'll find the > device info at sysfs; > > 2) This is a V4L2 API non-compliance. All drivers should be compliant > with the API; > > 3) If we all agree that bus_info doesn't matter at all and decide to > change V4L2 API, we'll still have a big trouble: most devices don't > have a serial number. > > The other patches are ok. I was asked to make this change, because otherwise there's no means via the V4L interface to uniquely REPEATABLY be able to identify the same device each time it is plugged in. I have gotten complaints about this. I actually pointed out that bus_info was about the "where" not the "what" of the device, but I was convinced to change this - after being surprised that the V4L spec allowed for this. Look at the online v4l spec; the following description exists about bus_info (as part of the VIDIOC_QUERYCAP description): "Location of the device in the system, a NUL-terminated ASCII string. For example: "PCI Slot 4". This information is intended for users, to distinguish multiple identical devices. If no such information is available the field may simply count the devices controlled by the driver, or contain the empty string (bus_info[0] = 0)." Based on that description, the actual format of the string depends a lot on the type of the device and that the only real requirement is that it distinguish among multiple devices. The changeset I posted above still fulfills those requirements. How can my change be a non-compliance given the above actual specification in the V4L2 spec? There's absolutely nothing there stating that the information must be usable to map a sysfs path. Surely the published V4L2 spec is the last word on this question... -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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
