d4mur / victus_brightness

3 stars 0 forks source link

Patch doesnt seem to be working #1

Closed ZN0N15 closed 1 month ago

ZN0N15 commented 1 month ago

Hi, I've recently followed your workaround to fix this issue regarding low brightness in HP Victus Laptops.

I have followed the steps to your patch correctly, made sure I'm using the same kernel version, in this case I'm using kernel 6.10.6-arch1 and I've downloaded the source for it. I've completed the patching and compiling of the kernel without issue.

But then I stumbled on an issue trying to rename the existing amdgpu.ko module with the command sudo cp /lib/modules/$(uname -r)/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko /lib/modules/$(uname -r)/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko.bak It returned with no file existing. I manually checked the directory to the amdgpu module, and sure enough that file did not exist, but instead an archived file amdgpu.ko.zst which contained the amdgpu.ko file does exist. I'm not an expert in kernel modules so I'm not really sure if this is normal, or if it should be archived at all. But I was sure that my system was using amdgpu drivers and made sure it was actually running via dmseg.

So following the next steps I just renamed the archive to something else and copied the newly patched and compiled amdgpu.ko to that directory and reboot my system. Sure enough it did not work, my brightness is still low.

I've done a couple troubleshooting like trying to archive the newly patched amdgpu.ko to amdgpu.ko.zst like the existing one. This also did nothing. But what I have noticed is that after booting with the patched module, trying to change brightness does not work for a few seconds, and then works again. If you wish to see any logs please feel free to say.

Update: So I've basically confirmed using sudo modinfo amdgpu | grep -i filename that it is loading the newly patched amdgpu.ko: filename: /lib/modules/6.10.6-arch1-1/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko.zst. So tried another method and rebuilt Initramfs with sudo mkinitcpio -P and rebooted. My laptop now goes to its true Max brightness, however, now I cannot adjust or lower the brightness at all. Which is the same result as acpi_backlight=video in kernel boot parameters. I'm currently trying other kernel versions if it yields the same result.

d4mur commented 1 month ago

Try checking if you have a directory named amdgpu_bl1 inside /sys/class/backlight. If it exists, but the brightness still doesn’t work, try applying this other patch. It adds some debug prints to the dmesg log. After that, run: sudo dmesg | grep VICTUS_DEBUG

and check if the original limit values are being bypassed.

max_brightness_debug.patch.txt

ZN0N15 commented 1 month ago

Inside /sys/class/backlight I have a directory named amdgpu_bl2.

I have applied the new patch you provided, but the results are still the same sadly. I've even tried different kernel versions.

Running sudo dmesg | grep VICTUS_DEBUG doesn't give any output at all. So I'm now skeptical if the patch is even working on my machine.

I've also learned that simply rebooting after copying the new amdgpu.ko doesn't properly unload the module. At least on Arch, I have to manually rebuild initramfs via sudo mkinitcpio -P in order to properly unload the module. After doing so I'm definitely certain that the new module has loaded, because after boot it goes to the true Max brightness, however I can no longer adjust the brightness at all.

d4mur commented 1 month ago

If you don't see any VICTUS_DEBUG lines in the dmesg log, I'm not sure if the system is loading the new module.

In the /sys/class/backlight directory, do you have any other directories besides amdgpu_bl2?

Have you tried changing the brightness by writing directly to the brightness file? For example: echo 100 | sudo tee /sys/class/backlight/amdgpu_bl2/brightness or echo 200 | sudo tee /sys/class/backlight/amdgpu_bl2/brightness

So, let me get this straight: since you're using a compressed kernel, you compressed the patched module with something like: zstd drivers/gpu/drm/amd/amdgpu/amdgpu.ko

and then copied the compressed module with: sudo cp drivers/gpu/drm/amd/amdgpu/amdgpu.ko.zst /lib/modules/$(uname -r)/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko.zst Is that correct?

I don’t have experience with Arch, but one thing that comes to mind is that you could try running: sudo depmod -a after copying the patched amdgpu.ko.zst, so that the symbol list gets updated.

ZN0N15 commented 1 month ago

In the /sys/class/backlight directory, do you have any other directories besides amdgpu_bl2?

Nope. But I found something interesting. After applying the patch via the steps I've followed, which causes my screen to get stuck to max brightness after reboot, amdgpu_bl2 folder no longer exists in /sys/class/backlight directory. This might be the reason why I could no longer change the brightness. The new module isnt working correctly.

So, let me get this straight: since you're using a compressed kernel, you compressed the patched module

Yes, but I don't necessarily have to I think. I've tried just copying the amdgpu.ko file without compression and it does seem to load it. sudo modinfo amdgpu | grep -i filename my output is filename: /lib/modules/6.10.6-arch1-1/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko so it technically detects the new module file regardless of compression. Some distros like Arch have most of their kernel modules compressed by default to save space.

