Am Fri, 16 Jan 2009 02:47:50 -0200 schrieb Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx>: > On Thu, 15 Jan 2009 18:41:33 +0100 > Carsten Meier <cm@xxxxxxxxxx> wrote: > > > > OK. Well, the usage he wants is something that is better fitted by > > > using sysfs info. There, you should have all information to > > > uniquely identify a device: driver, bus location (on PCI this can > > > be relevant), MAC (for dvb devices), etc. IMO, the proper way is > > > to add the serial number at sysfs, and let the bus_info point to > > > the proper bus location. Having the bus location, an userspace > > > app can seek the sysfs and look for the udev info. > > > > > > For example, on an em28xx analog device I have here, bus_info > > > returns "1-3". Ok, this is a very bad way to specify the bus. > > > IMO, we should use usb_make_path() to generate the canonical name > > > for USB buses. > > > > > > Anyway, by getting this information, and looking at sysfs, we'll > > > see lots of very useful information [1]. > > > > > > By parsing the info, we know that: > > > the v4l driver is em28xx; > > > the audio driver is snd-usb-audio (card1); > > > the event interface is input10; > > > this device uses two i2c modules: saa7115 and tuner; > > > the device has no dvb interface. > > > > > > It should be easy to extend it to provide more info, like the > > > serial number. This will also help udev to create a permanent > > > name for the known devices, as it does with internet interfaces. > > > > > > Cheers, > > > Mauro > > > > Hi, > > > > I'm the originator of this topic. > > > > Sorry, but I don't agree here. If I start to parse the bus_info > > string, my app will only work with device-drivers which return a > > canonical sysfs-path here. > > Since some devices currently doesn't provide an unique name at > bus_info, any solution will be applied on kernel 2.6.30 anyway. The > window for such changes on 2.6.29 were already closed. > > > To achive this, actually a new field in the > > capability-struct must be defined, > > Adding an extra string field for VIDIOC_QUERYCAP will break binary > only compatibility. This is not allowed. > No, it won't. There are reserved fields (16 bytes) at the end of the struct which can be used. To retain source-compatibility every app is advised to use a private copy of the header-file. > > because the specs don't put any > > contrains on the bus_info-string. (some space is left there) > > Any solution will need to review the specs. > Yes, but newer apps which are parsing bus_info then won't work with older kernels. This won't happen if a new field gets defined. > > And even if I parse the string to somehow obtain a sysfs-path, then > > I have to distinguish devices which have a serial-no and which > > don't. This leads to a unmaintainable situation. > > Almost all devices don't provide a readable serial number, or we > don't know how to obtain it. We just know the serial numbers on the > devices for one manufacturer (and a few other USB ones that provide a > serial number at the usb serial id field). > bus_info is *only* intended for users to distinguish multiple device instances. That's clearly stated by the specs. It was designed with PCI-cards in mind which always return the same location (PCI-slot). Applications usually then do a string comparision on card and bus_info to associate the device with its internal configuration or data structures. To make this mechanism work reliably with USB, the meaning of the field could be adapted to something like a binary identifier string. It is only required that this identifier won't change if the device is connected to the same port through the same hub. If the device has a unique serial-no., it is a perfect candidate for this string (then even the connection-path may change), otherwise some constant USB-info could be used. (This is what I meant by best guess above) This approach won't break anything (only a small addition to the docs for USB-devices is required, in that a constant identifier is required) Drivers which currently return an always changing bus_info break the v4l2-specs because they make it impossible for apps (and users) to distinguish devices reliably (which is required by v4l2). OK, just my 2 dollars :) Regards, Carsten -- 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
