4

I have an internal webcam on my Dell laptop. I don't see it listed with lspci, but it works.

I am using a self-compiled kernel, and here are the options I have enabled:

# zcat /proc/config.gz | grep -v '^#' | egrep '(MEDIA|VIDEO)'
CONFIG_ACPI_VIDEO=y
CONFIG_MEDIA_SUPPORT=y
CONFIG_MEDIA_SUPPORT_FILTER=y
CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_VIDEO_DEV=y
CONFIG_MEDIA_CONTROLLER=y
CONFIG_VIDEO_V4L2=y
CONFIG_VIDEO_V4L2_I2C=y
CONFIG_MEDIA_USB_SUPPORT=y
CONFIG_USB_VIDEO_CLASS=y
CONFIG_VIDEOBUF2_CORE=y
CONFIG_VIDEOBUF2_V4L2=y
CONFIG_VIDEOBUF2_MEMOPS=y
CONFIG_VIDEOBUF2_VMALLOC=y
CONFIG_SND_USB_AUDIO_USE_MEDIA_CONTROLLER=y

All options in my kernel are compiled statically, and I am not using loadable modules.

How can I disable the webcam at boot time, by passing/appending something to the kernel boot options?

I would like to decide at boot time whether I want to boot the kernel with webcam support, or without.

Improve this question
8
  • 6
    A webcam is unlikely to be a PCI device. Look for it in lsusb. Commented Nov 6, 2022 at 7:52
  • I don't see how this can be done with a kernel parameter, because with a statically linked kernel, you can't blacklist a module. Uh a kernel without module loading is usually security-wise a bad idea, as you need to include all functionality that you might eventually use always in the kernel. It's also hard to use. You're using a shared-library based userland with more than a single init executable. What was the consideration that made building a non-module-loading kernel the right choice? Commented Nov 6, 2022 at 8:19
  • @Marcus Müller - I am already using kernel boot parameters to disable some other kernel components. For example my audio card: snd-hda-intel.enable=0,1. This works fine, and I don't see why same could not work for webcam. Commented Nov 6, 2022 at 8:48
  • 3
    So: What was the consideration that made building a non-module-loading kernel the right choice? This greatly influences which kind of directions you can take from here, that's why I'm asking. You have had some consideration why you're doing this, which is central to the problem at hand, so doing the "right" thing depends on knowing the original purpose. If a solution defeats that purpose, it's not a solution for you at all, and writing it would waste everyone's time. Commented Nov 6, 2022 at 9:20
  • 1
    Does this answer your question? How can I disable a kernel driver for a specific USB device? (re: driver is not compiled as a module) Or this one? Commented Nov 7, 2022 at 9:14

2 Answers 2

Reset to default
11

If CONFIG_KALLSYMS is enabled, built-in drivers can be disabled by disabling their init function. For uvcvideo (which is likely to be the driver used for your webcam), add

initcall_blacklist=uvc_video_init

to your kernel’s command line.

If it isn’t, you won’t be able to disable only your webcam using kernel command line parameters, but you can control your webcam at run-time; find its entry in /sys/bus/usb/devices, and write 0 to the corresponding authorized file, e.g.

echo 0 | sudo tee /sys/bus/usb/devices/1-8/authorized

Write 1 to enable the camera again.

You can use USBGuard to provide control over all your USB devices, including your webcam.

Improve this answer
5
  • thank you, but appending initcall_blacklist=uvc_video_init to my boot parameters has no effect. The device /dev/video0 still exists, and the webcam still works. Commented Nov 7, 2022 at 7:10
  • Does your camera use the uvcvideo driver? Commented Nov 7, 2022 at 7:25
  • how can I find out? My laptops are Dell Latitude E6540 and Dell Latitude E7440. I believe they are using standard webcams over USB interface. Commented Nov 7, 2022 at 7:40
  • based on answer from a related question, initcall_blacklist needs CONFIG_KALLSYMS to work. But I don't have KALLSYMS in my kernel: unix.stackexchange.com/questions/615332/… Commented Nov 7, 2022 at 10:08
  • Ah, you should have seen a warning in your boot logs (“initcall_blacklist requires CONFIG_KALLSYMS”). Commented Nov 7, 2022 at 10:15
1

Not meant as an answer to the problem. Only explaining why "You just cannot!" is the only possible answer to the question as worded in the title :

It is indeed possible to pass boot parameters of the kind :

module_name.parameter_name=parameter_value

Which will be honored by some in-kernel built module_name driver at the condition the driver accepts the parameter_name and parameter_value is within the range of accepted values.

The usb-storage driver would for example be able to ignore one particular usb storage device using a boot command line parameter of the kind :

usb-storage.quirks=03f0:b002:iu

Because the usb-storage is programmed in order to honor the quirks parameter and decode its value as representing Vendor-Id:Product-Id and i meaning IGNORE_DEVICE.

If the uvcvideo driver does honor a quirks parameter, it unfortunately, offers no particular value for that parameter aiming at ignoring any device.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.