I noticed this behavior of Webcamoid while I was testing the latest Ubuntu MATE 24.04, and I mentioned it here. At the time, I thought that the app was broken. Webcamoid “just worked” under Ubuntu MATE 21.04, but that was with my Acer laptop from 2016. This one from 2023 (manufactured in 2022) is a different animal, even if much cheaper.

The driver failed successfully

I couldn’t imagine that this is what Webcamoid does when it cannot detect any webcam. Everything else, including Cheese and Kamoid, displays a black image when no webcam is found; but Webcamoid, being developed by someone on mushrooms, takes screenshots of screenshots of screenshots ad infinitum!

The problem is that the kernel does detect the webcam, but then it doesn’t give a shit:

$ lsusb |grep Facing
Bus 003 Device 003: ID 0408:4033 Quanta Computer, Inc. ACER HD User Facing
$ sudo hwinfo --usb
...
03: USB 00.0: 0000 Unclassified device                          
  [Created at usb.122]
  Unique ID: gLM6.ATnBLzvXHQ1
  Parent ID: uIhY.2DFUsyrieMD
  SysFS ID: /devices/pci0000:00/0000:00:14.0/usb3/3-7/3-7:1.0
  SysFS BusID: 3-7:1.0
  Hardware Class: unknown
  Model: "Quanta ACER HD User Facing"
  Hotplug: USB
  Vendor: usb 0x0408 "Quanta Computer, Inc."
  Device: usb 0x4033 "ACER HD User Facing"
  Revision: "0.04"
  Serial ID: "01.00.00"
  Speed: 480 Mbps
  Module Alias: "usb:v0408p4033d0004dcEFdsc02dp01ic0Eisc01ip01in00"
  Driver Info #0:
    Driver Status: uvcvideo is active
    Driver Activation Cmd: "modprobe uvcvideo"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #4 (Hub)

So uvcvideo is active, but it didn’t create anything under /dev/video*.

$ sudo dmesg | grep uvc
[    9.602158] uvcvideo 3-7:1.1: Failed to query (129) UVC probe control : 26 (exp. 48).
[    9.602166] uvcvideo 3-7:1.1: Failed to initialize the device (-5).
[    9.602259] usbcore: registered new interface driver uvcvideo

This behavior goes in the consecrated line of “successful errors”:

So what it says is this: “uvcvideo: Failed to initialize the device (-5). Driver Status: uvcvideo is active.”

What it should have said: “uvcvideo: Failed to initialize the device. Driver Status: uvcvideo is dumb.” Because what’s active is the device, but the driver is unable to use it!

Some people tried to patch the kernel

That’s right, people tried to patch the kernel, out-of-tree. These attempts worked for some versions of the kernel. Here’s a summary of the attempts.

● On Acer forums: Acer Aspire 3 A315-59 Laptop camera not working [Fedora 38]. This happens to be my laptop, too. Relevant links:

  • Link to a comment on the corresponding Ubuntu bug 2000947 that tells people how to rebuild the uvcdriver module via Giuliano69’s patched uvc_driver.c.
  • A comment by yashoswalyo telling how to manually patch uvc_driver.c themselves on Fedora and rebuild the module.

There’s proof that it worked for the kernel 6.4.12-200.fc38.

● On r/archlinux: Issues with webcam [acer], on Feb. 15, 2024, for the same laptop Acer Aspire 3 A315-59-71NF (what comes after A315-59 specifies the configuration, but the webcam is the same) and the same webcam 0408:4033. Of relevance:

  • Link to fus0g’s patch, intended to work with both webcam devices 0408:4033 and 0408:4035, with detailed instructions.

We know that, at some point, the patch worked for the owner of an Acer Aspire 5 A515-57.

Note that fus0g’s approach is in two steps: if the patched full driver sources updated for 6.8.7-300.fc40 don’t work, you’re told to manually patch uvc_driver.c by adding two structs for the said webcam models.

