# Does the "which driver" question have an universal answer?

## ManDay

It sounds strange, but in all the years I've used linux this remained a question which I was never able to fully solve.

The thing:

The kernel seems to know some way to load the correct driver for a device, so it must know which device requires which driver.

But I don't. Why? Why can I not simply use that information which the kernel appears to have to answer the question "Which driver/module do I require to use the pci/usb device of id xxxx:yyyy?"

It's painful to find all those drivers manually and I think, to the present day, I was never able to get all devices to work on all the personal computer I used and own.

----------

## Jaglover

http://kmuto.jp/debian/hcl/

or you can grep kernel sources. The fun part is if your device is not listed in kernel sources as supported then the driver will not be loaded ... regardless, if the actual chipset is supported then adding it to the kernel sources will work.

----------

## Gusar

Load a liveusb distro, see if all hardware is working, see which modules got loaded for it (lspci -vnn)

----------

## <3

 *Jaglover wrote:*   

> http://kmuto.jp/debian/hcl/

  This. It's what I use these days to set up my kernel. I wish someone would take this idea and write a program that you could install on your box instead of referencing some website.

----------

## NeddySeagoon

ManDay,

The kernel doesn't know.  It tries lots of things and if something binds to hardware, it stays loaded, if not its normally unloaded again.

There are two problems with this.  The kernel does not always get it right - its been known to load the wrong driver, which stops the right driver from working.

Not all the junk gets unloaded.

----------

## ManDay

I know of Debian HCL but that was not the answer I was looking for. Neither is using a LiveDistro an "ultimate answer" as I mentioned it.

NeddySeagoon, I guess that's it then. What a bummer.

So back to DebianHCL, is that the best one can get? What about http://cateee.net/lkddb/ ? Any use for http://www.pcidatabase.com/ ?  

After all, if there is no ultimate answer that leaves plenty of room for the next best answer possible. So what do you suggest, besides DebianHCL ?

----------

## Gusar

 *ManDay wrote:*   

> Neither is using a LiveDistro an "ultimate answer" as I mentioned it.

 

Of course it is. What else do you expect? You said the kernel does it's thing and you wanted to have that information. A live distro gives you exactly that.

----------

## py-ro

Hmm,

```
lspci -k
```

?

----------

## ManDay

Gusar, that requires that the LiveDistro has all the drivers and also applies them correctly (especially former). So now I have a couple of devices here (also USB vendor:produce keys) and Debian HCL doesn't find them if I insert them as vendor:product keys into that field (lsusb has no -n switch) - does that mean I'm screwed and will have to guess?

py-ro: What?

----------

## krinn

lspci -k will gave you the kernel driver need to load the module

and neddy said the kernel cannot detect the driver it need for a device, but udev can, and lspci too

and lspci use a live database for devices, so even the tool isn't update, you can still update its database using : update-pciids

----------

## Gusar

 *ManDay wrote:*   

> Gusar, that requires that the LiveDistro has all the drivers

 

You say the kernel does it's thing and you want that info. But now you're doubting that the kernel has the info? Does not compute. If the kernel has the info, why would a live distro be exempt from that?

----------

## ManDay

 *Gusar wrote:*   

>  *ManDay wrote:*   Gusar, that requires that the LiveDistro has all the drivers 
> 
> You say the kernel does it's thing and you want that info. But now you're doubting that the kernel has the info? Does not compute. If the kernel has the info, why would a live distro be exempt from that?

 

Why do think that by "The Kernel" I meant "A Kernel" of an arbitrary live distro, which you seem to reference here?

----------

## NeddySeagoon

ManDay,

lspci followed by lspci -n and a grep of the kernel sources is pretty good. 

lsusb and a grep of the kernel sources is good for USB devices too.

The vendor and device IDs are read from the hardware in both cases.  

Google can be faster and more user friendly when fed with the device IDs and bus tyoe.

Knowing the file that the vendor and device IDs are declared in is a pretty good guide to where in the kernel you need to look.

This falls down for 'generic devices' like usb-storage devices and UVC class webcams but you can tell the difference between a webcam and a USB storage device by other means :)

----------

## Gusar

 *ManDay wrote:*   

> Why do think that by "The Kernel" I meant "A Kernel" of an arbitrary live distro, which you seem to reference here?

 

Which kernel were you talking about then? The kernel is the kernel. Once compiled it does it's thing. And *especially* on a general purpose live distro, the kernel will have everything under the sun compiled into it (well, as modules actually).

----------

