On Thu, 15 Jan 2009 18:41:33 +0100
Carsten Meier <c...@trexity.de> 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.
> 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.
> 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).
> What bus_info must be to make it of any use is that it must contain a
> string that won't change if the device reconnects (at least to the same
> port; manually or due to system-wakeup) A driver can do its best guess
> here (serial-no, slot or *constant* USB-port or whatever) I think this
> is the *only* V4L2-conforming solution to the problem.
For usb devices, usb_make_path() provide a canonical name for the device. For
PCI ones, we have pci_name() for the same function. in the case of pci devices,
I suspect that all use pci_name(). We just need to use usb_make_path() at the
usb ones.
Currently, only the IR part of most of the drivers use the usb canonical
name. It is trivial to convert the remaining ones to use it. It is just a matter
of replacing the string copy function to a usb_make_path() call.
Something like replacing:
strlcpy(cap->bus_info,pvr2_hdw_get_bus_info(hdw),
sizeof(cap->bus_info));
by:
usb_make_path(hdw->usb_dev, cap->bus_info, sizeof(cap->bus_info));
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