The list of provided working distros is misleading: Nobara 38-39, Fedora 39-40, Ubuntu 23.10 and 24.04, Pop_OS! 22.04, Arch Linux Latest, Cachy OS Latest, Linux Mint 22, OpenSuse Tumbleweed Latest. First of all, “latest” has no meaning for rolling-release distros, unless a timestamp is mentioned or, preferably, a kernel version. Then, even Fedora 40 now has the kernel 6.9.12-200.fc40, while fus0g’s Git was updated up to 6.8.7-300.fc40. (Fedora is fucking semi-rolling.)

● On Ubuntu forums: Built in webcam doesn’t work – Acer Aspire A515-57G. First reported on Aug. 1, 2022, for Ubuntu 22.04 (kernel 5.15.0-25).

Here, too, Giuliano69’s patch is mentioned. Someone provided a spoon-feed script that worked under Ubuntu 22.04 LTS even with kernels 6.2.0-39 and, after adjustment, 6.5.0-14, which I suppose are HWE and Edge kernels.

● Revisiting Ubuntu’s Bug #2000947: UVC Quanta 0408:4035 camera PROBLEM, reported by Giuliano Lotta on 2023-01-03 (that Giuliano69!), we can find out more, beyond the already mentioned out-of-tree patch.

The actual way to rebuild the patched driver was suggested to Giuliano69 by Jeremy (wa113y3s).

Resuming from sleep seems to break the driver. Well, resuming from hibernation breaks my Wi-Fi and BT, so I don’t expect anything anymore from the Linux kernel.

The 0408:4033 camera should work just like 0408:4035, with the proper patch. It’s worth noting that these webcam models also come with Acer Nitro 5 models. Giuliano69 explains it one more time to another user. Still, it seems that this patch might fail with 0408:4033.

Oh, the uvcvideo: loading out-of-tree module taints kernel message is to be expected for a modified, unsigned module. Secure Boot should be disabled, but I disable it anyway, I’m not that brainwashed as to believe it protects me. If anything, it hinders me. I suspect that the message module verification failed: signature and/or required key missing - tainting kernel comes from having Secure Boot enabled. It’s OK to have the first warning, but this second one is an error, and it prevents the loading of the module.

Here’s what happens when you replace uvc_driver.c in its entirety instead of patching it. As the kernel evolved into newer versions, the header files have changed, and Giuliano69‘s version of it doesn’t work with all kernel versions. This happened to someone after the kernel got upgraded to 6.2.0-33. Giuliano69 insists that Ubuntu 22.04 users should use his compile_module.sh, which I tend to disagree with: it’s safer to manually patch yourself and to perform the steps one by one.

Giuliano69 himself:

AFAIK
· version users with version 22.04 (born with kernel 5.x) are supposed to follow my approach on github
· version users with version >= 23.x (with kernel 6.x) are supposed to follow the https://github.com/Kvalme/uvc.git

Strange thing, is that now 22.04 is using kernel 6.2, but still works with “old” approach…

Takshak Mudgal (takshak) details the patching process for RPM-based distros.

Let’s put together the list of patches:

They’re intrinsically identical, only the presentation is different: fully patched files updated for different kernel versions, helper scripts or not, etc.

The $64,000 question:

Shouldn’t Quanta or Acer accurately propose a patch to make your device work natively on recent kernels?
Or do they do this but the team that maintains the kernel takes a while to accept the changes?

Here’s a failure report for kernel 6.2.0-37. Giuliano69 answers that it worked for him with kernel 6.2.0-39.40~22.04.1 (linux-hwe-6.2). That was in December 2023.

A report from January 2024, that kernel 6.5.0-14 “seems to have broken both approaches” (Giuliano69 and Kvalme). In reply, Giuliano69 has updated his patched uvc_driver.c file.

Have You Heard the Good News?™ Giuliano69 did:

Richardo Ribalda has confirmed the patch to the UVC Quanta 0408:4035 camera, allowing it to join the official source code.
Hope that in few releases the uvc driver will be normally recognising the camera.
Seems that it should also apply to UVC Quanta 0408:4033 camera.

Also:

AFAIK the kernel 6.11 should get the patch as official update….

Except that I checked with kernel 6.11-rc1 and it’s not there! And the patch doesn’t work with 6.5.0-44. Still…

Seems the fix in now on the current kernel source
https://github.com/torvalds/linux/blob/master/drivers/media/usb/uvc/uvc_driver.c

