How to identify USB-video-devices

Hello list,

we recently had a discussion on the pvrusb2-list on how to identify a video-device connected via USB from an userspace app. (Or more precisely on how to associate config-data with a particular device). This led to a patch which returned the device's serial-no. in v4l2_capability's bus_info field. This one has been rejected, but I really feel that this is the right way to go. Here's the thread:
http://www.isely.net/pipermail/pvrusb2/2009-January/002091.html

I think the meaning of the bus_info-field should be modified slightly for USB-devices to reflect its dynamic nature. At least a string that won't change on dis-/reconnect and standby/wake-up-cycles should be returned. If a device has a unique serial-no. it is a perfect candidate for this, if not, some USB-port-info should be returned that won't change if the device is connected to the same port through the same hub.

What do you think?
(BTW: I'm not a kernel-hacker, I'm writing this from the perspective of an app-developer)

Quoted 19 lines

Hello list,

we recently had a discussion on the pvrusb2-list on how to identify a video-device connected via USB from an userspace app. (Or more precisely on how to associate config-data with a particular device). This led to a patch which returned the device's serial-no. in v4l2_capability's bus_info field. This one has been rejected, but I really feel that this is the right way to go. Here's the thread:
http://www.isely.net/pipermail/pvrusb2/2009-January/002091.html

I think the meaning of the bus_info-field should be modified slightly for USB-devices to reflect its dynamic nature. At least a string that won't change on dis-/reconnect and standby/wake-up-cycles should be returned. If a device has a unique serial-no. it is a perfect candidate for this, if not, some USB-port-info should be returned that won't change if the device is connected to the same port through the same hub.

Quoted 4 lines

What do you think?
(BTW: I'm not a kernel-hacker, I'm writing this from the perspective of an app-developer)

write a few shellscripts and parse sysfs, or attach your application to sysfs that it will
be notified if a device gets added. dbus is also a tip. no need to hook up drivers
with some special things there.

regards,
Markus

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Carsten Meier Sent: 15 janvier 2009 10:34 To: Markus Rechberger
Cc: [email protected]
Subject: Re: How to identify USB-video-devices

Am Thu, 15 Jan 2009 16:20:23 +0100
schrieb "Markus Rechberger" <[email protected]>:

Quoted 26 lines

Quoted 19 lines · Carsten Meier

Hello list,

we recently had a discussion on the pvrusb2-list on how to identify a video-device connected via USB from an userspace app. (Or more precisely on how to associate config-data with a particular device). This led to a patch which returned the device's serial-no. in v4l2_capability's bus_info field. This one has been rejected, but I really feel that this is the right way to go. Here's the thread:
http://www.isely.net/pipermail/pvrusb2/2009-January/002091.html

I think the meaning of the bus_info-field should be modified slightly for USB-devices to reflect its dynamic nature. At least a string that won't change on dis-/reconnect and standby/wake-up-cycles should be returned. If a device has a unique serial-no. it is a perfect candidate for this, if not, some USB-port-info should be returned that won't change if the device is connected to the same port through the same hub.

Quoted 4 lines

What do you think?
(BTW: I'm not a kernel-hacker, I'm writing this from the perspective of an app-developer)

Quoted 8 lines

write a few shellscripts and parse sysfs, or attach your application to sysfs that it will
be notified if a device gets added. dbus is also a tip. no need to hook up drivers
with some special things there.

regards,
Markus

But according to the docs, the bus_info-field is intended for the purpose of identifying particular devices. Other solutions may be possible, but they are much more complex and much more sensible to other kernel-changes. By using bus_info, there is a simple and clean solution that only depends on the V4L2-API and it also reflects the primary intention of the field.

Other USB-device-drivers aren't required to change to the new policy, their current bus_info-string (if implemented like in pvrusb2) changes on every reconnect and standby/wake-up-cycle and is of no use anyway for any app.

I really think that current behaviour is broken.

Regards,
Carsten

I think that generic devices (often cheapest price) do not identify themselves exactly as well known trademarks.

So you can identify kind of chip they use (empia 2860) but, the eeprom space usb chips identity have, remain the responsibility/regardless to the company who build the entire video usb board and not the empia or otherelse chip you ask information on.

You can identify the vendor (2 letters id)so, in this situation, contact the vendor/company to get more precision about.

Try lsusb in terminal.

Hope this reply is usefull. Best regards, cheers

Storing device-file-names is also not an option because they are created dynamicly.

Quoted 2 lines · Carsten Meier

Storing device-file-names is also not an option because they are created dynamicly.

You use udev rules to give persistent names.

Here is my /etc/udev/rules.d/video.rules file, which creates /dev/webcam and /dev/tvtuner as appropriate.

