Keymap for TeVii S650's remote control
Hi,
I've created a keymap for the remote control that ships with the TeVii
S650. It is just a hack, I simply replaced the previous keymap in
linux/drivers/media/dvb/dvb-usb/dw2102.c (line 527)
Here's the code:
static struct dvb_usb_rc_key dw210x_rc_keys[] = {
{ 0xf8, 0x00, KEY_UP },
{ 0xf8, 0x01, KEY_DOWN },
{ 0xf8, 0x02, KEY_RIGHT },
{ 0xf8, 0x03, KEY_LEFT },
{ 0xf8, 0x04, KEY_RECORD },
/* { 0xf8, 0x05, KEY_ }, live-mode */
{ 0xf8, 0x06, KEY_CHANNELDOWN },
/* { 0xf8, 0x07, KEY_ }, play-mode */
{ 0xf8, 0x08, KEY_CHANNELUP },
{ 0xf8, 0x09, KEY_VOLUMEUP },
{ 0xf8, 0x0a, KEY_POWER2 },
/* { 0xf8, 0x0b, KEY_ }, timer */
{ 0xf8, 0x0c, KEY_MUTE },
{ 0xf8, 0x0e, KEY_OPEN },
{ 0xf8, 0x0f, KEY_VOLUMEDOWN },
{ 0xf8, 0x10, KEY_KP0 },
{ 0xf8, 0x11, KEY_KP1 },
{ 0xf8, 0x12, KEY_KP2 },
{ 0xf8, 0x13, KEY_KP3 },
{ 0xf8, 0x14, KEY_KP4 },
{ 0xf8, 0x15, KEY_KP5 },
{ 0xf8, 0x16, KEY_KP6 },
{ 0xf8, 0x17, KEY_KP7 },
{ 0xf8, 0x18, KEY_KP8 },
{ 0xf8, 0x19, KEY_KP9 },
{ 0xf8, 0x1a, KEY_LAST }, /* recall / event info */
{ 0xf8, 0x1b, KEY_FAVORITES }, /* fav /cur/next */
{ 0xf8, 0x1c, KEY_MENU },
{ 0xf8, 0x1d, KEY_BACK },
{ 0xf8, 0x1e, KEY_REWIND },
{ 0xf8, 0x1f, KEY_OK },
{ 0xf8, 0x40, KEY_PLAYPAUSE },
{ 0xf8, 0x41, KEY_AB },
{ 0xf8, 0x43, KEY_AUDIO },
{ 0xf8, 0x44, KEY_EPG },
{ 0xf8, 0x45, KEY_SUBTITLE },
{ 0xf8, 0x46, KEY_F1 }, /* F1 / satellite */
{ 0xf8, 0x48, KEY_F2 }, /* F2 / provider */
{ 0xf8, 0x4a, KEY_LIST },
{ 0xf8, 0x4c, KEY_INFO },
{ 0xf8, 0x4d, KEY_FASTFORWARD },
{ 0xf8, 0x52, KEY_F5 }, /* F5 / all */
/* { 0xf8, 0x56, KEY_ }, mon */
/* { 0xf8, 0x58, KEY_ }, FS */
{ 0xf8, 0x5a, KEY_F6 },
{ 0xf8, 0x5c, KEY_F4 }, /* F4 / favorites */
{ 0xf8, 0x5e, KEY_F3 } /* F3 / transp */
};
For the commented-out keys, I haven't found a matching kernel-constant.
It would be nice if somebody could integrate this into the v4l-dvb-tree.
(Don't ask me to do it, I have no clue how to do it without breaking
the other devices that depend on the old keymap)
Cheers,
Carsten
--
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
Where to get dvb-usb-dw2104.fw for TeVii S650
Hello list, where do I get the dvb-usb-dw2104.fw firmware-file for my TeVii S650? The driver-package downloadble from the manufacturer website ( http://tevii.com/support.html ) only contains dvb-fe-cx24116.fw, dvb-usb-s600.fw, and dvb-usb-s600.fw. The manufacturers driver is multiproto-based which is not what I want. The method described here: http://article.gmane.org/gmane.linux.drivers.dvb/44694 to get the firmware doesn't work anymore, the file has been removed. Any hints? Thanks in advance, Carsten -- 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
Re: Where to get dvb-usb-dw2104.fw for TeVii S650
Am Wed, 1 Apr 2009 14:01:16 +0200 schrieb Carsten Meier c...@trexity.de: Hello list, where do I get the dvb-usb-dw2104.fw firmware-file for my TeVii S650? The driver-package downloadble from the manufacturer website ( http://tevii.com/support.html ) only contains dvb-fe-cx24116.fw, dvb-usb-s600.fw, and dvb-usb-s600.fw. The manufacturers driver is multiproto-based which is not what I want. The method described here: http://article.gmane.org/gmane.linux.drivers.dvb/44694 to get the firmware doesn't work anymore, the file has been removed. Any hints? Thanks in advance, Carsten -- 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 I actually meant: The driver-package downloadble from the manufacturer website ( http://tevii.com/support.html ) only contains dvb-fe-cx24116.fw, dvb-usb-s600.fw, and dvb-usb-s650.fw (650 not 600) I've found this thread: http://www.allrussian.info/thread.php?postid=1460227 Because I cannot speak any russian, I've auto-translated it with google. Am I right that it suggests to simply rename dvb-usb-s650.fw from the manufacturer to dvb-usb-dw2104.fw? Thanks, Carsten -- 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
Re: Sometimes no lock on digivox miniII (Ver3.0)
Am Mon, 16 Feb 2009 21:54:40 -0600 (CST) schrieb kilg...@banach.math.auburn.edu: On Tue, 17 Feb 2009, Andreas Witte wrote: Hello List, after changing my system to newer hardware (and use the latest driver for af9015), it seems the device didnt get a lock sometimes (mostly in the case the system is started up). I use the stick together with mythtv. If i get the partial lock, i restart mythbackend or switch channel - then i get the lock. If i get it just the first time the stick is working fine for the whole day. Only the very first channelpick after system start seems to be the problem. I cant reproduce this at all. Sometimes it works, sometimes not. Anybody else seeing this? Im on gentoo with 2.6.28 kernel. Any Ideas? Regards, Andreas -- 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 I don't know anything about the af9015, what kind of device it is, what it is supposed to do, or who wrote the code, except that I just grepped the code for af9015, found it, and it is a USB device. So I am an outside observer. Here is my suspicion of what is wrong: There was a rather nasty USB bug in 2.6.28 (no suffixes). It hit a lot of USB device drivers. The problem showed itself, pretty much, as you describe. I experienced it, too, with a couple of Gphoto camera drivers that I wrote which had been working ust fine for years and worked again just fine when I patched the kernel. So by extrapolation there is quite likely nothing wrong here, either. Probably, the best thing to do would be either to upgrade to 2.6.28.x or to downgrade to 2.6.27.x. If the problem goes away, good. Theodore Kilgore The bug occurs seldomly here, too. I'm using Ubuntu 8.10 with the Ubuntu flavour of 2.6.27, some weeks old v4l-dvb-tree, and MSI digivox II v3. I have to switch channels a couple of times to get a channel lock. Can't reproduce it, and it doesn't happend for some time. Possibly because of a v4l-dvb- or kernel- update. Cheers, Carsten -- 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
Where to find DVB-API v5 (s2api) documentation
Hello list, is there any documentation of the dvb-api v5 (or s2api) available? I've already read the various s2api-threads, but there are still a lot of questions, especially about the delivery-system- and capabilities-stuff. Any starting points for reading about that? Thanks, Carsten -- 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
Re: Howto obtain sysfs-pathes for DVB devices?
Am Fri, 30 Jan 2009 03:07:07 +0100 schrieb hermann pitton hermann-pit...@arcor.de: Hi, Am Mittwoch, den 28.01.2009, 16:46 +0100 schrieb Carsten Meier: Hello again, now I've managed to obtain syfs-pathes for v4l2-devices. But what about dvb? I haven't found something like bus_info in the dvb-api-docs. (I'm new to it) Any hints for this? Thanks, Carsten I'm also still new on it ... Maybe anything useful here? cat /sys/class/dvb/dvb0.frontend0/uevent MAJOR=212 MINOR=0 PHYSDEVPATH=/devices/pci:00/:00:08.0/:01:07.0 PHYSDEVBUS=pci PHYSDEVDRIVER=saa7134 Cheers, Hermann Hi, IMHO there is no other way (not counting other daemons) than scanning the dvb-device-files, stat() them, and compare major and minor numbers with sysfs-contents. Anyway, I think I'll switch to HAL for that... Cheers, Carsten -- 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
Re: Howto obtain sysfs-pathes for DVB devices?
Am Fri, 30 Jan 2009 12:51:03 +0100 schrieb Matthias Schwarzott z...@gentoo.org: On Freitag, 30. Januar 2009, Carsten Meier wrote: Am Fri, 30 Jan 2009 03:07:07 +0100 schrieb hermann pitton hermann-pit...@arcor.de: Hi, Am Mittwoch, den 28.01.2009, 16:46 +0100 schrieb Carsten Meier: Hello again, now I've managed to obtain syfs-pathes for v4l2-devices. But what about dvb? I haven't found something like bus_info in the dvb-api-docs. (I'm new to it) Any hints for this? Thanks, Carsten I'm also still new on it ... Maybe anything useful here? cat /sys/class/dvb/dvb0.frontend0/uevent MAJOR=212 MINOR=0 PHYSDEVPATH=/devices/pci:00/:00:08.0/:01:07.0 PHYSDEVBUS=pci PHYSDEVDRIVER=saa7134 Cheers, Hermann Hi, IMHO there is no other way (not counting other daemons) than scanning the dvb-device-files, stat() them, and compare major and minor numbers with sysfs-contents. Anyway, I think I'll switch to HAL for that... One way of asking udev is this: udevadm info -q path -n /dev/dvb/adapter0/frontend0 Regards Matthias Ok, then I think I'm gonna use it... :) It's much more simple than struggling through dbus-/hal-libs and the various unfinished c++ bindings, although I normally don't like to start system-tools from c++. Or is there any c-api for it? I haven't found one. Thanks, Carsten -- 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
How to obtain sysfs-path from bus_info
Am Thu, 22 Jan 2009 16:57:36 +0100 schrieb Laurent Pinchart laurent.pinch...@skynet.be: On Thursday 22 January 2009, Carsten Meier wrote: Am Thu, 22 Jan 2009 00:20:00 +0100 schrieb Laurent Pinchart laurent.pinch...@skynet.be: Hi Carsten, On Wednesday 21 January 2009, Carsten Meier wrote: now I want to translate bus_info into a sysfs-path to obtain device-info like serial numbers. Given a device reports usb-:00:1d.2-2 as bus_info, then the device-info is located under /sys/bus/usb/devices/2-2, which is a symlink to the appropriate /sys/devices/ directory, right? I'm afraid not. In the above bus_info value, :00:1d.2 is the PCI bus path of your USB controller, and the last digit after the dash is the USB device path. All I have to do is to compare the first 4 chars of bus_info against usb-, get the chars after . and append it to /sys/bus/usb/devices/ to obatin a sysfs-path, right? Is there a more elegant solution or already a function for this? Can the . appear more than once before the last one? Probably not before, but definitely after. Root hubs get a USB device path set to '0'. Every other device is numbered according to the hub port number it is connected to. If you have an external hub connected on port 2 of your root hub, and have a webcam connected to port 3 of the external hub, usb_make_path() will return usb-:00:1d.2-2.3. Cheers, Laurent Pinchart Hi, On my machine, my pvrusb2 (connected directly to my mini-pc) shows up under /sys/bus/usb/devices/7-2/ which is a symbolic link to ../../../devices/pci:00/:00:1d.7/usb7/7-2 You're just lucky that USB bus 7 (usb7/7) is connected to the 7th function of your USB host controller (1d.7). Here's an example of what I get on my computer: /sys/bus/usb/devices/4-2 - ../../../devices/pci:00/:00:1d.2/usb4/4-2 I can't test for the new bus_info-string, because it's not fixed yet in the driver. But if I got it correctly it should be usb-:00:1d.7-7.2 ? I think you will get usb-:00:1d.7-2 Then I've to simply take the string after the last dash, replace . by - and append it to /sys/bus/usb/devices/ for a sysfs-path? Unfortunately the mapping is not that direct. The part before the last dash identifies the USB host controller. The part after the last dash identifies the device path related to the controller, expressed as a combination of port numbers. The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB bus number (in this case 7) that is not present in usb_make_path()'s output. To find the sysfs path of your USB peripheral, you will have to find out which bus number the bus name (:00:1d.7) corresponds to. You might be able to find that by checking each usb[0-9]+ links in /sys/bus/usb/devices and comparing the link's target with the bus name. Best regards, Laurent Pinchart Hi, I'll scan the link-targets of /sys/bus/usb/devices/usb[0-9] and compare them against the bus name. Now I've the problem of extracting the right path component of the link-target to compare with. E.g. /sys/bus/usb/devices/usb7 points to ../../../devices/pci:00/:00:1d.7/usb7 . My plan is to check the bus name against the component before last and then extract the bus num from the last component's digit. Now again a question: Does this always work or is there probably another parent directory for usb7 in the global devices-directory? Thanks again... Regards, Carsten -- 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
How to obtain sysfs-path from bus_info
Am Thu, 22 Jan 2009 22:12:08 +0100 schrieb Thierry Merle thierry.me...@free.fr: Laurent Pinchart a écrit : On Thursday 22 January 2009, Carsten Meier wrote: Am Thu, 22 Jan 2009 00:20:00 +0100 schrieb Laurent Pinchart laurent.pinch...@skynet.be: Hi Carsten, On Wednesday 21 January 2009, Carsten Meier wrote: now I want to translate bus_info into a sysfs-path to obtain device-info like serial numbers. Given a device reports usb-:00:1d.2-2 as bus_info, then the device-info is located under /sys/bus/usb/devices/2-2, which is a symlink to the appropriate /sys/devices/ directory, right? I'm afraid not. In the above bus_info value, :00:1d.2 is the PCI bus path of your USB controller, and the last digit after the dash is the USB device path. All I have to do is to compare the first 4 chars of bus_info against usb-, get the chars after . and append it to /sys/bus/usb/devices/ to obatin a sysfs-path, right? Is there a more elegant solution or already a function for this? Can the . appear more than once before the last one? Probably not before, but definitely after. Root hubs get a USB device path set to '0'. Every other device is numbered according to the hub port number it is connected to. If you have an external hub connected on port 2 of your root hub, and have a webcam connected to port 3 of the external hub, usb_make_path() will return usb-:00:1d.2-2.3. Cheers, Laurent Pinchart Hi, On my machine, my pvrusb2 (connected directly to my mini-pc) shows up under /sys/bus/usb/devices/7-2/ which is a symbolic link to ../../../devices/pci:00/:00:1d.7/usb7/7-2 You're just lucky that USB bus 7 (usb7/7) is connected to the 7th function of your USB host controller (1d.7). Here's an example of what I get on my computer: /sys/bus/usb/devices/4-2 - ../../../devices/pci:00/:00:1d.2/usb4/4-2 I can't test for the new bus_info-string, because it's not fixed yet in the driver. But if I got it correctly it should be usb-:00:1d.7-7.2 ? I think you will get usb-:00:1d.7-2 Then I've to simply take the string after the last dash, replace . by - and append it to /sys/bus/usb/devices/ for a sysfs-path? Unfortunately the mapping is not that direct. The part before the last dash identifies the USB host controller. The part after the last dash identifies the device path related to the controller, expressed as a combination of port numbers. The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB bus number (in this case 7) that is not present in usb_make_path()'s output. To find the sysfs path of your USB peripheral, you will have to find out which bus number the bus name (:00:1d.7) corresponds to. You might be able to find that by checking each usb[0-9]+ links in /sys/bus/usb/devices and comparing the link's target with the bus name. To ease this processing, using libsysfs can be a good idea... On my system, the documentation of libsysfs is here: /usr/doc/sysfsutils-2.1.0/libsysfs.txt Knowing the bus-id, it won't be hard to look at it in data structures. Just my 2 cents. Hi, I already looked at it, but it doesn't help very much if you don't know how sysfs is organized in detail. The sysfs-reference at http://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/ also doesn't help very much as it only gives a brief overview. Regards, Carsten -- 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
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Am Thu, 22 Jan 2009 16:57:36 +0100 schrieb Laurent Pinchart laurent.pinch...@skynet.be: On Thursday 22 January 2009, Carsten Meier wrote: Am Thu, 22 Jan 2009 00:20:00 +0100 schrieb Laurent Pinchart laurent.pinch...@skynet.be: Hi Carsten, On Wednesday 21 January 2009, Carsten Meier wrote: now I want to translate bus_info into a sysfs-path to obtain device-info like serial numbers. Given a device reports usb-:00:1d.2-2 as bus_info, then the device-info is located under /sys/bus/usb/devices/2-2, which is a symlink to the appropriate /sys/devices/ directory, right? I'm afraid not. In the above bus_info value, :00:1d.2 is the PCI bus path of your USB controller, and the last digit after the dash is the USB device path. All I have to do is to compare the first 4 chars of bus_info against usb-, get the chars after . and append it to /sys/bus/usb/devices/ to obatin a sysfs-path, right? Is there a more elegant solution or already a function for this? Can the . appear more than once before the last one? Probably not before, but definitely after. Root hubs get a USB device path set to '0'. Every other device is numbered according to the hub port number it is connected to. If you have an external hub connected on port 2 of your root hub, and have a webcam connected to port 3 of the external hub, usb_make_path() will return usb-:00:1d.2-2.3. Cheers, Laurent Pinchart Hi, On my machine, my pvrusb2 (connected directly to my mini-pc) shows up under /sys/bus/usb/devices/7-2/ which is a symbolic link to ../../../devices/pci:00/:00:1d.7/usb7/7-2 You're just lucky that USB bus 7 (usb7/7) is connected to the 7th function of your USB host controller (1d.7). Here's an example of what I get on my computer: /sys/bus/usb/devices/4-2 - ../../../devices/pci:00/:00:1d.2/usb4/4-2 I can't test for the new bus_info-string, because it's not fixed yet in the driver. But if I got it correctly it should be usb-:00:1d.7-7.2 ? I think you will get usb-:00:1d.7-2 Then I've to simply take the string after the last dash, replace . by - and append it to /sys/bus/usb/devices/ for a sysfs-path? Unfortunately the mapping is not that direct. The part before the last dash identifies the USB host controller. The part after the last dash identifies the device path related to the controller, expressed as a combination of port numbers. The sysfs device path /sys/bus/usb/devices/7-2/ includes a USB bus number (in this case 7) that is not present in usb_make_path()'s output. To find the sysfs path of your USB peripheral, you will have to find out which bus number the bus name (:00:1d.7) corresponds to. You might be able to find that by checking each usb[0-9]+ links in /sys/bus/usb/devices and comparing the link's target with the bus name. Best regards, Laurent Pinchart Hi Laurent, could you please post what your video-device reports for bus_info together with the /sys/bus/usb-path where it shows up and the location where the symlink points to? This thing makes me going nuts... :( Thanks, Carsten -- 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
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Am Mon, 19 Jan 2009 04:25:54 +0100
schrieb Carsten Meier c...@trexity.de:
Am Mon, 19 Jan 2009 06:11:33 +0300
schrieb Alexey Klimov klimov.li...@gmail.com:
On Mon, Jan 19, 2009 at 6:09 AM, Alexey Klimov
klimov.li...@gmail.com wrote:
On Mon, 2009-01-19 at 03:55 +0100, Carsten Meier wrote:
Am Mon, 19 Jan 2009 05:25:15 +0300
schrieb Alexey Klimov klimov.li...@gmail.com:
On Sun, 2009-01-18 at 23:36 -0200, Mauro Carvalho Chehab wrote:
On Sat, 17 Jan 2009 19:09:51 +0100
Carsten Meier c...@trexity.de wrote:
Am Fri, 16 Jan 2009 02:47:50 -0200
schrieb Mauro Carvalho Chehab mche...@infradead.org:
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.
I looked at the sources for what string gets generated for
bus_info by usb_make_path(). If it gets used by pvrusb2, my
problems are solved, because it is constant across
standby-wake-up-cycles. The pvrusb2's implementation
currently delivers usb 7-2 address 6 here. address 6
corresponds to devnum which gets constantly increased,
which results in always changing strings here. Sorry for my
unneccessary complaints.
Mike, Thierry, Jean-Francois, Laurent and others:
IMO, we should patch all usb drivers to use usb_make_path().
It will be more transparent to userspace, if all drivers
provide the bus_info using the same notation. Comments?
I did this thing to dsbr100.c usb radio driver:
diff -r de513684aca2 linux/drivers/media/radio/dsbr100.c
--- a/linux/drivers/media/radio/dsbr100.c Sun Jan 18 23:06:34
2009 -0200 +++ b/linux/drivers/media/radio/dsbr100.cMon
Jan 19 05:18:36 2009 +0300 @@ -393,9 +393,12 @@
static int vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *v)
{
+ struct dsbr100_device *radio = video_drvdata(file);
+
strlcpy(v-driver, dsbr100, sizeof(v-driver));
strlcpy(v-card, D-Link R-100 USB FM Radio,
sizeof(v-card));
- sprintf(v-bus_info, USB);
+ usb_make_path(radio-usbdev, v-bus_info,
sizeof(v-bus_info));
+ printk(KERN_INFO %s\n, v-bus_info);
v-version = RADIO_VERSION;
v-capabilities = V4L2_CAP_TUNER;
return 0;
And get such dmesg messages for different usb ports:
usb-:00:1d.2-2
usb-:00:1d.0-1
Looks okay to my eyes or may be i missed something. Anyway it's
more useful than just simple USB string.
Do you get the same string if you unplug and then replug the same
device to the same port? If not, I have the same problems than
before, otherwise I'll be happy with it.
To be sure that i did that you want me to: i plug device in, run
application that use it, close application, unplug device, and
then plug device in (and i didn't reload the kernel module during
this), run app again..
Yes, i have the same string in this case. btw, kernel 2.6.29-rc2.
Oh, i forget to tell you that it was the same usb port and the same
usb device. :)
Yes, that's what I meant. :) Userspace-land would be very happy if
usb_make_path() is used by all usb-device-drivers.
Hi,
now I want to translate bus_info into a sysfs-path to obtain
device-info like serial numbers. Given a device reports
usb-:00:1d.2-2 as bus_info, then the device-info is located
under /sys/bus/usb/devices/2-2, which is a symlink to the
appropriate /sys/devices/ directory, right?
All I have to do is to compare the first 4 chars of bus_info against
usb-, get the chars after . and append it to
/sys/bus/usb/devices/ to obatin a sysfs-path, right?
Is there a more elegant solution or already a function for this? Can
the . appear more than once before the last one?
Thaks,
Carsten
--
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
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Am Mon, 19 Jan 2009 05:25:15 +0300
schrieb Alexey Klimov klimov.li...@gmail.com:
On Sun, 2009-01-18 at 23:36 -0200, Mauro Carvalho Chehab wrote:
On Sat, 17 Jan 2009 19:09:51 +0100
Carsten Meier c...@trexity.de wrote:
Am Fri, 16 Jan 2009 02:47:50 -0200
schrieb Mauro Carvalho Chehab mche...@infradead.org:
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.
I looked at the sources for what string gets generated for
bus_info by usb_make_path(). If it gets used by pvrusb2, my
problems are solved, because it is constant across
standby-wake-up-cycles. The pvrusb2's implementation currently
delivers usb 7-2 address 6 here. address 6 corresponds to
devnum which gets constantly increased, which results in always
changing strings here. Sorry for my unneccessary complaints.
Mike, Thierry, Jean-Francois, Laurent and others:
IMO, we should patch all usb drivers to use usb_make_path(). It
will be more transparent to userspace, if all drivers provide the
bus_info using the same notation. Comments?
I did this thing to dsbr100.c usb radio driver:
diff -r de513684aca2 linux/drivers/media/radio/dsbr100.c
--- a/linux/drivers/media/radio/dsbr100.c Sun Jan 18 23:06:34
2009 -0200 +++ b/linux/drivers/media/radio/dsbr100.c Mon Jan
19 05:18:36 2009 +0300 @@ -393,9 +393,12 @@
static int vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *v)
{
+ struct dsbr100_device *radio = video_drvdata(file);
+
strlcpy(v-driver, dsbr100, sizeof(v-driver));
strlcpy(v-card, D-Link R-100 USB FM Radio,
sizeof(v-card));
- sprintf(v-bus_info, USB);
+ usb_make_path(radio-usbdev, v-bus_info,
sizeof(v-bus_info));
+ printk(KERN_INFO %s\n, v-bus_info);
v-version = RADIO_VERSION;
v-capabilities = V4L2_CAP_TUNER;
return 0;
And get such dmesg messages for different usb ports:
usb-:00:1d.2-2
usb-:00:1d.0-1
Looks okay to my eyes or may be i missed something. Anyway it's more
useful than just simple USB string.
Do you get the same string if you unplug and then replug the same
device to the same port? If not, I have the same problems than before,
otherwise I'll be happy with it.
Regards,
Carsten
--
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
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Am Mon, 19 Jan 2009 06:11:33 +0300
schrieb Alexey Klimov klimov.li...@gmail.com:
On Mon, Jan 19, 2009 at 6:09 AM, Alexey Klimov
klimov.li...@gmail.com wrote:
On Mon, 2009-01-19 at 03:55 +0100, Carsten Meier wrote:
Am Mon, 19 Jan 2009 05:25:15 +0300
schrieb Alexey Klimov klimov.li...@gmail.com:
On Sun, 2009-01-18 at 23:36 -0200, Mauro Carvalho Chehab wrote:
On Sat, 17 Jan 2009 19:09:51 +0100
Carsten Meier c...@trexity.de wrote:
Am Fri, 16 Jan 2009 02:47:50 -0200
schrieb Mauro Carvalho Chehab mche...@infradead.org:
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.
I looked at the sources for what string gets generated for
bus_info by usb_make_path(). If it gets used by pvrusb2, my
problems are solved, because it is constant across
standby-wake-up-cycles. The pvrusb2's implementation
currently delivers usb 7-2 address 6 here. address 6
corresponds to devnum which gets constantly increased, which
results in always changing strings here. Sorry for my
unneccessary complaints.
Mike, Thierry, Jean-Francois, Laurent and others:
IMO, we should patch all usb drivers to use usb_make_path(). It
will be more transparent to userspace, if all drivers provide
the bus_info using the same notation. Comments?
I did this thing to dsbr100.c usb radio driver:
diff -r de513684aca2 linux/drivers/media/radio/dsbr100.c
--- a/linux/drivers/media/radio/dsbr100.c Sun Jan 18 23:06:34
2009 -0200 +++ b/linux/drivers/media/radio/dsbr100.cMon
Jan 19 05:18:36 2009 +0300 @@ -393,9 +393,12 @@
static int vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *v)
{
+ struct dsbr100_device *radio = video_drvdata(file);
+
strlcpy(v-driver, dsbr100, sizeof(v-driver));
strlcpy(v-card, D-Link R-100 USB FM Radio,
sizeof(v-card));
- sprintf(v-bus_info, USB);
+ usb_make_path(radio-usbdev, v-bus_info,
sizeof(v-bus_info));
+ printk(KERN_INFO %s\n, v-bus_info);
v-version = RADIO_VERSION;
v-capabilities = V4L2_CAP_TUNER;
return 0;
And get such dmesg messages for different usb ports:
usb-:00:1d.2-2
usb-:00:1d.0-1
Looks okay to my eyes or may be i missed something. Anyway it's
more useful than just simple USB string.
Do you get the same string if you unplug and then replug the same
device to the same port? If not, I have the same problems than
before, otherwise I'll be happy with it.
To be sure that i did that you want me to: i plug device in, run
application that use it, close application, unplug device, and then
plug device in (and i didn't reload the kernel module during this),
run app again..
Yes, i have the same string in this case. btw, kernel 2.6.29-rc2.
Oh, i forget to tell you that it was the same usb port and the same
usb device. :)
Yes, that's what I meant. :) Userspace-land would be very happy if
usb_make_path() is used by all usb-device-drivers.
--
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
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Am Fri, 16 Jan 2009 12:36:43 +0100 schrieb Carsten Meier c...@trexity.de: To make this mechanism work reliably with USB, the meaning of the field could be adapted to something like a binary identifier string. I really meant opaque identifier string. -- 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