About the Ricardo Ribalda thing: here’s the patch proposed on Jan. 15, 2023, and which, on June 16, 2024, was “waiting for your Tested-by: tag. I’ll add it and merge the patch for v6.11.” Wow, 17 months, that’s Speedy Gonzales! (The two webcam models are in Acer laptops since mid-2022.)

Finally, just before the Good News™, another user came with a synthesis of the above patches, but it’s just a script.sh and it doesn’t come with anything new, really; it also only patches for 0x4035 (mine is 0x4033): https://github.com/autodistries/uvc_driver-Quanta-Computer-Inc.-ACER-HD-User-Facing-Camera-0408-4035

I don’t like the way it patches, but I’d mention that his sudo modprobe uvcvideo trace=0xffffffff is meant to give a more verbose output in dmesg, for debugging purposes.

What Is to Be Done?

To quote Fridtjof Nansen, “Have you not succeeded? Continue! Have you succeeded? Continue!” Or just install Windows, which would not detect your NVMe SSDs without an extra driver, but will detect your webcam. And, either way, it supports 3rd-party drivers (Microsoft supported them since MS-DOS), whereas the Linux kernel doesn’t. Oh, how fucked up this world is!

Here are the configurations I tried these patches on:

AlmaLinux 9.4 KDE:

  • kernel 5.14
  • kernel-lt 6.1.x (ELRepo)
  • kernel-ml 6.10.x and 6.11-rc2 (ELRepo)

openSUSE Leap 15.6 KDE:

  • kernel 6.4.0

Kubuntu 24.04 LTS:

  • kernel 6.8.0
  • kernel 6.11-rc2

The shocking results, below.

AlmaLinux 9.4

First, I didn’t even try the official 5.14 kernel. It’s antiquated. It can’t support my MT7663-based Wi-Fi, so it’s useless to me. Why would I patch it to support a webcam that’s in use since 2022 if it can’t support a Wi-Fi/BT chip that’s in use also since 2022?

ELRepo’s kernels are what I relied on. But then, starting with 6.1.101 and still true for 6.1.105, kernel-lt broke my sound (which requires alsa-sof-firmware, but which works with any other kernel line). I reported the bug on ELRepo, and we tried to identify the root cause, but we failed. I investigated the differences between 6.1.100 and 6.1.101; I tried to rebuild the driver, but to no avail.

AUGUST 20 UPDATE: Regarding the bug I reported on ELRepo as 0001471: kernel-lt 6.1.101 and 6.1.102 break the Intel Alder Lake audio controller with PCI ID 8086:51c8:1025:161d: The bug automagically disappeared in 6.1.106! The sound started to work again.

I couldn’t identify anything relevant in ChangeLog-6.1.106. Nothing reverted or obviously able to have an impact.

But I also couldn’t identify the offensive change in ChangeLog-6.1.101. I had my suspects, which I examined and found nothing peculiar:

  • ASoC: SOF: sof-audio: Skip unprepare for in-use widgets on error rollback
  • ASoC: topology: Do not assign fields that are already set
  • ASoC: topology: Fix references to freed memory

But the same patches have entered 6.9.11 and 6.10, and those kernel lines work(ed) just fine. There was this batch that included the aforementioned patches:

  • tag ‘sound-6.10-rc6’ of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (40 commits)

It’s not related to the build options used by ELRepo, so it will remain a mystery forever.

So I can use again kernel-lt from ELRepo. But can I trust it again?

Building ELRepo’s kernels is more annoying than it should have been, because their SRPMs for the kernel are nosrc. The actual kernel sources must be downloaded from kernel.org. But investigating whether it is an upstream (kernel.org) bug or ELRepo’s bug is impossible on my side as long as I cannot have kernel-lt-6.1.100-1.el9.elrepo.nosrc.rpm, kernel-lt-devel-6.1.100-1.el9.elrepo.x86_64.rpm, kernel-lt-headers-6.1.100-1.el9.elrepo.x86_64.rpm, kernel-lt-modules-6.1.100-1.el9.elrepo.x86_64.rpm, and kernel-lt-modules-extra-6.1.100-1.el9.elrepo.x86_64.rpm. I just happen to still have the 6.1.100 kernel installed, but not the packages that would have allowed me to compare them with the same packages for 6.1.101 (or newer) and possibly find the differences in the building options that introduced the said bug. The bug is there to stay, so I can’t use ELRepo’s kernel-lt anymore.