KERNEL=="video*" SYSFS{name}=="USB2.0 Camera", NAME="video%n", SYMLINK+="webcam" KERNEL=="video*" SYSFS{name}=="em28xx*", NAME="video%n", SYMLINK+="tvtuner"

To find distinguishing attributes to match on use:

echo /sys/class/video4linux/video* | xargs -n1 udevinfo -a -p

Quoted 2 lines · Carsten Meier

Storing device-file-names is also not an option because they are created dynamicly.

You use udev rules to give persistent names.

Here is my /etc/udev/rules.d/video.rules file, which creates /dev/webcam and /dev/tvtuner as appropriate.

KERNEL=="video*" SYSFS{name}=="USB2.0 Camera", NAME="video%n", SYMLINK+="webcam" KERNEL=="video*" SYSFS{name}=="em28xx*", NAME="video%n", SYMLINK+="tvtuner"

To find distinguishing attributes to match on use:

echo /sys/class/video4linux/video* | xargs -n1 udevinfo -a -p

cheers,
Pádraig.

Am Thu, 15 Jan 2009 22:22:11 +0000
schrieb Pádraig Brady <[email protected]>:

Quoted 13 lines

Quoted 2 lines · Carsten Meier

Storing device-file-names is also not an option because they are created dynamicly.

You use udev rules to give persistent names.

Here is my /etc/udev/rules.d/video.rules file, which creates /dev/webcam and /dev/tvtuner as appropriate.

KERNEL=="video*" SYSFS{name}=="USB2.0 Camera", NAME="video%n", SYMLINK+="webcam" KERNEL=="video*" SYSFS{name}=="em28xx*", NAME="video%n", SYMLINK+="tvtuner"

Quoted 6 lines

To find distinguishing attributes to match on use:

echo /sys/class/video4linux/video* | xargs -n1 udevinfo -a -p

cheers,
Pádraig.

