LinuxQuestions.org - [SOLVED] How to disable unused device without blacklisting a module

- Linux - Hardware (https://www.linuxquestions.org/questions/linux-hardware-18/)

- - How to disable unused device without blacklisting a module (https://www.linuxquestions.org/questions/linux-hardware-18/how-to-disable-unused-device-without-blacklisting-a-module-4175428844/)

According to this http://www.reactivated.net/writing_udev_rules.html "Even if there are no matching rules, udev will create the device node with the default name supplied by the kernel."

This seems to be the case here. There are no rules matching my webcam but udev can still query the necessary information from sysfs.

Code:

$ cd /sys/class/video4linux/

$ ls -l

$ (...) video0 -> ../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/video4linux/video0

$ cat video0/uevent

MAJOR=81

MINOR=0

DEVNAME=video0

$

So, I am guessing that /dev/video0 is created based on DEVNAME from sysfs.

Quote:

So, there's either a rule in one of the rules.d directories, or there's a listing in the driver's data file for the major and minor device node numbers, or the UVC driver is doing it directly. If it's the two former scenarios, you need to edit those files.

I am not sure if I fully understand - what do you mean by the driver's data file?

I grepped the uvc source files from the kernel (3.5.3) for 5986 (vendorId), but found no result. The other webcam's vendorId (046d - Logitech) is explicitly listed in uvc_driver.c:

Code:

uvc_driver.c: case 0x046d: /* Logitech */

I do not know much about how the kernel determines which driver to load for which device. I was under the impression that the modules must explicitly list the supported devices.

Regards,
Alikasundara

What about in hex for that vendor id?
0x1762

I'm guessing that since there's no table and no udev rule, it must be hard coded either in the driver or in the kernel. Take a look at the kernel config... Is there a reference for that vendor id?

I'm guessing you would need to either patch the driver, or the kernel to get rid of support for that camera... Ironic in a way, no?!?!

Edit: In fact, I'm pretty sure that you'll find your vendor id referenced in the kernel config,... I'm betting that's why udev is picking it up and assigning it.

At this stage, it's probably easier to crack the case open and physically remove the unwanted camera.

5986 is already in hex - lsusb lists all vendorIds in hex.
I grepped the whole kernel tree and did not find any 5986 / 1762, except in some random places. Nothing related to my device though. (5986 _is_ actually mentioned in uvc_ctrl.c but in a non-related context). Maybe some drivers provide range of vendorIds rather then list of individual devices.

Eventually I used a simple and dirty hack in uvc_probe function in uvc_driver.c (22918 is DEC for 5986):

Code:

if (udev->descriptor.idVendor == 22918 && udev->descriptor.idProduct == 865) {

  goto error;

}

and it is working (ie. the webcam is not working) fine.

Thanks for your replies,
Alikasundara

PS. Yes, it is indeed very ironic. I would have expected there to be an easier way of doing that...

Great news, and nice hack!!! ... It also sheds light on the poorly documented UVC and Udev process, and how it works...

You should put up some kind of wiki or blog with the solution, in case there are others that want to disable similar troublesome hardware.

Note that you won't be able to use any video hardware by that vendor, but I suppose it's all low rez embedded stuff, anyhow...

The irony I was referring to was that you needed to go through so much trouble to DISABLE a piece of hardware, when Linux is so often accused of not supporting hardware...

Hi JaseP; I believe I should be able to use other devices by that vendor because I specify both vendor ID and the product ID:

Code:

descriptor.idVendor == 22918 && udev->descriptor.idProduct == 865

The problem with this solution though is that the uvc source needs to be hacked every time I build a new kernel, and being a Gentoo user I am used to be doing it at least once every two weeks ;-) I still have not found any better solution.

Regards,
Alikasundara

Have you tried building your patch with DKMS??? Doing so should allow it to update the patch each time there's a modification...

Someone provided a proper solution to this problem here: http://askubuntu.com/questions/18970...n-external-one. No need to hack kernel source anymore :-)
We can finally considered this solved!