I tried with ELRepo’s kernel-ml, which is currently 6.10.5, with 6.11.0-rc2 here, in testing.

Based on the aforementioned hint of yashoswalyo, here’s what I did after I unpacked the kernel sources.

Basically, in drivers/media/usb/uvc/uvc_driver.c, I looked for this:

static const struct usb_device_id uvc_ids[] = {

Into this structure, I added the two webcams, the way Giuliano69 did:

	 /* Quanta ACER HD User Facing  0x4035 - Experimental */
	{ .match_flags 	= USB_DEVICE_ID_MATCH_DEVICE
			| USB_DEVICE_ID_MATCH_INT_INFO,
	  .idVendor = 0x0408,
	  .idProduct = 0x4035,
	  .bInterfaceClass = USB_CLASS_VIDEO,
	  .bInterfaceSubClass = 1,
	  .bInterfaceProtocol =	UVC_PC_PROTOCOL_15,
	  .driver_info = (kernel_ulong_t) &(const struct uvc_device_info ) {
							.uvc_version = 0x010a, } }, 
	  
	/* Quanta ACER HD User Facing 4033 - Experimental !! */
	{ .match_flags 	= USB_DEVICE_ID_MATCH_DEVICE
			| USB_DEVICE_ID_MATCH_INT_INFO,
	  .idVendor = 0x0408,
	  .idProduct = 0x4033,
	  .bInterfaceClass = USB_CLASS_VIDEO,
	  .bInterfaceSubClass = 1,
	  .bInterfaceProtocol =	UVC_PC_PROTOCOL_15,
	  .driver_info = (kernel_ulong_t) &(const struct uvc_device_info ) {
							.uvc_version = 0x010a, } },

For tidiness, the idea is to add them after the already existing Quanta USB2.0 models, and before LogiLink.

Since the actual kernel sources are elsewhere, in my case in ~/Downloads, a symlink is needed.

sudo ln -s ~/Downloads/$(uname -r) /usr/src/kernels/$(uname -r)/build

In the same folder (with kernel-ml-devel etc. for the running kernel installed):

$ make -j4 -C /lib/modules/$(uname -r)/build M=$(pwd) modules 
$ sudo rm /lib/modules/$(uname -r)/kernel/drivers/media/usb/uvc/uvcvideo.*
$ sudo cp uvcvideo.ko /lib/modules/$(uname -r)/kernel/drivers/media/usb/uvc/

A reboot was needed.

Nope, it didn’t work. From dmesg:

[    2.606792] usb 3-7: New USB device found, idVendor=0408, idProduct=4033, bcdDevice= 0.04
[    2.606798] usb 3-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.606800] usb 3-7: Product: ACER HD User Facing
[    2.606801] usb 3-7: Manufacturer: Quanta
[    2.606802] usb 3-7: SerialNumber: 01.00.00

But no message from uvcvideo and, more importantly, no /dev/video*!

Previously, this is I was used to:

$ sudo dmesg |grep uvc
[    4.649273] uvcvideo 3-7:1.1: Failed to query (129) UVC probe control : 26 (exp. 48).
[    4.649286] uvcvideo 3-7:1.1: Failed to initialize the device (-5).
[    4.650537] usbcore: registered new interface driver uvcvideo

So, when it doesn’t know what to do with the webcam it still does this, “usbcore: registered new interface driver uvcvideo”, but when it knows… it fails?! Maybe I did something wrong and the new uvcvideo.ko doesn’t work at all?!

As I discovered later, when I tried to create a service that would manually load uvcvideo.ko using insmod, because modprobe can fail, as it looks for dependencies, the culprit was SELinux!

Fuck SELinux. What an abomination! I can’t be bothered to create a custom SELinux policy. The last thing I want is to have SELinux tell me what I can run and what I cannot run, unless I add an exception. I don’t want the equivalent of Windows Defender in Linux! This piece of crap must go:

sudo dnf remove selinux*