I have actually done sudo depmod -a and other commands to restart the module like sudo modprobe -r amdgpu and sudo modprobe amdgpu but nothing seems to work unfortunately.

Can I ask which Distro and Kernel version you use so I can try it? I'm only on a fresh install of arch just to test this workaround so I'm not really concerned with losing anything from distro hopping.

d4mur commented 1 month ago

Ok, try checking if the module is actually loaded by running: lsmod | grep amdgpu

As a test, you could try restoring the original backed-up module to see if it returns to the original low-brightness condition.

Can I ask which Distro and Kernel version you use so I can try it? I'm only on a fresh install of arch just to test this workaround so I'm not really concerned with losing anything from distro hopping.

I’m using Slackware Current with kernel 6.10.6.

EDIT In this Arch guide, it states:

In order to compile and load our module cleanly, we must find the value of the EXTRAVERSION component of the current kernel version number so we can match the version number exactly in our kernel source ... Once the EXTRAVERSION value is known, we prepare the source for module compilation: $ make EXTRAVERSION=\ modules_prepare

I’m not sure if this could be helpful.

ZN0N15 commented 1 month ago

Ok, try checking if the module is actually loaded by running: lsmod | grep amdgpu

It returns nothing after copying the new module. So it's definitely not being loaded correctly.

As a test, you could try restoring the original backed-up module to see if it returns to the original low-brightness condition.

This does indeed restore it back to the original low brightness condition.

In this Arch guide

Thanks for the heads up on the manual. I've just done this method by adding the extra command make EXTRAVERSION=-arch1 SUBDIRS=drivers/gpu/drm/amd/amdgpu/ modules on both Arch and Manjaro but still no luck. I've also recently tried it on Fedora Linux but results are still the same. I may have to try Slackware if it's the only known Distro for this patch to work.

d4mur commented 1 month ago

It returns nothing after copying the new module. So it's definitely not being loaded correctly.

OK. In a previous message, you mentioned that you tried to load the module manually with sudo modprobe amdgpu. Did it return any errors?

I may have to try Slackware if it's the only known Distro for this patch to work.

The patch is very simple; it only changes two numeric values, so I doubt it would be incompatible with a specific distro. At this point, I think the issue isn’t with the patch itself but the procedure used to build the module and load it into the system. Maybe if you rebuilt the original module (without patching it) using the same procedure, you would encounter the same problem.

One of the main differences with Slackware is that it uses a vanilla kernel, without any modifications, while most popular distros typically apply several patches. Theoretically, if one of these patches modified the amdgpu driver, there could be issues when applying my patch. However, I don’t think this is the case because if it were, you would have received an error when applying it with patch -p1 < max_brightness.patch .

ZN0N15 commented 1 month ago

OK. In a previous message, you mentioned that you tried to load the module manually with sudo modprobe amdgpu. Did it return any errors?

When I said this previously the module wasnt being loaded so the modprobe amdgpu returned without errors. Only when I had to manually update initramfs to load the module after boot that now I'm getting an error: modprobe: ERROR: could not insert 'amdgpu': Exec format error which according to the archwiki guide says that the error is due to EXTRAVERSION not set correctly (which is strange since I followed the guide explicitly adding the extraversion for module compilation)

I think the issue isn’t with the patch itself but the procedure used to build the module and load it into the system

After many trial and errors with no success I've already come to this same conclusion. I'm not exactly sure what the problem is, if the downloaded kernel source code is incorrect, which I highly doubt since I've cloned it from their official github with the exact version. And I've basically followed the archwiki guide on building the kernel module without issues.

Strangely the newly compiled amdgpu.ko module is always the same size at over 500mb after the build. After compression to zst its about 100mb. Is the file supposed to be this big? For comparison the stock amdgpu module is only 4mb.

d4mur commented 1 month ago

Did you also copy the original .config as stated in the Arch guide?

zcat /proc/config.gz > .config
make oldconfig

Strangely the newly compiled amdgpu.ko module is always the same size at over 500mb after the build. After compression to zst its about 100mb. Is the file supposed to be this big?

The file size seems quite large. My uncompressed amdgpu.ko is 22 MB.

Another thing you could try is following all the instructions in the Arch guide step by step after applying the patch with patch -p1 < max_brightness.patch .

For example, I noticed that the guide uses the M parameter instead of SUBDIR for building the module, so you could try:

make M=drivers/gpu/drm/amd/amdgpu

Other commands in the guide could be crucial for a successful build.

ZN0N15 commented 1 month ago

Did you also copy the original .config as stated in the Arch guide?

Yes. That's how I've always done it. I've even tried doing make olddefconfig to set every option in config to default values. Still no luck.

make M=drivers/gpu/drm/amd/amdgpu

