How to know if USB device has driver properly installed?
in [Debian]
|
Prev: ATI Radeon HD 4550 & HDMI : only stereo (with radeonhd) !!!
Next: If you use DRDB ... dont update / upgrade your kernel
From: Dotan Cohen on 12 Mar 2010 13:50 > Well, once you compile a driver, you have to load it, which is done by > modprobe. Removing is modprobe -r. man modprobe and man lsmod are a good > start. > Thanks! -- Dotan Cohen http://bido.com http://what-is-what.com Please CC me if you want to be sure that I read your message. I do not read all list mail. -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/880dece01003121049y42f1418bu78ba92c5c05fe887(a)mail.gmail.com
From: Celejar on 12 Mar 2010 14:20 On Fri, 12 Mar 2010 18:18:30 +0200 Dotan Cohen <dotancohen(a)gmail.com> wrote: > > No, it only means that this combination of vendor ID 104f (WB > > Electronics) and device ID 0006 (Infinity Smart) is not listed in your > > /var/lib/usbutils/usb.ids file. You can run "update-usbids" to get the > > newest version. The contents of the usb.ids have no influence on the > > process by which the kernel tries to find modules for devices, AFAIK. > > > > If after running "sudo update-usbids.sh" the device name is still not > shown, is that a sign that the driver is not properly installed? As others (Florian) have explained, no. IIUC, the usbids list is just a list of mappings between USB IDs and the organizations to which they have been allotted - it has no connection whatsoever to any executable code. Drivers often contain (hardcoded) lists of USB IDs which they (think that they) can handle, and, IIUC, they sometimes will pick up any device whose data seems to be following a protocol that they know. For example, I recently purchased a cheap, no-name USB webcam from a Far Eastern distributor. lsusb didn't display anything helpful, but the uvc kernel driver handled the camera fine, apparently because the camera was speaking the uvc protocol. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100312141237.18fff5fc.celejar(a)gmail.com
From: Florian Kulzer on 12 Mar 2010 18:30 On Fri, Mar 12, 2010 at 14:12:37 -0500, Celejar wrote: > On Fri, 12 Mar 2010 18:18:30 +0200 Dotan Cohen wrote: [...] > > If after running "sudo update-usbids.sh" the device name is still not > > shown, is that a sign that the driver is not properly installed? > > As others (Florian) have explained, no. IIUC, the usbids list is just > a list of mappings between USB IDs and the organizations to which they > have been allotted - it has no connection whatsoever to any executable > code. Drivers often contain (hardcoded) lists of USB IDs which they > (think that they) can handle, and, IIUC, they sometimes will pick up > any device whose data seems to be following a protocol that they know. The kernel seems to use the information in /lib/modules/$(uname -r)/modules.alias to decide which module(s) to try for a given device. AFAIK, this information is generated/updated by running depmod, which is handled automatically if you install a Debian kernel package or if you use module-assistant/DKMS to handle additional modules. > For example, I recently purchased a cheap, no-name USB webcam from a > Far Eastern distributor. lsusb didn't display anything helpful, but > the uvc kernel driver handled the camera fine, apparently because the > camera was speaking the uvc protocol. That is also how I understand the process. Some of the entries in modules.alias are straightforward vendor/device-ID pairs, while others use wildcards for these values and rely on capabilities such as "a modem of class X, subclass Y that understands protocol Z". The module then often uses dedicated diagnostic code to find out if it really supports that particular device. Syslog/dmesg should reveal which modules the kernel tried in response to a USB hotplug event and if there were any problems. Modprobing the module with a higher debug level (if that option is available) should provide additional clues. -- Regards, | Florian | -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100312230913.GA8281(a)isar.localhost
From: Tzafrir Cohen on 13 Mar 2010 10:30 On Thu, Mar 11, 2010 at 10:19:05PM +0200, Dotan Cohen wrote: > I am trying to get a USB device working. In lsusb the ID shows up, but > the name of the device does not. Is this an indication that the driver > is not properly installed? > > For instance, this is how functioning devices look in lsusb: > Bus 005 Device 003: ID 413c:8126 Dell Computer Corp. Wireless 355 Bluetooth > > However, the device that I need to operate does not show the name, > only the beginning of the line like this: > Bus 003 Device 002: ID 104f:0006 > > Does that mean that the device driver is not properly installed? Basically what you ask for is the USB equivalent of lspci -k . Sadly there's no such thing. A quick search (usb 413c:8126 linux) brings up http://cateee.net/lkddb/web-lkddb/BT_HCIUSB.html -- Tzafrir Cohen | tzafrir(a)jabber.org | VIM is http://tzafrir.org.il | | a Mutt's tzafrir(a)cohens.org.il | | best ICQ# 16849754 | | friend -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100313152654.GF16560(a)pear.tzafrir.org.il
From: Celejar on 13 Mar 2010 20:20
On Sat, 13 Mar 2010 00:09:13 +0100 Florian Kulzer <florian.kulzer+debian(a)icfo.es> wrote: .... > The kernel seems to use the information in > > /lib/modules/$(uname -r)/modules.alias > > to decide which module(s) to try for a given device. AFAIK, this > information is generated/updated by running depmod, which is handled > automatically if you install a Debian kernel package or if you use > module-assistant/DKMS to handle additional modules. .... > That is also how I understand the process. Some of the entries in > modules.alias are straightforward vendor/device-ID pairs, while others > use wildcards for these values and rely on capabilities such as "a modem > of class X, subclass Y that understands protocol Z". The module then > often uses dedicated diagnostic code to find out if it really supports > that particular device. Syslog/dmesg should reveal which modules the > kernel tried in response to a USB hotplug event and if there were any > problems. Modprobing the module with a higher debug level (if that > option is available) should provide additional clues. This looks like useful stuff to know - thanks. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100313201200.b4e08e8c.celejar(a)gmail.com |