Of course, there are less radical ways, such as setting SELINUX=disabled in /etc/selinux/config, or passing a parameter to the kernel:

grubby --update-kernel ALL --args selinux=0

But what’s the logic in having SELinux installed if I don’t want to use it?

It should work now (after a reboot). If it still doesn’t work for you, you can try the approach described below for Kubuntu, that of creating a service.

My problem is that this isn’t practical for me. I cannot run the official kernel because it doesn’t support my Wi-Fi. I cannot run anymore ELRepo’s kernel-lt, because it broke my audio. I can only run ELRepo’s kernel-ml, which will keep upgrading it to newer versions. What is this, Fedora? Arch?

If it hadn’t, as it’s the case with most distros, I could have kept a copy of uvcvideo.ko and I could have used it to overwrite the official one after each kernel update. It should have worked if the kernel version didn’t change more than at the patch level. But it’s unpractical to have to build it so often, and to risk breakages when the mainline kernel goes amok. The entire rationale for using a RHEL clone vanishes.

🟠 VERDICT: As typically this webcam is present on Acer laptops that aren’t fully supported by kernel 5.14, and such laptops will also have the audio broken by the current kernel-lt from ELRepo, this webcam must be made to work with kernel-ml. Those having the 0x4035 webcam should have it work out-of-the-box once kernel-ml becomes 6.11. But is it sensible to use a mainline kernel with an EL9 clone?
😲 UPDATE: kernel-lt 6.1.106 automagically restored the audio!

“AFAIK the kernel 6.11 should get the patch…”

Oh, that one. I could test 6.11.0-rc2, and it didn’t work. The 6.11.0-rc3 wouldn’t have worked either, and you know why?

Only this device has been added…

	  .idVendor = 0x0408,
	  .idProduct = 0x4035,

…but not this one, which is mine!

	  .idVendor = 0x0408,
	  .idProduct = 0x4033,

What the fucking fuck?! The Linux kernel is the most random pile of shit I’ve ever encountered!

Take a look at it:

Not to mention that, architecture-wise, as long as such webcams seem to only need some generic declarations and no specific driver per se, why is the place of such declarations in the kernel? Why can’t it be a text configuration file? Why do I need to rebuild a kernel’s driver, for each and every kernel version, instead of just writing in a config file something to this effect: “hey, the devices with .idVendor = 0x0408 and .idProduct = 0x4035, and with .idVendor = 0x0408 and .idProduct = 0x4033 need to use USB_CLASS_VIDEO and UVC_PC_PROTOCOL_15” and that should be all!

Because, in order to be a Linux kernel architect, or Linus Torvalds himself, a prerequisite condition seems to be that of being a moron!

Kubuntu 24.04

There is a thing to discuss here, as a parenthesis. (K)ubuntu doesn’t rely anymore on /etc/apt/sources.list, but on /etc/apt/sources.list.d/ubuntu.sources and on any other files added to /etc/apt/sources.list.d/. This is not a bad thing per se, but Synaptic, being an old, frozen software, can’t manage such files. So on my test installation, I reverted to a traditional /etc/apt/sources.list:

deb http://archive.ubuntu.com/ubuntu/ noble main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu/ noble-security main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ noble-updates main restricted universe multiverse

deb-src http://archive.ubuntu.com/ubuntu/ noble main restricted universe multiverse
deb-src http://security.ubuntu.com/ubuntu/ noble-security main restricted universe multiverse
deb-src http://archive.ubuntu.com/ubuntu/ noble-updates main restricted universe multiverse

Inside sources.list.d/, I only added PPAs, such as mozillateam-ubuntu-ppa-noble.sources. But that’s for another time. Right now, I wanted to stress that deb-src were enabled when I started doing what follows.

$ sudo apt install dpkg-dev
$ sudo apt-get source linux-modules-extra-$(uname -r)
$ sudo chown `whoami`:`whoami` -R linux-*/
$ cd linux-*/drivers/media/usb/uvc

I then patched uvc_driver.c as previously described.

$ make -j4 -C /lib/modules/$(uname -r)/build M=$(pwd) modules
$ sudo rm /lib/modules/$(uname -r)/kernel/drivers/media/usb/uvc/uvcvideo.*
$ sudo cp uvcvideo.ko /lib/modules/$(uname -r)/kernel/drivers/media/usb/uvc/