I have actually tried this with M instead of SUBDIRS as noted in the Archwiki guide and it gives me errors saying it's missing dependencies. This is one of those errors I get; WARNING: Module.symvers is missing unresolved symbol errors. You can set KBUILD MODPOST WARN=1 to turn errors into warnings and then lists those missing dependencies that has to be compiled first.

Apparently, amdgpu is linked to dependencies outside of the drm module, so I have to actually build/compile the entire kernel first, in order to build amdgpu. Which is unfortunate because it takes like 30 min to build the whole thing. And it might be why the file is so big.

d4mur commented 1 month ago

so I have to actually build/compile the entire kernel first, in order to build amdgpu. Which is unfortunate because it takes like 30 min to build the whole thing. And it might be why the file is so big.

It's the same on Slackware: when I run make SUBDIRS=drivers/gpu/drm/amd/amdgpu/ modules for the first time, it rebuilds the whole kernel. But after that, when I run it again, it rebuilds only the amdgpu module. So, I don't think this is the reason for the large file size.

ZN0N15 commented 1 month ago

I believe I've narrowed down the issue. The output I get with sudo depmod amdgpu I get an error depmod: ERROR: Bad version passed amdgpu which indicates that the kernel source I compiled amdgpu with doesnt match the version of my kernel. And with sudo modprobe amdgpu I get modprobe: ERROR: could not insert 'amdgpu': Exec format error which according to the archwiki quide says its possibly the EXTRAVERSION not set correctly.

I'm confused as to where I should be getting the kernel source since I did try compiling from both the vanilla kernel found in kernel.org and the kernel from official arch github page with both having the same version I have.

d4mur commented 1 month ago

Use the sources downloaded from the Arch repository. Inside the sources directory, open the Makefile and check if the version at the top matches the output of uname -r. For example, if uname -r returns:

6.10.8-arch1

you should see something like this in the Makefile::

VERSION = 6
PATCHLEVEL = 10
SUBLEVEL = 8
EXTRAVERSION = -arch1

If they match, then the sources are correct, and the issue might be related to something in the build process.

EDIT I noticed that in a previous message you mentioned this path:

filename: /lib/modules/6.10.6-arch1-1/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko.zs

So maybe you should try:

make EXTRAVERSION=-arch1-1 SUBDIRS=drivers/gpu/drm/amd/amdgpu/ modules

instead of:

make EXTRAVERSION=-arch1 SUBDIRS=drivers/gpu/drm/amd/amdgpu/ modules

ZN0N15 commented 1 month ago

If they match, then the sources are correct, and the issue might be related to something in the build process.

You might be right. I've checked everything and they all match. I have even tried make EXTRAVERSION=-arch1-1 SUBDIRS=drivers/gpu/drm/amd/amdgpu/ modules and make EXTRAVERSION=-arch1-1 M=drivers/gpu/drm/amd/amdgpu/ modules resulting in the same issue.

I made a mistake earlier when I said sudo depmod amdgpu would output depmod: ERROR: Bad version passed amdgpu this only happens when in the original (low brightness) amdgpu module. After installing the newly patched module and a restart, my output for sudo depmod -a and sudo depmod amdgpu shows the error depmod: FATAL: Module amdgpu.ko.zst not found. I've even manually checked the directory and the file is definitely there. Copying back the original module would even bring it back to low brightness.

I'm not exactly sure which part of the build process is creating this issue. It might be the cause as to why the newly compiled amdgpu.ko file results in a 500mb size.

EDIT I did another method which I thought could work, without any human errors. I cloned the PKGBUILD of the archlinux kernel from gitlab. Since that PKGBUILD already does all the necessary processes to install dependencies, clone the exact kernel source and compiling of the kernel via makepkg command. This somehow still did not work. The amdgpu.ko file still resulted in 500mb size and the module doesnt load properly as usual after installing.

d4mur commented 1 month ago

I installed Arch on an external SSD so I could run some tests. I encountered the same issues (a large, non-loadable module), so I tried the different approach: I rebuilt the entire kernel following this guide. I edited the PKGBUILD file to add the instructions for applying my patch.

At the end of the process, two packages were generated (one for the kernel and one for the headers). After installing them, updating the GRUB configuration, and rebooting with the new kernel, the patched module worked, and the brightness now uses the full range.

If you want to install this kernel, you can download it from here: kernel, headers

EDIT This is the PKGBUILD file I used, which includes the instructions to patch the amdgpu driver PKGBUILD.zip

ZN0N15 commented 1 month ago

This is the PKGBUILD file I used, which includes the instructions to patch the amdgpu driver PKGBUILD.zip

Can confirm this actually works now! Though I still fail to see why this method works and how its different from just manually building and copying the patched module like in previous methods. Nonetheless the workaround works as intended, I get full control of the brightness range.

I recommend adding these new installation instructions for Arch based distros in the README. Thanks again!

d4mur commented 1 month ago

I recommend adding these new installation instructions for Arch based distros in the README

Good idea, I've just updated the instructions.