How to disable unused device without blacklisting a module
 

Hello,

Does anyone know a general way of disabling a device without blacklisting a module/driver? The reason I am asking this is that I have two webcams (one built-in, one external) and I want to permanently disable the built-in one. Blacklisting a module is not an option cause both webcams use the same driver (uvcvideo, if that makes a difference)...
I was trying to find a way to do that using udev rule(s) but no luck so far.

Crossposted a week ago on askubuntu: http://askubuntu.com/questions/18970...n-external-one

Thanks,
Alikasundara

Have you looked in the BIOS to see if you can disable it there? If you can, then the OS won't see the device at all.

Yes, that was the first thing I tried (no luck). Sorry for not mentioning it in the original post.

Thanks,
Alikasundara

This blogger wrote a udev rule to switch which one was primary...

http://windywindycitytech.wordpress....-linux-ubuntu/

You could do something similar, just not enable the one at all...

However, what about the BIOS? Many built in cameras can be disabled in the BIOS settings...

Thanks for your reply, but I am looking to disable the device completely for paranoia reasons ;-)

I have checked that already. Unfortunately my BIOS seems to be very limited and does not support disabling the webcam...

Thanks,
Alikasundara

You might look into unplugging the web cam. Most manufacturers have doc on how to remove and replace parts. If you are handy, and have some physical kill, you may be able to simply unplug the device.

If in the udev rules,... you "send it to never-never land," by not defining a valid rule that will allow its use, it will be functionally disabled. That means modifying the blogger's udev rules to define the built-in camera such that it will not get picked up by uvcvideo.

If a device is not properly defined by the system's udev rules,... and cannot be found, it doesn't exist as far as the system is concerned. Unuseable. It's just an unknown device...

Only someone with root access would be able to fix it...

Short of physically removing it, only cutting power to it will "completely" disable it,... and that's a (missing) BIOS function.

Sounds promising... This rule matches the device:

Any idea how to make it "invalid" enough?

Thank you!

Start by commenting it out... the # in the beginning of it's line...

The webcam was enabled without any udev configuration, so commenting out the rule I have just created will not help...

I will do that as a last resort ;-)
It just seems unbelivable to me that there is no easy way to disable a particular device on OS level.

Are you sure that there is no udev rule regarding this camera? Did you check within the /etc/udev/rules.d/ directory? They might just ID the camera by vendor...

I'm not sure how uvcvideo works, but I would assume that udev has to ID the device first, before it just starts using it... uvcvideo is part of the v4l2 subsystem, ... and one would assume that this device is getting assigned to something like /dev/video0 or something ...

Positive. The only udev rules I have cover persistent net device naming.

It is assigned to /dev/video0 without any rules at all. I am guessing that's because video0 is the default name for this device. Udev man page states that "If no matching rule is found, the default kernel device name is used". I think that's exactly the case here, cause with udev stopped the /dev/video0 node is not created (it's actually removed whenever I stop udev).

Thanks,
Alikasundara

That just doesn't sound right...

What about in...
/usr/lib/udev/rules.d
???

My understanding was that udevadm handled all the /dev namings... ?!?!
But then again, I don't know whether the udev developers even fully understand udev...

Alright,... Following up my own post...

See here,...

http://content.hccfl.edu/pollock/AUnix1/udev-info.htm

Third paragraph,... I suppose it is possible for the driver to produce its own dev namings...

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. If it's the latter, you either patch UVC to NOT pick up that device, or you're S-O-L, unfortunately.

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.
So, I am guessing that /dev/video0 is created based on DEVNAME from sysfs.

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:

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):

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:

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!