After a reboot… nope, things are just as they were with AlmaLinux.

[    1.845533] usb 3-7: new high-speed USB device number 3 using xhci_hcd
[    2.010097] usb 3-7: New USB device found, idVendor=0408, idProduct=4033, bcdDevice= 0.04
[    2.010131] usb 3-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.010143] usb 3-7: Product: ACER HD User Facing
[    2.010153] usb 3-7: Manufacturer: Quanta
[    2.010161] usb 3-7: SerialNumber: 01.00.00

Nothing more, and no /dev/video*!

Let’s try the manual way:

sudo rmmod uvcvideo && sudo modprobe uvcvideo

No error, but dmesg:

[  587.372188] usbcore: deregistering interface driver uvcvideo
[  587.398060] usb 3-7: Found UVC 1.50 device ACER HD User Facing (0408:4033)
[  587.424876] usb 3-7: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.
[  587.427959] uvcvideo 3-7:1.1: Failed to query (129) UVC probe control : 26 (exp. 48).
[  587.427981] uvcvideo 3-7:1.1: Failed to initialize the device (-5).
[  587.428170] usbcore: registered new interface driver uvcvideo

Nice error, “UVC non compliance – GET_DEF(PROBE) not supported. Enabling workaround.” This is as old as kernels 2.6.22-2.6.32! See here (or here). Apparently, a workaround was to change in /drivers/media/video/uvc/uvcvideo.h the line

#define UVC_CTRL_STREAMING_TIMEOUT	1000

to

#define UVC_CTRL_STREAMING_TIMEOUT	3000

But it’s already

#define UVC_CTRL_STREAMING_TIMEOUT	5000

these days! So it must be something else. More recently, this bug was again present in kernel 5.4.0, but fixed since.

And no, this time I can’t blame AppArmor for that! It didn’t block anything, I checked. It’s not as noxious as SELinux. But I have absolutely no idea why manually patching that one file isn’t enough to make the driver work! Apparently, this is what kernel 6.11 does, albeit only for the 0x4035 webcam and not for the 0x4033 one.

💡 Let’s try a new approach in Kubuntu: despite its 6.8.0 kernel, let’s get the complete driver sources patched for 6.5.0 from https://github.com/Kvalme/uvc.

$ git clone https://github.com/Kvalme/uvc
$ cd uvc
$ make

Quick testing:

$ sudo rmmod uvcvideo
$ sudo insmod ./uvcvideo.ko

It worked!

And now, the second idea: since this module is definitely out of kernel, but it still works with the kernel present in Kubuntu 24.04 LTS, we want to make sure it’s loaded instead of the official one, and that it’s not overwritten when the kernel is updated. We need a service for that.

Here’s why the idea of overriding the official driver doesn’t work:

$ sudo rm /lib/modules/$(uname -r)/kernel/drivers/media/usb/uvc/uvcvideo.*
$ sudo cp uvcvideo.ko /lib/modules/$(uname -r)/kernel/drivers/media/usb/uvc/
$ sudo rmmod uvcvideo && sudo modprobe uvcvideo
modprobe: ERROR: could not insert 'uvcvideo': Unknown symbol in module, or unknown parameter (see dmesg)

Yeah, modprobe fails, and this is how the kernel loads it when it starts! So don’t do the above stuff, and leave the official driver, as stupid as it is, in place.

I should recommend you to start this way:

sudo nano /etc/systemd/system/load_uvcvideo.service

But this is how I start:

sudo touch /etc/systemd/system/load_uvcvideo.service

We’re in 2024 (I double-checked, we’re not in 1994), and I’m doing this from within X11, so I prefer to edit such files with FeatherPad or Kate or whatever else. I’ll be asked for my password to save the file (except for openSUSE, which has a non-configured sudo that asks for the root password, but GUI editors would simply fail without asking for any password; yes, this is how stupid openSUSE’s defaults are!).

The contents now:

[Unit]
Description=Load uvcvideo module using insmod
After=network.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c '/usr/sbin/rmmod uvcvideo; /sbin/insmod /home/ludditus/modules/uvcvideo.ko'
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

