Closed ZN0N15 closed 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.
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.
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.
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.
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.
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.
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
.
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.
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.
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.
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.
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.
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
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.
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
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!
I recommend adding these new installation instructions for Arch based distros in the README
Good idea, I've just updated the instructions.
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 fileamdgpu.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 viadmseg
.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
toamdgpu.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 withsudo 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 asacpi_backlight=video
in kernel boot parameters. I'm currently trying other kernel versions if it yields the same result.