Which Drivers Are Used by Usb Mouse in Linux Kernel

Which drivers are used by usb mouse in linux kernel?

I'll try to answer your questions one by one :

1) To make my module load (hotplug) when this mouse plugs in, I have to disable these 3 drivers in kernel and build whole kernel with my driver with vendor and device ID in id_table. Right?

Yes, but there are some additional things you need to take care of. First understand how a particular module(driver) gets loaded. The key to this is MODULE_DEVICE_TABLE(usb, &my_id_table); Whenever a particular module is "installed" (using make modules_install), an entry, according to the id table passed in MODULE_DEVICE_TABLE gets created in /lib/modules/<your_kernel>/modules.usbmap and /lib/modules/<your_kernel>/modules.dep file(search for the string "usbhid" in the files). Whenever a new usb device is detected, the kernel reads these files to find the matching parameters. If it is found, the following module is loaded from the corresponding path found in /lib/modules/<your_kernel>/modules.dep which holds the info. about the path where the driver is located and also its dependencies.

So, now even if you unload(rmmod) usbhid from the kernel, it will be loaded again when you re-insert your mouse. To avoid this from happening you need to modify those files, i.e. remove the entries from the files. To do so, "move" the usbhid driver from its original path(generally located at /lib/modules/<your_kernel>/kernel/drivers/hid/usbhid/usbhid.ko to a safe place. Now rebuild the dependencies such that the entries would be removed from the dependency files.

Now you need to create entries of your driver. Just install your driver and you are good to go!

So, to summarize :

$ sudo rmmod usbhid                                      # Unload the usb mouse driver
$ cd /lib/modules/$(uname -r)/ # Move to your current kernel
$ vim modules.usbmap # Check for the "usbhid" string
$ vim modules.dep # Check for "usbhid.ko:" string
$ sudo mv kernel/drivers/hid/usbhid/usbhid.ko ~/Desktop # Take backup of your current
usb mouse driver
$ sudo depmod -a # Rebuild the dependency files

Now check the dependency files for the string "usbhid" again. It shouldn't be there!

$ cd /path/to/your/driver
$ sudo make modules_install # Install your driver into /lib/modules/$(uname -r)/extra
$ sudo depmod -a # Rebuild the dependency files

After this step, search for the string corresponding to your module in the dependency files, and it should be there! From this moment on, whenever you insert the mouse(or from boot itself) your driver will be loaded, instead of the original.

Once your are done playing with your driver, you may copy back the original usbhid file to its original destination and rebuild the dependency files (sudo depmod -a)

Now I also see that you are trying to use vendor and device id to match your device, in which case, the driver would work only for your mouse. The recommended way is to use class ids, which makes your driver work for any usb mouse.


2) I also read about USB core drivers and USB device drivers. So these HID drivers are core drivers or device drivers?

usbhid is basically a "device driver". The classification of drivers could be briefed out as : core drivers, host controller drivers and device drivers :

Device Drivers : This is the software used to control the devices. For example usb mouse, pci based ethernet card, usb pendrive, i2c based accelerometer.

Host Controller Drivers : This is the software written to control the bus controller. For example USB Host Controllers(EHCI, UHCI, OHCI, etc.), PCI Host Controller, I2C Masters, etc.

Core Drivers : These actually glues up the above discussed drivers. Examples are USB core, PCI core, etc. Core drivers provides helper routines(APIs) such that the device and host-controller driver could make use of them(concept of module stacking!). These are the ones, which bind the correct device to its driver. There are many other services provided by the core drivers.

Example code for USB Device Driver :

http://lxr.free-electrons.com/source/drivers/hid/usbhid/usbmouse.c

You may find the USB Host Controller Drivers under :

http://lxr.free-electrons.com/source/drivers/usb/host/

USB Core resides here : http://lxr.free-electrons.com/source/drivers/usb/core/

I think this also answers your third question!

Hope this helped.

How to insert my driver automatically on the insertion of USB mouse in Linux System?

Thanks all for your help.

I follow the udev approach to load module automatically on the USB insertion

Below is the procedure to load your Driver automatically on the Insertion of Hot plug-gable device (I experiment with the USB mouse and below procedure is working fine for it)

  1. Run Following command

    cmd > udevadm info -a -p $(udevadm info -q path -n /dev/input/mouse)

    In place of ?? in the above command user need to add the device ID based on its entry in /dev (e.g.for USB flash drive: sdb1 or sda1 etc. based on the device identity)

  2. Get the Value of the below parameters from the output of above command
    KERNEL, ATTRS{idVendor}, ATTRS{idProduct}, ATTRS{serial}

  3. Go to /etc/dev/rule.d directory and Add your rule

    cmd > sudo vim 40-usbmouse.rules
    ACTION=="add", SUBSYSTEM=="block", KERNEL=="sd?1", ATTRS{idVendor}=="058f", ATTRS{idProduct}=="6387", ATTRS{serial} =="4EPLXAXE", SYMLINK+="usbpd", RUN+="/usr/local/bin/InsertModule.sh"

    Save this file.
    Above rule is defined for the USB Mouse.
    Parameter SYMLINK creates a link of your device in the /dev directory and In RUN+ you can give your script location which is going to execute on your device insertion.

    For more info on How to write a rule refer below link

    http://hackaday.com/2009/09/18/how-to-write-udev-rules/

  4. Now after you define your rule user need to restart the udev to take your rule in notice by kernel.
    cmd > sudo stop udev

    cmd > sudo start udev

  5. Insert your USB and validate that your script which you define in your rule shows its effact.
    For Mouse user can use below command

    cmd > udevadm info -a -p $(udevadm info -q path -n /dev/input/mouse)

P.S.: cmd stands for the command shell (Terminal).The above procedure is working with any USB device.

Which usb driver is called in order to transfer data?

I searched and i found that it's the function usb_stor_bulk_transfer_sglist in transport.c that perform a data transfer for a USB flash drive

In fact, it uses URB with sglist of address

How to implement mouse drivers Linux USB mouse driver?

As guidance given by Mr. Stark which is essential before writing a module. As far as the problem of usb mouse driver you can check the following link. For the unknown USB device you can refer this link.
More links for usb mouse driver : link1 link2

How does linux pick connect the mouse on my display to a driver in /dev/input/mouse*?

The Linux kernel doesn't process /dev/input/mouse*

The kernel is what provides /dev/input/mouse*

Userspace programs like X.org can then read this device and show a cursor moving accordingly.

USB drivers fall under which category of drivers? character drivers or block drivers?

There are both character and block USB drivers:

  • cdc-acm is a character driver (for USB CDC serial ports).
  • usb-storage is a block device driver (USB mass storage).

You could omit developing a kernel level USB driver by using LibUSB in your application.

How does linux recognize what input driver it needs to load?

Background: kernel sends what is called uevents using kobject_uevent_env function. This uevents are read by udev daemon from netlink socket (earlier versions used hotplug). Before start, udev preloads rules from /etc/udev/rules.d/, this rules contain information about what need to be done as reaction to appropriate uevent from kernel (f.e. insmod a module).

Now about what you have asked. Typically what is shipped with uevent message is a MODALIAS, it could look like this:

MODALIAS = usb:v046DpC03Ed2000dc00dsc00dp00ic03isc01ip02

The USB device stores vendor id and device id, they are used, also, when MODALIAS is constructed. The kernel device drivers, which could be loaded dynamically (.ko files) also store the device identificators, this driver could work with. The driver could announce that it works with appropriate device/vendor id using MODULE_DEVICE_TABLE macro. So that is how the relationship between device and dynamic module is established.



Related Topics



Leave a reply



Submit