This assumes that:

  1. I have copied the driver in my home in a folder modules. Adapt to your user name and to the place where you’ll keep uvcvideo.ko.
  2. The original (but useless) uvcvideo.ko is loaded and must be unloaded. If it’s not loaded, that’s fine, too.

Once you make sure the path is correct:

sudo systemctl enable load_uvcvideo.service

Test it:

sudo systemctl start load_uvcvideo.service

It should work.

If you want to use this approach with AlmaLinux, but not with a module built from https://github.com/Kvalme/uvc (which targets Ubuntu), use the module built under AlmaLinux.

🟢 VERDICT: Although the method is unorthodox (using sources for 6.5.0 with 6.8.0), the webcam can be made to work in Ubuntu 24.04 LTS. Those willing to spend their time and port all the changes to 6.8.0 are free to do so. I expect Ubuntu to keep patching 6.8.0 instead of switching to a newer kernel, so this module should work for the years to come (am I too optimistic?). Of course, HWE, OEM, and other extra kernels from Canonical are a whole different ballgame.

openSUSE Leap 15.6

There is a strange thing with this distro. When I tried its KDE and XFCE live ISOs (it’s a mess in here), I noticed that there was no audio device detected, but I thought that the sof-firmware package was missing, and that installing it and rebooting would fix the problem. As rebooting a live ISO would lose any installed packages, I stopped thinking about this issue. (The equivalent packages are called firmware-sof-signed in Debian/Ubuntu and alsa-sof-firmware in the land of Red Hat.)

Well, the installed system still had no audio devices, and the sof-firmware package was already installed! So, WTF, openSUSE, you have a broken 6.4.0 kernel!

BTW, why on the fucking Earth have they updated the kernel used in 15.5, namely 5.14.21 (plus “some individual 19,000 patches”), to 6.4.0, which is EOL upstream since September 2023? Of all possible kernels, why 6.4.0?

Here’s the audio driver failing:

[    7.067170] sof-audio-pci-intel-tgl 0000:00:1f.3: enabling device (0000 -> 0002)
[    7.067388] sof-audio-pci-intel-tgl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100
[    7.067481] sof-audio-pci-intel-tgl 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[    7.074354] sof-audio-pci-intel-tgl 0000:00:1f.3: use msi interrupt mode
[    7.096778] sof-audio-pci-intel-tgl 0000:00:1f.3: hda codecs found, mask 5
[    7.096783] sof-audio-pci-intel-tgl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now
[    7.096786] sof-audio-pci-intel-tgl 0000:00:1f.3: DMICs detected in NHLT tables: 2
[    7.108695] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware info: version 2:2:0-57864
[    7.108697] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
[    7.108700] sof-audio-pci-intel-tgl 0000:00:1f.3: unknown sof_ext_man header type 3 size 0x30
[    7.219387] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware info: version 2:2:0-57864
[    7.219397] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
[    7.232796] sof-audio-pci-intel-tgl 0000:00:1f.3: Topology: ABI 3:22:1 Kernel ABI 3:23:0
[    7.233134] sof-audio-pci-intel-tgl 0000:00:1f.3: error: sink PGA1.0\xc7 not found
[    7.233142] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: topology: add_route failed: -22
[    7.233146] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: topology: could not load header: -22
[    7.233255] sof-audio-pci-intel-tgl 0000:00:1f.3: error: tplg component load failed -22
[    7.233263] sof-audio-pci-intel-tgl 0000:00:1f.3: error: failed to load DSP topology -22
[    7.233266] sof-audio-pci-intel-tgl 0000:00:1f.3: ASoC: error at snd_soc_component_probe on 0000:00:1f.3: -22
[    7.233290] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: failed to instantiate card -22
[    7.233359] skl_hda_dsp_generic: probe of skl_hda_dsp_generic failed with error -22

So this distro is unusable on my newer laptop (on the old one, any distro would work!), but I still wanted to try the webcam patch. I tried it even in the live session with sudo rmmod uvcvideo && sudo modprobe uvcvideo, but I wanted to give it a proper test on an installed system.

$ sudo zypper mr -e repo-source
$ sudo zypper in kernel-source
$ cd /usr/src/linux/drivers/media/usb/uvc/

