| Message ID | 20090114142004.0833d61d@pedra.chehab.org (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
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
On Wed, 14 Jan 2009, Mike Isely wrote: > 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): > [...] Mauro: If you still don't like this specific changeset, then OK, but I'd still appreciate it if you could pull the other changes (especially the v4l2_subdev fix). And I'd appreciate some suggestions from anyone about a means via the V4L interface to make available a device-specific identifier, like a serial number. Yes I know such a thing is not always available with all devices, but it is available for Hauppauge devices in general and users want to have access to that information for purposes of mapping behavior in userspace. -Mike
On Wednesday 14 January 2009 17:44:38 Mike Isely wrote: > On Wed, 14 Jan 2009, Mike Isely wrote: > > 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): > > [...] > > Mauro: > > If you still don't like this specific changeset, then OK, but I'd > still appreciate it if you could pull the other changes (especially > the v4l2_subdev fix). Mauro, I agree with Mike on this: please pull at least the v4l2_subdev fix which must go asap to 2.6.29 as well. It's a very embarrassing bug that I introduced and that Mike found (thanks Mike!). Regards, Hans > And I'd appreciate some suggestions from anyone about a means via the > V4L interface to make available a device-specific identifier, like a > serial number. Yes I know such a thing is not always available with > all devices, but it is available for Hauppauge devices in general and > users want to have access to that information for purposes of mapping > behavior in userspace. > > -Mike
On Wednesday 14 January 2009 17:32:07 Mike Isely wrote: > 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. The serial number of the usb device should be available to udev through ATTRS{serial}. That's how we solved it for owners of multilpe HD PVRs. HTH Janne -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 14 Jan 2009 10:44:38 -0600 (CST) Mike Isely <isely@isely.net> wrote: > Mauro: > > If you still don't like this specific changeset, then OK, but I'd still > appreciate it if you could pull the other changes (especially the > v4l2_subdev fix). While discussing the serial number patch, I've picked the other ones. > On Wed, 14 Jan 2009, Mike Isely wrote: > > > 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): > > Interesting... Yet, IMO, we should be more strict about bus_info. This can be used as a way to associate a /dev/<device> with their sysfs entry. > And I'd appreciate some suggestions from anyone about a means via the > V4L interface to make available a device-specific identifier, like a > serial number. Yes I know such a thing is not always available with all > devices, but it is available for Hauppauge devices in general and users > want to have access to that information for purposes of mapping behavior > in userspace. Sorry, but I didn't understand the need. What do you want to map in userspace? Except for debugging purposes, or when the user has more than one device connected, I can't see any other usage for such identifier. For debug, you can just print the serial number. For device unique identification, there are the sysfs stuff, used by udev. Am I missing something? Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 15 Jan 2009, Mauro Carvalho Chehab wrote: > On Wed, 14 Jan 2009 10:44:38 -0600 (CST) > Mike Isely <isely@isely.net> wrote: [...] > > > And I'd appreciate some suggestions from anyone about a means via the > > V4L interface to make available a device-specific identifier, like a > > serial number. Yes I know such a thing is not always available with all > > devices, but it is available for Hauppauge devices in general and users > > want to have access to that information for purposes of mapping behavior > > in userspace. > > Sorry, but I didn't understand the need. What do you want to map in userspace? > Except for debugging purposes, or when the user has more than one device > connected, I can't see any other usage for such identifier. > > For debug, you can just print the serial number. For device unique > identification, there are the sysfs stuff, used by udev. > > Am I missing something? > Rather than paraphrase it all here, I invite you to look at the discussion thread on the pvrusb2 list where the topic came up: http://www.isely.net/pipermail/pvrusb2/2009-January/002091.html After looking over that discussion, let's talk about it. I think I know where you are heading with this, but I have other questions (if I'm right about where you're heading) and I'd like you to see that thread first. -Mike
On Wed, 14 Jan 2009 21:01:47 -0600 (CST) Mike Isely <isely@isely.net> wrote: > On Thu, 15 Jan 2009, Mauro Carvalho Chehab wrote: > > > On Wed, 14 Jan 2009 10:44:38 -0600 (CST) > > Mike Isely <isely@isely.net> wrote: > > [...] > > > > > > And I'd appreciate some suggestions from anyone about a means via the > > > V4L interface to make available a device-specific identifier, like a > > > serial number. Yes I know such a thing is not always available with all > > > devices, but it is available for Hauppauge devices in general and users > > > want to have access to that information for purposes of mapping behavior > > > in userspace. > > > > Sorry, but I didn't understand the need. What do you want to map in userspace? > > Except for debugging purposes, or when the user has more than one device > > connected, I can't see any other usage for such identifier. > > > > For debug, you can just print the serial number. For device unique > > identification, there are the sysfs stuff, used by udev. > > > > Am I missing something? > > > > Rather than paraphrase it all here, I invite you to look at the > discussion thread on the pvrusb2 list where the topic came up: > > http://www.isely.net/pipermail/pvrusb2/2009-January/002091.html > > After looking over that discussion, let's talk about it. I think I know > where you are heading with this, but I have other questions (if I'm > right about where you're heading) and I'd like you to see that thread > first. 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 [1] This is the info generated by em28xx driver: /sys/bus/usb/devices/1-3 |-- 1-3:1.0 | |-- bAlternateSetting | |-- bInterfaceClass | |-- bInterfaceNumber | |-- bInterfaceProtocol | |-- bInterfaceSubClass | |-- bNumEndpoints | |-- driver -> ../../../../../../bus/usb/drivers/em28xx | |-- ep_81 -> usb_endpoint/usbdev1.2_ep81 | |-- ep_82 -> usb_endpoint/usbdev1.2_ep82 | |-- ep_84 -> usb_endpoint/usbdev1.2_ep84 | |-- modalias | |-- power | | `-- wakeup | |-- subsystem -> ../../../../../../bus/usb | |-- uevent | `-- usb_endpoint | |-- usbdev1.2_ep81 | | |-- bEndpointAddress | | |-- bInterval | | |-- bLength | | |-- bmAttributes | | |-- dev | | |-- device -> ../../../1-3:1.0 | | |-- direction | | |-- interval | | |-- power | | | `-- wakeup | | |-- subsystem -> ../../../../../../../../class/usb_endpoint | | |-- type | | |-- uevent | | `-- wMaxPacketSize | |-- usbdev1.2_ep82 | | |-- bEndpointAddress | | |-- bInterval | | |-- bLength | | |-- bmAttributes | | |-- dev | | |-- device -> ../../../1-3:1.0 | | |-- direction | | |-- interval | | |-- power | | | `-- wakeup | | |-- subsystem -> ../../../../../../../../class/usb_endpoint | | |-- type | | |-- uevent | | `-- wMaxPacketSize | `-- usbdev1.2_ep84 | |-- bEndpointAddress | |-- bInterval | |-- bLength | |-- bmAttributes | |-- dev | |-- device -> ../../../1-3:1.0 | |-- direction | |-- interval | |-- power | | `-- wakeup | |-- subsystem -> ../../../../../../../../class/usb_endpoint | |-- type | |-- uevent | `-- wMaxPacketSize |-- 1-3:1.1 | |-- bAlternateSetting | |-- bInterfaceClass | |-- bInterfaceNumber | |-- bInterfaceProtocol | |-- bInterfaceSubClass | |-- bNumEndpoints | |-- driver -> ../../../../../../bus/usb/drivers/snd-usb-audio | |-- modalias | |-- power | | `-- wakeup | |-- sound | | `-- card1 | | |-- audio1 | | | |-- dev | | | |-- device -> ../../card1 | | | |-- power | | | | `-- wakeup | | | |-- subsystem -> ../../../../../../../../../class/sound | | | `-- uevent | | |-- controlC1 | | | |-- dev | | | |-- device -> ../../card1 | | | |-- power | | | | `-- wakeup | | | |-- subsystem -> ../../../../../../../../../class/sound | | | `-- uevent | | |-- device -> ../../../1-3:1.1 | | |-- dsp1 | | | |-- dev | | | |-- device -> ../../card1 | | | |-- power | | | | `-- wakeup | | | |-- subsystem -> ../../../../../../../../../class/sound | | | `-- uevent | | |-- mixer1 | | | |-- dev | | | |-- device -> ../../card1 | | | |-- power | | | | `-- wakeup | | | |-- subsystem -> ../../../../../../../../../class/sound | | | `-- uevent | | |-- pcmC1D0c | | | |-- dev | | | |-- device -> ../../card1 | | | |-- pcm_class | | | |-- power | | | | `-- wakeup | | | |-- subsystem -> ../../../../../../../../../class/sound | | | `-- uevent | | |-- power | | | `-- wakeup | | |-- subsystem -> ../../../../../../../../class/sound | | `-- uevent | |-- subsystem -> ../../../../../../bus/usb | `-- uevent |-- 1-3:1.2 | |-- bAlternateSetting | |-- bInterfaceClass | |-- bInterfaceNumber | |-- bInterfaceProtocol | |-- bInterfaceSubClass | |-- bNumEndpoints | |-- driver -> ../../../../../../bus/usb/drivers/snd-usb-audio | |-- ep_83 -> usb_endpoint/usbdev1.2_ep83 | |-- modalias | |-- power | | `-- wakeup | |-- subsystem -> ../../../../../../bus/usb | |-- uevent | `-- usb_endpoint | `-- usbdev1.2_ep83 | |-- bEndpointAddress | |-- bInterval | |-- bLength | |-- bmAttributes | |-- dev | |-- device -> ../../../1-3:1.2 | |-- direction | |-- interval | |-- power | | `-- wakeup | |-- subsystem -> ../../../../../../../../class/usb_endpoint | |-- type | |-- uevent | `-- wMaxPacketSize |-- authorized |-- bConfigurationValue |-- bDeviceClass |-- bDeviceProtocol |-- bDeviceSubClass |-- bMaxPacketSize0 |-- bMaxPower |-- bNumConfigurations |-- bNumInterfaces |-- bcdDevice |-- bmAttributes |-- busnum |-- configuration |-- descriptors |-- dev |-- devnum |-- driver -> ../../../../../bus/usb/drivers/usb |-- ep_00 -> usb_endpoint/usbdev1.2_ep00 |-- i2c-adapter | `-- i2c-1 | |-- 1-0025 | | |-- driver -> ../../../../../../../../bus/i2c/drivers/saa7115' | | |-- modalias | | |-- name | | |-- power | | | `-- wakeup | | |-- subsystem -> ../../../../../../../../bus/i2c | | `-- uevent | |-- 1-0063 | | |-- driver -> ../../../../../../../../bus/i2c/drivers/tuner' | | |-- modalias | | |-- name | | |-- power | | | `-- wakeup | | |-- subsystem -> ../../../../../../../../bus/i2c | | `-- uevent | |-- device -> ../../../1-3 | |-- name | |-- power | | `-- wakeup | |-- subsystem -> ../../../../../../../class/i2c-adapter | `-- uevent |-- idProduct |-- idVendor |-- input | `-- input10 | |-- capabilities | | |-- abs | | |-- ev | | |-- ff | | |-- key | | |-- led | | |-- msc | | |-- rel | | |-- snd | | `-- sw | |-- device -> ../../../1-3 | |-- event10 | | |-- dev | | |-- device -> ../../input10 | | |-- power | | | `-- wakeup | | |-- subsystem -> ../../../../../../../../class/input | | `-- uevent | |-- id | | |-- bustype | | |-- product | | |-- vendor | | `-- version | |-- modalias | |-- name | |-- phys | |-- power | | `-- wakeup | |-- subsystem -> ../../../../../../../class/input | |-- uevent | `-- uniq |-- maxchild |-- power | |-- active_duration | |-- autosuspend | |-- connected_duration | |-- level | |-- persist | `-- wakeup |-- product |-- quirks |-- speed |-- subsystem -> ../../../../../bus/usb |-- uevent |-- urbnum |-- usb_endpoint | `-- usbdev1.2_ep00 | |-- bEndpointAddress | |-- bInterval | |-- bLength | |-- bmAttributes | |-- dev | |-- device -> ../../../1-3 | |-- direction | |-- interval | |-- power | | `-- wakeup | |-- subsystem -> ../../../../../../../class/usb_endpoint | |-- type | |-- uevent | `-- wMaxPacketSize |-- version `-- video4linux |-- vbi0 | |-- dev | |-- device -> ../../../1-3 | |-- index | |-- name | |-- power | | `-- wakeup | |-- subsystem -> ../../../../../../../class/video4linux | `-- uevent `-- video0 |-- dev |-- device -> ../../../1-3 |-- index |-- name |-- power | `-- wakeup |-- subsystem -> ../../../../../../../class/video4linux `-- uevent 101 directories, 174 files Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 15 Jan 2009, Mauro Carvalho Chehab 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. I will review what the pvrusb2 driver is doing and change it to use usb_make_path() if needed. However given all the other information about the device that querycap returns, a serial number in that batch would be right at home there. Requiring an app to go through everything you described is a pretty complex process for what should be very simple datum. In any case, right now the serial number in the pvrusb2 is not available through that means because I haven't done anything to make it available to udev. I'd like to do something, but so far I have found no information on how to make that happen. -Mike
On Friday 16 January 2009 15:39:33 Mike Isely wrote: > In any case, right now the serial number in the pvrusb2 is not available > through that means because I haven't done anything to make it available > to udev. Â I'd like to do something, but so far I have found no > information on how to make that happen. You shouldn't need to do anything special. The serial number is available through the parent USB device. It can be used for udev rules through ATTRS{serial} and in sysfs entry of the video device through device/serial. Janne -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 16 Jan 2009, Janne Grunau wrote: > On Friday 16 January 2009 15:39:33 Mike Isely wrote: > > In any case, right now the serial number in the pvrusb2 is not available > > through that means because I haven't done anything to make it available > > to udev. Â I'd like to do something, but so far I have found no > > information on how to make that happen. > > You shouldn't need to do anything special. The serial number is available > through the parent USB device. It can be used for udev rules through > ATTRS{serial} and in sysfs entry of the video device through device/serial. > Ah yes! What I said before was right in its own context, but now I see something else. The serial number that the pvrusb2 driver itself knows about is parsed out of Hauppauge private data by the tveeprom module from the device's internal I2C ROM. This data is formatted in a packetized way that is specific to Hauppauge. What I was refering to was *that* serial number, and since it's in the private ROM I saw no means for udev to know about it. However I just tested with two 24xxx devices using usbview, and the same serial number is in fact visible in the USB configuration data. There's simply no way for the USB core in Linux to be able to directly know about, get at, or even understand that internal ROM. Yet there it is. I'm thinking now that perhaps the FX2 microcontroller is either parsing out the data itself during initialization and then writing out the USB configuration accordingly, or the serial number is in fact written in two places within the device! Up until now, I had not seen any evidence to suggest that the FX2 firmware ever actually read the nearby ROM on its own. But that could be what is happening here. Thanks for pointing that out. These devices still surprise me. For anyone looking at this, the serial number in the USB configuration data for the device is just a hex-formatted version of the same value that you can see via the pvrusb2 driver's sysfs interface. -Mike
--- a/linux/drivers/media/video/pvrusb2/pvrusb2-v4l2.c Wed Jan 14 01:24:20 2009 -0600 +++ b/linux/drivers/media/video/pvrusb2/pvrusb2-v4l2.c Wed Jan 14 01:30:53 2009 -0600 @@ -205,7 +205,7 @@ static long pvr2_v4l2_do_ioctl(struct fi struct v4l2_capability *cap = arg; memcpy(cap, &pvr_capability, sizeof(struct v4l2_capability)); - strlcpy(cap->bus_info,pvr2_hdw_get_bus_info(hdw), + strlcpy(cap->bus_info, pvr2_hdw_get_device_identifier(hdw), sizeof(cap->bus_info)); strlcpy(cap->card,pvr2_hdw_get_desc(hdw),sizeof(cap->card));