This already came up on the pvrusb2-list and someone told me (I don't know much about udev) that it might cause problems on disconnection of a device with a file-descriptor open which then gets reconnected and there are two device-files for it. I also don't like it, because an average user (including me) usually can't or don't want to write udev rules. Finally v4l2 already contains a very simple and reliable mechanism for doing this (bus_info-field) which simply isn't used correctly by the USB-drivers.

My app should simply scan for /dev/video*-files, read out capabilities from them, present the user menus to select devices and edit device settings, save settings to a file and apply them on demand. This would work fine if bus_info was filled right, without root-privileges, without special udev rules or other sysfs-magic.

Regards,
Carsten

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Quoted 23 lines

Am Thu, 15 Jan 2009 22:22:11 +0000
schrieb Pádraig Brady <[email protected]>:

Quoted 13 lines

Quoted 2 lines · Carsten Meier

Storing device-file-names is also not an option because they are created dynamicly.

You use udev rules to give persistent names.

Here is my /etc/udev/rules.d/video.rules file, which creates /dev/webcam and /dev/tvtuner as appropriate.

KERNEL=="video*" SYSFS{name}=="USB2.0 Camera", NAME="video%n", SYMLINK+="webcam" KERNEL=="video*" SYSFS{name}=="em28xx*", NAME="video%n", SYMLINK+="tvtuner"

Quoted 6 lines

To find distinguishing attributes to match on use:

echo /sys/class/video4linux/video* | xargs -n1 udevinfo -a -p

cheers,
Pádraig.

Quoted 9 lines

This already came up on the pvrusb2-list and someone told me (I don't know much about udev) that it might cause problems on disconnection of a device with a file-descriptor open which then gets reconnected and there are two device-files for it. I also don't like it, because an average user (including me) usually can't or don't want to write udev rules. Finally v4l2 already contains a very simple and reliable mechanism for doing this (bus_info-field) which simply isn't used correctly by the USB-drivers.

check the device serial for this one. I don't know if the pvrusb2 devices have it set up properly
I know some manufacturers don't do!
Be flexible with the node, but not with the serial.

cat /sys/class/video4linux/video0/device/serial
080702001788

you have the nodename in it, there are many ways to retrieve the nodename.

Quoted 10 lines

My app should simply scan for /dev/video*-files, read out capabilities from them, present the user menus to select devices and edit device settings, save settings to a file and apply them on demand. This would work fine if bus_info was filled right, without root-privileges, without special udev rules or other sysfs-magic.

Regards,
Carsten

Quoted 6 lines

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Am Fri, 16 Jan 2009 00:40:47 +0100
schrieb "Markus Rechberger" <[email protected]>:

Quoted 39 lines · Carsten Meier

Quoted 23 lines

Am Thu, 15 Jan 2009 22:22:11 +0000
schrieb Pádraig Brady <[email protected]>:

Quoted 13 lines

Quoted 2 lines · Carsten Meier

Storing device-file-names is also not an option because they are created dynamicly.

You use udev rules to give persistent names.

Here is my /etc/udev/rules.d/video.rules file, which creates /dev/webcam and /dev/tvtuner as appropriate.

KERNEL=="video*" SYSFS{name}=="USB2.0 Camera", NAME="video%n", SYMLINK+="webcam" KERNEL=="video*" SYSFS{name}=="em28xx*", NAME="video%n", SYMLINK+="tvtuner"

Quoted 6 lines

To find distinguishing attributes to match on use:

echo /sys/class/video4linux/video* | xargs -n1 udevinfo -a -p

cheers,
Pádraig.

Quoted 9 lines

This already came up on the pvrusb2-list and someone told me (I don't know much about udev) that it might cause problems on disconnection of a device with a file-descriptor open which then gets reconnected and there are two device-files for it. I also don't like it, because an average user (including me) usually can't or don't want to write udev rules. Finally v4l2 already contains a very simple and reliable mechanism for doing this (bus_info-field) which simply isn't used correctly by the USB-drivers.

check the device serial for this one. I don't know if the pvrusb2 devices have it set up properly
I know some manufacturers don't do!
Be flexible with the node, but not with the serial.

Quoted 5 lines

cat /sys/class/video4linux/video0/device/serial
080702001788

you have the nodename in it, there are many ways to retrieve the nodename.

If I do a "ls /sys/class/video4linux/video0/" it simply prints:

dev index name power subsystem uevent

and it will end up with many differnet cases to consider by any app. I stay at my opinion that current bus_info-impl is broken. This *is* a driver issue that needs fixing.

Quoted 50 lines

Am Fri, 16 Jan 2009 00:40:47 +0100
schrieb "Markus Rechberger" <[email protected]>:

Quoted 41 lines

Quoted 23 lines · Carsten Meier

Am Thu, 15 Jan 2009 22:22:11 +0000
schrieb Pádraig Brady <[email protected]>:

Quoted 13 lines

Quoted 2 lines · Carsten Meier

Storing device-file-names is also not an option because they are created dynamicly.

You use udev rules to give persistent names.

Here is my /etc/udev/rules.d/video.rules file, which creates /dev/webcam and /dev/tvtuner as appropriate.

KERNEL=="video*" SYSFS{name}=="USB2.0 Camera", NAME="video%n", SYMLINK+="webcam" KERNEL=="video*" SYSFS{name}=="em28xx*", NAME="video%n", SYMLINK+="tvtuner"

Quoted 6 lines

To find distinguishing attributes to match on use:

echo /sys/class/video4linux/video* | xargs -n1 udevinfo -a -p

cheers,
Pádraig.

Quoted 10 lines

This already came up on the pvrusb2-list and someone told me (I don't know much about udev) that it might cause problems on disconnection of a device with a file-descriptor open which then gets reconnected and there are two device-files for it. I also don't like it, because an average user (including me) usually can't or don't want to write udev rules. Finally v4l2 already contains a very simple and reliable mechanism for doing this (bus_info-field) which simply isn't used correctly by the USB-drivers.

check the device serial for this one. I don't know if the pvrusb2 devices have it set up properly
I know some manufacturers don't do!
Be flexible with the node, but not with the serial.

Quoted 5 lines

cat /sys/class/video4linux/video0/device/serial
080702001788

you have the nodename in it, there are many ways to retrieve the nodename.

Quoted 8 lines

If I do a "ls /sys/class/video4linux/video0/" it simply prints:

dev index name power subsystem uevent

and it will end up with many differnet cases to consider by any app. I stay at my opinion that current bus_info-impl is broken. This *is* a driver issue that needs fixing.

could it be that video0 is no usb device - or something else? The usb-core framework should give you the information about the serial id not the driver.

$ ls /sys/bus/usb/devices/*/id* /sys/bus/usb/devices/*/serial | while
read a; do cat $a; done
0c15 <- product
04fc <- vendor
00000CFD49 <- usb serial id
008e
0ccd
080702001788
6377
058f
920321111113
0000 <- nothing attached here
0000
0000:00:02.0
0000
0000
0000:00:02.1

$ lsusb
Bus 002 Device 008: ID 0ccd:008e TerraTec Electronic GmbH
Bus 002 Device 003: ID 058f:6377 Alcor Micro Corp.
Bus 002 Device 002: ID 04fc:0c15 Sunplus Technology Co., Ltd
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

I use kernel 2.6.24.21 here; but the sysfs entries have been available for quite some time already.

Markus

Am Fri, 16 Jan 2009 01:59:51 +0100
schrieb "Markus Rechberger" <[email protected]>:

Quoted 92 lines · Carsten Meier

Quoted 50 lines

Am Fri, 16 Jan 2009 00:40:47 +0100
schrieb "Markus Rechberger" <[email protected]>:

Quoted 41 lines

Quoted 23 lines · Carsten Meier

Am Thu, 15 Jan 2009 22:22:11 +0000
schrieb Pádraig Brady <[email protected]>:

Quoted 13 lines

Quoted 2 lines · Carsten Meier

Storing device-file-names is also not an option because they are created dynamicly.

You use udev rules to give persistent names.

Here is my /etc/udev/rules.d/video.rules file, which creates /dev/webcam and /dev/tvtuner as appropriate.

KERNEL=="video*" SYSFS{name}=="USB2.0 Camera", NAME="video%n", SYMLINK+="webcam" KERNEL=="video*" SYSFS{name}=="em28xx*", NAME="video%n", SYMLINK+="tvtuner"

Quoted 6 lines

To find distinguishing attributes to match on use:

echo /sys/class/video4linux/video* | xargs -n1 udevinfo -a -p

cheers,
Pádraig.

Quoted 10 lines

This already came up on the pvrusb2-list and someone told me (I don't know much about udev) that it might cause problems on disconnection of a device with a file-descriptor open which then gets reconnected and there are two device-files for it. I also don't like it, because an average user (including me) usually can't or don't want to write udev rules. Finally v4l2 already contains a very simple and reliable mechanism for doing this (bus_info-field) which simply isn't used correctly by the USB-drivers.

check the device serial for this one. I don't know if the pvrusb2 devices have it set up properly
I know some manufacturers don't do!
Be flexible with the node, but not with the serial.

Quoted 5 lines

cat /sys/class/video4linux/video0/device/serial
080702001788

you have the nodename in it, there are many ways to retrieve the nodename.

Quoted 8 lines

If I do a "ls /sys/class/video4linux/video0/" it simply prints:

dev index name power subsystem uevent

and it will end up with many differnet cases to consider by any app. I stay at my opinion that current bus_info-impl is broken. This *is* a driver issue that needs fixing.

could it be that video0 is no usb device - or something else? The usb-core framework should give you the information about the serial id not the driver.

$ ls /sys/bus/usb/devices/*/id* /sys/bus/usb/devices/*/serial | while
read a; do cat $a; done
0c15 <- product
04fc <- vendor
00000CFD49 <- usb serial id
008e
0ccd
080702001788
6377
058f
920321111113
0000 <- nothing attached here
0000
0000:00:02.0
0000
0000
0000:00:02.1

$ lsusb
Bus 002 Device 008: ID 0ccd:008e TerraTec Electronic GmbH
Bus 002 Device 003: ID 058f:6377 Alcor Micro Corp.
Bus 002 Device 002: ID 04fc:0c15 Sunplus Technology Co., Ltd
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

I use kernel 2.6.24.21 here; but the sysfs entries have been available for quite some time already.

Quoted 1 line

Markus

Yes, it is a pvr-usb-device with an mpeg-encoder which resides under /sys/class/pvrusb2/. And exactly this difference shows that it should be solved by the driver's bus_info-string and not by programming this logic into an app.

OK, I'm done for today. I'm arguing this for two full days now. :(

Quoted 3 lines · Carsten Meier

Am Fri, 16 Jan 2009 01:59:51 +0100
schrieb "Markus Rechberger" <[email protected]>:

Quoted 40 lines

Quoted 30 lines

could it be that video0 is no usb device - or something else? The usb-core framework should give you the information about the serial id not the driver.

$ ls /sys/bus/usb/devices/*/id* /sys/bus/usb/devices/*/serial | while
read a; do cat $a; done
0c15 <- product
04fc <- vendor
00000CFD49 <- usb serial id
008e
0ccd
080702001788
6377
058f
920321111113
0000 <- nothing attached here
0000
0000:00:02.0
0000
0000
0000:00:02.1

$ lsusb
Bus 002 Device 008: ID 0ccd:008e TerraTec Electronic GmbH
Bus 002 Device 003: ID 058f:6377 Alcor Micro Corp.
Bus 002 Device 002: ID 04fc:0c15 Sunplus Technology Co., Ltd
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

Quoted 4 lines

I use kernel 2.6.24.21 here; but the sysfs entries have been available for quite some time already.

Markus

Yes, it is a pvr-usb-device with an mpeg-encoder which resides under /sys/class/pvrusb2/. And exactly this difference shows that it should be solved by the driver's bus_info-string and not by programming this logic into an app.

Quoted 2 lines

OK, I'm done for today. I'm arguing this for two full days now. :(

I understand, it should be fixed in the driver yes.