Patch uvc_driver.c as previously described. OpenSUSE being fucked-up by design, you cannot edit the file with e.g. Kate and be asked for the password upon saving. Also, because the sources are owned by root, we need to do this way:

$ sudo make -j4 -C /lib/modules/$(uname -r)/build M=$(pwd) modules
$ sudo rm /lib/modules/$(uname -r)/kernel/drivers/media/usb/uvc/uvcvideo.*
$ sudo cp uvcvideo.ko /lib/modules/$(uname -r)/kernel/drivers/media/usb/uvc/

Live testing:

$ sudo rmmod uvcvideo && sudo modprobe uvcvideo
modprobe: ERROR: could not insert 'uvcvideo': Unknown symbol in module, or unknown parameter (see dmesg)

Oh, so even when compiled from the matching sources, modprobe fails to load it? dmesg:

[ 2007.121735] usbcore: deregistering interface driver uvcvideo

Even after a reboot, uvcvideo won’t be loaded.

So the fix is to load the module using insmod and a service, like I did in Kubuntu.

But here’s another strange thing: modprobe was able to load the rebuilt module in a live ISO session in the following conditions:

  1. openSUSE-Leap-15.6-KDE-Live-x86_64-Build13.236-Media.iso was used, a build that cannot be downloaded anymore. At the time of writing, openSUSE-Leap-15.6-KDE-Live-x86_64-Build13.323-Media.iso was offered.
  2. The included, hence the running kernel was 6.4.0-150600.21-default #1 SMP PREEMPT_DYNAMIC Thu May 16 11:09:22 UTC 2024.
  3. The available kernel sources were for 6.4.0-150600.23.17-default #1 SMP PREEMPT_DYNAMIC Tue Jul 30 06:37:32 UTC 2024.

So, to put it again:

  • A driver built from the sources of the kernel .23.17 cannot be loaded by modprobe if the running kernel has the same version .23.17.
  • But the same driver from the sources of the kernel .23.17 cannot be loaded by modprobe if the running kernel has the older version .21.

🤡 What KoolAid are drinking those guys at openSUSE?!

Sure thing, insmod can load the driver…

🔴 VERDICT: One can make this webcam work with openSUSE Leap 15.6. But if in my case the audio doesn’t work, I expect other Acer laptops to be impacted too, including some that have a 0408:4033 or a 0408:4035 webcam. So it’s pointless. Not to mention that, while the issue of needing to use insmod is not unique to this distro, the fact that a mismatch in the kernel versions can make modprobe (and the automatic loading on boot) work is, in my view, crazy. I wouldn’t touch openSUSE with a 10-foot pole!

In conclusion, as ChatGPT would say…

☑️ Yeah, it’s totally normal for a Linux user to start patching the kernel and to rebuild drivers.

☑️ Yeah, it’s totally normal to have the drivers in the kernel instead of being able to install them separately. Because it’s so brilliant not to have a stable ABI. If Linus Torvalds and Greg Kroah-Hartman insist on “the very good side effects of having your driver in the main kernel tree,” then they must be true. Oh, it was so wrong when one could just install a driver on Windows as if it were a normal program, regardless of what privilege ring it runs at.

☑️ It’s rocket science to have an Intel audio chip working with some kernels. Maybe its architecture is too complex, or maybe the fucking kernel is too stupid. But the kernel team managed to break something as simple as an audio jack, so why am I wondering?

☑️ It’s also only natural to have such simple struct declarations in the sources instead of an external config file. Why make it simple? Simplicity, flexibility, and modularity hurt and should be avoided. We don’t want “Linux on the Desktop,” but only on servers, in VMs, and in containers.

☑️ Finally, it’s also normal to have a patch enter the kernel some 17 months after the community has created it (the respective kernel is still in the Release Candidate stage, so let’s say 18 months, and even more until that kernel reaches the non-rolling distros). While doing so, make sure you only add support for the device 0x4035 and miss 0x4033, despite the difference being only in this fucking ID! Once again, this is not real code, it’s a fucking declarative structure! Even a half-brained crushed fly would have thought of a mechanism for using an external file to which such generic device declarations could be added!