idea: DKMS #6

BayLee4 · 2025-01-06T22:50:25Z

Got the idea from here, but basically it should be possible to leverage DKMS to build the uvc module after patching it, every time the kernel is updated. Hopefully rpi-source exists to retrieve the newly updated kernel source. It would make any package freezing unnecessary, and building the uvc module shouldn't be too demanding even for a raspberry

The text was updated successfully, but these errors were encountered:

awawa-dev · 2025-01-06T22:53:58Z

Hi
Thanks for the idea! There's a problem with the sources because they're currently not tagged with releases: we're supposed to take the official release date and look for the last commit made to rpi-kernel before the release.

BayLee4 · 2025-01-06T23:00:00Z

I see, maybe I misunderstood but I thought that this issue would be fixed by using rpi-source, from the README : rpi-source installs the kernel source used to build rpi-update kernels and the kernel on the Raspberry Pi OS image. This makes it possible to build loadable kernel modules., am I missing something?

awawa-dev · 2025-01-06T23:04:30Z

Unfortunately rpi-source is currently unusable: awawa-dev/HyperHDR#968 (comment)

BayLee4 · 2025-01-06T23:35:38Z

That is very unfortunate, I looked at the code and there may still be hope to use the debian_method, I noticed:

The debianlog path is outdated, it should be : /usr/share/doc/raspi-firmware/changelog.Debian.gz
The fw_rev regular expression is outdated, it should be : raspi-firmware \(1:([0-9.]+)

There may be other parts that needs to be updated, unfortunately I do not have access to a raspberry at the moment

EDIT: The regular expression should probably be closer to raspi-firmware \((1:)?([0-9.]+), but in that case it's now the second group that needs to be extracted, with fw_rev = fw_rev.group(2)

awawa-dev · 2025-01-06T23:47:48Z

They removed versioning completely. You can extract SD image using 7zip and view this file.
The beginning of the changelog.Debian.gz:

raspi-firmware (1:1.20240924-1) bookworm; urgency=medium

  * New upstream version 1.20240924

 -- Serge Schneider <[email protected]>  Tue, 24 Sep 2024 13:34:44 +0100

raspi-firmware (1:1.20240902-1) bookworm; urgency=medium

  * New upstream version 1.20240902

 -- Serge Schneider <[email protected]>  Mon, 02 Sep 2024 12:54:07 +0100

raspi-firmware (1:1.20240529-1) bookworm; urgency=medium

  * d/: Update gbp.conf
  * New upstream version 1.20240529

 -- Serge Schneider <[email protected]>  Wed, 29 May 2024 15:01:05 +0100

raspi-firmware (1:1.20240424-1) bookworm; urgency=medium

  * New upstream version 1.20240424
  * Bump epoch
  * d/gbp.conf: use git-buildpackage for managing the package
  * d/watch: use firmware github releases page as upstream source
  * Add debian/.gitignore
  * Rework kernel and initramfs hooks
  * Remove WLAN firmware
  * d/c: Change Maintainer
  * d/c: Update VCS information
  * d/c: raspi-firmware should support all Raspberry Pi boards
  * d/copyright: don't exclude files

 -- Serge Schneider <[email protected]>  Wed, 24 Apr 2024 17:46:43 +0100

BayLee4 · 2025-01-06T23:55:22Z

It should be fine, the script (with the updated regex) would extract the 1.20240924 version of the raspi-firmware package, and use it to subsequently extract the kernel hash with a call to : https://raw.githubusercontent.com/raspberrypi/firmware/1.20240924/extra/git_hash, automatically

awawa-dev · 2025-01-06T23:58:01Z

OK, I think that should work.

BayLee4 · 2025-01-07T12:02:49Z

Had access to my raspbperry pi today, I submitted a patch to rpi-source to fix the issue : RPi-Distro/rpi-source#37

BayLee4 · 2025-01-07T21:13:16Z

Good news, I got a working PoC!

uvc-1.0
├── dkms-patchmodule.sh
├── dkms.conf
├── p10_dkms.patch
└── rpi-source

1 directory, 4 files

uvc-1.0.zip

dkms.conf:

PACKAGE_NAME="uvc"
PACKAGE_VERSION="1.0"
BUILT_MODULE_NAME[0]="uvc"
MAKE[0]="make -C $kernel_source_dir M=$dkms_tree/$PACKAGE_NAME/$PACKAGE_VERSION/build/src/drivers/media/common uvc.ko && make -C $kernel_source_dir M=$dkms_tree/$PACKAGE_NAME/$PACKAGE_VERSION/build/src/drivers/media/usb/uvc uvcvideo.ko"
CLEAN[0]="rm -f $dkms_tree/$PACKAGE_NAME/$PACKAGE_VERSION/build/src/drivers/media/common/*.*o && rm -f $dkms_tree/$PACKAGE_NAME/$PACKAGE_VERSION/build/src/drivers/media/usb/uvc/*.*o"
BUILT_MODULE_LOCATION[0]="src/drivers/media/common"
DEST_MODULE_LOCATION[0]="/updates/dkms"
BUILT_MODULE_NAME[1]="uvcvideo"
BUILT_MODULE_LOCATION[1]="src/drivers/media/usb/uvc"
DEST_MODULE_LOCATION[1]="/updates/dkms"
AUTOINSTALL="yes"
REMAKE_INITRD="yes"
PRE_BUILD="dkms-patchmodule.sh"

p10_dkms.patch:

diff --git a/drivers/media/common/uvc.c b/drivers/media/common/uvc.c
index 9c0ba7a6c185..249328428ce7 100644
--- a/drivers/media/common/uvc.c
+++ b/drivers/media/common/uvc.c
@@ -10,6 +10,9 @@
 /* ------------------------------------------------------------------------
  * Video formats
  */
+#define UVC_GUID_FORMAT_P010 \
+	{ 'P',  '0',  '1',  '0', 0x00, 0x00, 0x10, 0x00, \
+	 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
 
 static const struct uvc_format_desc uvc_fmts[] = {
 	{
@@ -40,6 +43,10 @@ static const struct uvc_format_desc uvc_fmts[] = {
 		.guid		= UVC_GUID_FORMAT_M420,
 		.fcc		= V4L2_PIX_FMT_M420,
 	},
+	{
+		.guid		= UVC_GUID_FORMAT_P010,
+		.fcc		= V4L2_PIX_FMT_P010,
+	},
 	{
 		.guid		= UVC_GUID_FORMAT_UYVY,
 		.fcc		= V4L2_PIX_FMT_UYVY,
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index f4988f03640a..8998bc2079e0 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -203,6 +203,9 @@ static u32 uvc_v4l2_get_bytesperline(const struct uvc_format *format,
 	case V4L2_PIX_FMT_M420:
 		return frame->wWidth;
 
+	case V4L2_PIX_FMT_P010:
+		return frame->wWidth * 2;
+
 	default:
 		return format->bpp * frame->wWidth / 8;
 	}

dkms-patchmodule.sh:

#!/bin/bash

./rpi-source --download-only --skip-update --dest .

echo "Extracting original source"
tar --wildcards --one-top-level=src --strip-components 1 -xf linux-*.tar.* linux-*/drivers/media/common linux-*/drivers/media/usb/uvc

# The new module version should be increased to allow the new module to be
# installed during kernel upgrade
echo "Increase module version"
sed -i 's/MODULE_VERSION(DRIVER_VERSION)/MODULE_VERSION("999")/g' src/drivers/media/usb/uvc/uvc_driver.c
echo 'MODULE_VERSION("999");' >> src/drivers/media/common/uvc.c

cd src
for i in `ls ../*.patch`
do
  echo "Applying $i"
  patch -p1 < $i
done

The file p10_dkms.patch is a ever so slightly modified version of your patch (it moves the definition of UVC_GUID_FORMAT_P010 from the .h to the .c)

The configuration file is dkms.conf, rpi-source (with RPi-Distro/rpi-source#37 merged) is leveraged to download the kernel source while dkms-patchmodule.sh apply the patch and increment the module version

To use it the package dkms must be installed, then:

sudo cp -r uvc-1.0 /usr/src
sudo dkms install uvc/1.0

Done!

awawa-dev · 2025-01-07T21:49:09Z

Thank you! With rpi-source script working with your fix (even as PR) I will update my Github Action script soon!

BayLee4 · 2025-01-08T22:45:45Z

I made a repository (thank you @ampledata for your boilerplate!) to build the DKMS as a .deb, meaning it can be installed as a regular package offering uvc/uvcvideo modules recompilation each time the kernel is updated, automatically. No need for custom images or packages freezing (or anything else) with this method, it would work on any Raspberry Pi OS installation.

A github actions workflow is used to release the arm64 deb file.

awawa-dev · 2025-01-09T00:03:31Z

The Raspberry Pi operating system contains two kernels: one for the RPi5 and one for the others. I still need to figure out how to chroot them in the emulation so that it compiles both using their specific configuration and produce ready to boot universal image.

BayLee4 · 2025-01-09T00:07:25Z

Why would it be necessary? Isn't the .deb method sufficient to achieve P010 support?

awawa-dev · 2025-01-09T00:09:32Z

While building the image you don't know the final architecture that will be used after the installation. And you must prepare image for that.

BayLee4 · 2025-01-09T00:31:56Z

I see, so both kernel must first be patched at build time. Technically the .deb is agnostic so it would be possible to pre-install it and run a dkms install v4l2-p010-dkms/1.0 automatically at the first boot to trigger the recompilation. But if there's no internet connection it will fail because it needs to download the sources, so... yeah, unfortunately it seems the only safe bet is to first patch both kernel :(

awawa-dev · 2025-01-09T00:43:28Z

Couldn't we prepare and pre-build 2 directories with the dkms modules for 2 different kernel configurations when creating the image? And then just do dkms install from the appropriate directory during the first boot when we already know the architecture?

BayLee4 · 2025-01-09T02:38:43Z

That is a really good idea, it would eliminates the need for internet connection. I think that would work. Are the kernel versions also different or is it only the configurations?

If it's only the configurations I think $kernel_source_dir needs to be changed in dkms.conf to point to the right location each time, which would be at /lib/modules/KERNEL1_OR_KERNEL2/build. I vaguely remember it being /lib/modules/6.6.62+rpt-rpi-v8/build when testing on my RPI4

awawa-dev · 2025-01-09T02:55:37Z

Are the kernel versions also different or is it only the configurations?

Only the configurations are different, they share the same kernel source.

I think RPi5 is using v8-16k sufix but I will test it later. The page size is different and maybe something else too.

BayLee4 · 2025-01-09T11:56:28Z

Only the configurations are different, they share the same kernel source.

I think RPi5 is using v8-16k sufix but I will test it later. The page size is different and maybe something else too.

I see, then this is the best case scenario. I don't think there is a need to modify the conf file anymore. The build flow would be similar to:

Use dkms to build patched modules for both kernels, commands will look like: dkms build --dkmstree "$(pwd)/built_modules_dir" --sourcetree "$(pwd)/dkms_source_dir" -m 4l2-p010-dkms/1.0 -k KERNEL_VERSION_HERE+rpt-rpi-v8(-16k)?
Copy (uvc|uvcvideo).ko.xz from $(pwd)/built_modules_dir to their respective destinations in /lib/modules/KERNEL_VERSION_HERE+rpt-rpi-v8(-16k)?/kernel/drivers, just like you do in your script
Build and pre-install the .deb so it will take care of future kernel upgrades and can easily be updated/removed if not needed anymore at some point in the future, even on existing installations

.
├── built_modules_dir
└── dkms_source_dir
    └── v4l2-p010-dkms-1.0
        ├── README.md
        ├── debian
        │   ├── README.Debian
        │   ├── README.source
        │   ├── changelog
        │   ├── compat
        │   ├── control
        │   ├── copyright
        │   ├── dirs
        │   ├── docs
        │   ├── postinst
        │   ├── prerm
        │   ├── rules
        │   └── source
        │       └── format
        ├── dkms-patchmodule.sh
        ├── dkms.conf
        ├── p10_dkms.patch
        └── rpi-source

6 directories, 17 files

In the end it seems there will be no need for first-time boot commands

awawa-dev · 2025-01-09T16:09:24Z

I modified the script to use your improved rpi-source script https://github.com/awawa-dev/P010_for_V4L2/tree/dkms
Since I already preinstall the UVC modules when building the image, wouldn't dkms add ... be enough for the future if the kernel was upgraded?
I don't quite know where to get the kernel configuration when the dkms build/install event is triggered. /proc/config.gz will already be current at this stage or do I need to detect RPi5 vs. other and invoke make bcm2712_defconfig ... or make bcm2711_defconfig ... to use correct default config? Probably here:

P010_for_V4L2/dkms/dkms.conf

Line 4 in 9671053

    
           MAKE[0]="make -C $kernel_source_dir M=$dkms_tree/$PACKAGE_NAME/$PACKAGE_VERSION/build/src/drivers/media/common uvc.ko && make -C $kernel_source_dir M=$dkms_tree/$PACKAGE_NAME/$PACKAGE_VERSION/build/src/drivers/media/usb/uvc uvcvideo.ko"

BayLee4 · 2025-01-09T18:16:13Z

Since I already preinstall the UVC modules when building the image, wouldn't dkms add ... be enough for the future if the kernel was upgraded?

Absolutely. The idea behind the .deb is that it would be easily upgradeable in case where for instance rpi-sourcebreaks again and needs to be updated. Or if another module needs patching. Or if at some point it's not necessary anymore, so it could be removed like any package. It's just future-proofing but it's not necessary by any means.

I don't quite know where to get the kernel configuration when the dkms build/install event is triggered. /proc/config.gz will already be current at this stage or do I need to detect RPi5 vs. other and invoke make bcm2712_defconfig ... or make bcm2711_defconfig ... to use correct default config? Probably here:

I don't think it would be necessary to run these commands at all. The commands described in #6 (comment) should be sufficient to build the modules for both kernel and installing them

awawa-dev · 2025-01-10T02:22:46Z

Find one file that is missing in downloaded 6.6.62 sources ;-)

I don't know if I should be angry or cry, so for now I'll take a break to clear my mind 😉 They really had to do it in this small revision release and they didn't wait with such a big thing until 7.x...

awawa-dev · 2025-01-10T02:24:55Z

On the other hand why 2023?

BayLee4 · 2025-01-10T11:08:36Z

Wow, where does that hash come from? It's a bit strange, and as you noticed it dates from two years ago, which doesn't make sense : raspberrypi/linux@0afb5e9

Only thing I can think of is that raspi-firmware is out of date, meaning the changelog is too, meaning we extract an outdated hash. But that would still be strange, since you use a recent image 🧐 Well, if the diagnostic is correct a sudo apt upgrade raspi-firmware will do the trick, but still.

I don't know if I should be angry or cry, so for now I'll take a break to clear my mind 😉 They really had to do it in this small revision release and they didn't wait with such a big thing until 7.x...

No need to cry! The breaking commit dates from less than two years ago, the patch is actually up-to-date, it was that infamous hash that was not : raspberrypi/linux@466be4c

So no worries, the patch need no modification at all ✌️

BayLee4 · 2025-01-10T11:33:04Z

Another possibility is that rpi-source is using the rpi-update method instead of the debian one, removing the -q parameter will allow to see that in the logs. Doesn't make it any less strange though.

BayLee4 · 2025-01-10T11:50:36Z

Looking at the github actions logs it seems the correct kernel version is downloaded, on which machine/environment does the problem occur?

awawa-dev · 2025-01-10T12:02:22Z

Hello @BayLee4 😃
A new day, new energy and optimism and of course new ideas 😄 I am sending full update logs: https://pastebin.com/quZrsLv2
/var/lib/dkms/v4l2_p010/1.0/build/src/drivers/media/common/uvc.c did not exist initially, that is why this error from the build.
I tested on the RPi4 after flashing SD image and the error is during updating kernel using sudo apt upgrade raspberrypi-bootloader raspberrypi-kernel raspberrypi-kernel-headers.

awawa-dev · 2025-01-10T12:08:46Z

Oh...that's the problem:

wrong change-log from the past and it's 'bullseye' not 'bookworm' release

awawa-dev · 2025-01-10T12:48:51Z

Clean install:
https://pastebin.com/6A1uzm8Q
and 6.1.21 out of nowhere

I suspect they probably hid the 3rd kernel based on bullseye for the old devices but it breaks the DKMS phase and blocks it there.

BayLee4 · 2025-01-10T12:56:33Z

Hi @awawa-dev 👋

wrong change-log from the past and it's 'bullseye' not 'bookworm' release

Wow that was effectively unexpected... How is it even possible? I did my tests on a fresh Raspberry Pi OS (64-bit) and never encountered that issue 🤔

Regardless, I updated my fix to rpi-source : RPi-Distro/rpi-source@712b64f, it now tries the updated changelog path first (in case both exists as they do now), and also uses the debian method by default. It will avoid further unsolicited "surprises" in case it suddenly decides to use the untested rpi-update method 😮‍💨

BayLee4 · 2025-01-10T13:00:04Z

Oh, maybe that's happening because raspberrypi-bootloader is now an obsolete package in Bookworm? Is it installed by default?

awawa-dev · 2025-01-10T13:40:00Z

Of course you're right, my mistake 🤦 🤦 🤦 🤦 🤦 ... so I had previously upgraded (actually installed it) a package that was no longer supported, although on the other hand I didn't notice any direct warnings there and I was relying on old scripts found on the net. And it froze the Kernal on version 6.1.21, at least in the changelog. A really interesting story that teaches us once again that we need to be careful at every step 😔
Now it builds for 6.6.62, although DKMS still forces it to build for 6.1.21 and here it crashes, which then blocks DKMS with an unfinished phase. But that's something I'll deal with later.

BayLee4 · 2025-01-10T14:36:07Z

Of course you're right, my mistake 🤦 🤦 🤦 🤦 🤦 ... so I had previously upgraded (actually installed it) a package that was no longer supported, although on the other hand I didn't notice any direct warnings there and I was relying on old scripts found on the net. And it froze the Kernal on version 6.1.21, at least in the changelog.

I just verified and the packages are indeed present in their bookworm distribution repository, where they do not belong, alongside a ton of other bullseye packages: https://archive.raspberrypi.org/debian/dists/bookworm/main/binary-arm64/Packages

That is clearly an oversight on their part, renaming packages + still shipping obsolete ones with the same old name is a recipe for disaster.

A really interesting story that teaches us once again that we need to be careful at every step 😔

Well, rpi-source is now more reliable than it was before, that's still a win 🤷‍♂️ Sooner or later it would have caused problems, so discovering the issue now in the testing phase is much preferable.

Now it builds for 6.6.62, although DKMS still forces it to build for 6.1.21 and here it crashes, which then blocks DKMS with an unfinished phase. But that's something I'll deal with later.

I think that's because raspberrypi-kernel and raspberrypi-kernel-headers are also obsolete packages, 6.1.21 was the bullseye kernel version. For upgrading only already installed packages without unwillingly installing new ones sudo apt-get --only-upgrade install <packagename> may work, but I'm not really sure for meta-packages such as kernels.

I believe the current names are linux-image-rpi-v8 and linux-headers-rpi-v8. Those must always be updated at the same time as raspi-firmware, since the kernel hash is taken from its changelog.

awawa-dev · 2025-01-11T18:54:43Z

Hi @BayLee4 😃
Hope you have a great weekend. I added some protective measures for giddy users or victims of old scripts or bad packages in the official repo like me 😉 Now the script blocks building modules for kernels older than 6.6.x and detection of whether raspberrypi-bootloader is installed was added. At least this should give us some hints why DKMS may not work on a particular system.

And wow...finally after some minor changes and fixes the Github Action script built me an image that works correctly.
So it auto-magically builds a patched uvc module (P010) when upgrading the kernel.

sudo apt update && sudo apt upgrade => works OK, kernel upgraded to 6.6.62

sudo apt upgrade raspberrypi-kernel raspberrypi-kernel-headers => at some point DKMS throws an error because of BUILD_EXCLUSIVE_KERNEL rule (protection agains 6.1.21) and AUTOINSTALL. But it works, kernel upgraded to 6.6.62

then sudo apt upgrade raspberrypi-bootloader => the script detects raspberrypi-bootloader and throws an error

It only worked thanks to you, because you yourself proposed the idea and basically prepared all the necessary scripts.
I saw your PR, thank you. I'll move my changes there later. I would rather avoid having to build the DKMS module by the user on first run and build everything in Github Action... you really don't want to know how slow SD cards some people use, slow enough that the v4l2 module starts after HyperHDR 😉 I have some problems with starting DKMS under chroot but I'll try to work around them by forcing the architecture and configuration.

BayLee4 · 2025-01-12T11:12:09Z

Hi @BayLee4 😃 Hope you have a great weekend. I added some protective measures for giddy users or victims of old scripts or bad packages in the official repo like me 😉 Now the script blocks building modules for kernels older than 6.6.x and detection of whether raspberrypi-bootloader is installed was added. At least this should give us some hints why DKMS may not work on a particular system.

Hi @awawa-dev 👋
Good weekend, got hard diffed by the dkms/chroot/github-actions combo but in the end it worked out so I'm not complaining, hope yours was great too.

Just saw your nice raspberrypi-bootloader detection, rpi-source is now handling that case gracefully (also fixes a potential issue with rpi-update), but as it signifies to the user that something is wrong with their system it's still worth keeping it just in case.

And wow...finally after some minor changes and fixes the Github Action script built me an image that works correctly. So it auto-magically builds a patched uvc module (P010) when upgrading the kernel.

sudo apt update && sudo apt upgrade => works OK, kernel upgraded to 6.6.62

sudo apt upgrade raspberrypi-kernel raspberrypi-kernel-headers => at some point DKMS throws an error because of BUILD_EXCLUSIVE_KERNEL rule (protection agains 6.1.21) and AUTOINSTALL. But it works, kernel upgraded to 6.6.62

then sudo apt upgrade raspberrypi-bootloader => the script detects raspberrypi-bootloader and throws an error

Great! Using BUILD_EXCLUSIVE_KERNEL was a clever idea, I didn't know that option existed.

In the PR I install dkms with --no-install-recommends, which has the effect to not install the obsolete raspberrypi-kernel-headers package.

To make it short, dkms is installed from the debian bookworm repository which recommends linux-headers, and thanks to the clusterfuck that is the raspberry pi os bookworm repository it is still resolved to raspberrypi-kernel-headers instead of linux-headers-rpi-v8. Yeah, nice surprise isn't it. Using --no-install-recommends makes it so the former is not wrongfully installed.

But thanks to your BUILD_EXCLUSIVE_KERNEL addition, even if for some reason it is at some point, it will still be handled correctly.

It only worked thanks to you, because you yourself proposed the idea and basically prepared all the necessary scripts. I saw your PR, thank you. I'll move my changes there later. I would rather avoid having to build the DKMS module by the user on first run and build everything in Github Action... you really don't want to know how slow SD cards some people use, slow enough that the v4l2 module starts after HyperHDR 😉 I have some problems with starting DKMS under chroot but I'll try to work around them by forcing the architecture and configuration.

And I want to thank you for your hard work on HyperHDR, none of that would have been possible without it 😉

In addition to the above, the PR fixes the dkms build under github-actions/chroot, I tried to change as little as possible to what you did originally. I'm satisfied with the result, so no more force-push!

I think my mission ends here, please do the changes you see fit to the PR. I take this opportunity to thank you again, and wish you all the best for the future.

awawa-dev · 2025-01-12T19:50:04Z

Thank you very much. This is much more than I expected. I have already merged your changes. It seems to me that I still need to build the configs because the architecture alone may not be enough. In any case, they recommend doing this in their instructions https://www.raspberrypi.com/documentation/computers/linux_kernel.html make bcm2711_defconfig/bcm2712_defconfig. This will complicate the script a bit and will increase the image building time, but now after your changes it should be easy and I can handle it. Thank you very much again 😃

BayLee4 · 2025-01-13T00:24:34Z

It seems to me that I still need to build the configs because the architecture alone may not be enough.

Are you referring to the -a arm64 in the dkms build instruction? If so, don't worry it is completely unnecessary. It's a leftover from some experimenting, I should have deleted it. The configs are already there, under /usr/lib/linux-image-6.6.51+rpt-rpi-(2712|v8)/.config, and they are already detected and used correctly by the build command, no need to worry on that front.

(If you're curious, the experience was to try to get rid of the -k $KERNEL part to simplify the workflow even more, but when doing so dkms will build for all kernels including the github-actions runner kernel, so I tried to rule that one out with -a arm64 but that didn't work, the big sad)

awawa-dev · 2025-01-13T11:52:32Z

This was the last piece of the puzzle that I was missing: confirmation that the kernel configs exist and DKMS finds them correctly, so there is no need to build them or point them for DKMS manually. Thank you very much for clearing up my doubts 👍

awawa-dev mentioned this issue Jan 10, 2025

Implement zigbee2mqtt protocol awawa-dev/HyperHDR#1024

Merged

awawa-dev linked a pull request Jan 18, 2025 that will close this issue

Patch UVC with P010 support using DKMS #9

Merged

awawa-dev closed this as completed in #9 Jan 18, 2025

idea: DKMS #6

idea: DKMS #6

Comments

BayLee4 commented Jan 6, 2025 • edited Loading

awawa-dev commented Jan 6, 2025 • edited Loading

BayLee4 commented Jan 6, 2025 • edited Loading

awawa-dev commented Jan 6, 2025

BayLee4 commented Jan 6, 2025 • edited Loading

awawa-dev commented Jan 6, 2025

BayLee4 commented Jan 6, 2025 • edited Loading

awawa-dev commented Jan 6, 2025

BayLee4 commented Jan 7, 2025

BayLee4 commented Jan 7, 2025 • edited Loading

awawa-dev commented Jan 7, 2025

BayLee4 commented Jan 8, 2025 • edited Loading

awawa-dev commented Jan 9, 2025 • edited Loading

BayLee4 commented Jan 9, 2025

awawa-dev commented Jan 9, 2025

BayLee4 commented Jan 9, 2025 • edited Loading

awawa-dev commented Jan 9, 2025 • edited Loading

BayLee4 commented Jan 9, 2025 • edited Loading

awawa-dev commented Jan 9, 2025

BayLee4 commented Jan 9, 2025 • edited Loading

awawa-dev commented Jan 9, 2025 • edited Loading

BayLee4 commented Jan 9, 2025 • edited Loading

awawa-dev commented Jan 10, 2025

awawa-dev commented Jan 10, 2025

BayLee4 commented Jan 10, 2025

BayLee4 commented Jan 10, 2025 • edited Loading

BayLee4 commented Jan 10, 2025

awawa-dev commented Jan 10, 2025

awawa-dev commented Jan 10, 2025 • edited Loading

awawa-dev commented Jan 10, 2025 • edited Loading

BayLee4 commented Jan 10, 2025 • edited Loading

BayLee4 commented Jan 10, 2025 • edited Loading

awawa-dev commented Jan 10, 2025

BayLee4 commented Jan 10, 2025 • edited Loading

awawa-dev commented Jan 11, 2025

BayLee4 commented Jan 12, 2025 • edited Loading

awawa-dev commented Jan 12, 2025

BayLee4 commented Jan 13, 2025 • edited Loading

awawa-dev commented Jan 13, 2025

BayLee4 commented Jan 6, 2025 •

edited

Loading

awawa-dev commented Jan 6, 2025 •

edited

Loading

BayLee4 commented Jan 6, 2025 •

edited

Loading

BayLee4 commented Jan 6, 2025 •

edited

Loading

BayLee4 commented Jan 6, 2025 •

edited

Loading

BayLee4 commented Jan 7, 2025 •

edited

Loading

BayLee4 commented Jan 8, 2025 •

edited

Loading

awawa-dev commented Jan 9, 2025 •

edited

Loading

BayLee4 commented Jan 9, 2025 •

edited

Loading

awawa-dev commented Jan 9, 2025 •

edited

Loading

BayLee4 commented Jan 9, 2025 •

edited

Loading

BayLee4 commented Jan 9, 2025 •

edited

Loading

awawa-dev commented Jan 9, 2025 •

edited

Loading

BayLee4 commented Jan 9, 2025 •

edited

Loading

BayLee4 commented Jan 10, 2025 •

edited

Loading

awawa-dev commented Jan 10, 2025 •

edited

Loading

awawa-dev commented Jan 10, 2025 •

edited

Loading

BayLee4 commented Jan 10, 2025 •

edited

Loading

BayLee4 commented Jan 10, 2025 •

edited

Loading

BayLee4 commented Jan 10, 2025 •

edited

Loading

BayLee4 commented Jan 12, 2025 •

edited

Loading

BayLee4 commented Jan 13, 2025 •

edited

Loading