Problem with Screen Brightness Control on HP Victus Gaming Laptop with AMD Ryzen 5 5600H and Nvidia 3050 GPU [Victus by HP Gaming Laptop 15-fb0xxx]

[vky5]

I've recently purchased an HP Victus gaming laptop (model number: [Victus by HP Gaming Laptop 15-fb0xxx]) with an AMD Ryzen 5 5600H and Nvidia 3050 GPU. I'm trying to dual boot it with Debian 12 (Bookworm) KDE Plasma, but I've been struggling with controlling the screen brightness on Linux.

Here's what I've tried so far:

1. Installed Necessary Packages: Added the amdgpu-core, libdrm-amdgpu-amdgpu1, libdrm-amdgpu-common, libdrm2-amdgpu, xserver-xorg-video-amdgpu, and firmware-amd-graphics packages. The backlight control service (systemd-backlight@backlight:amdgpu_bl1.service) is starting correctly, but changes to the brightness aren't reflected on the screen.
2. Tested Kernel Parameters: I tried various kernel parameters like acpi_backlight=vendor, acpi_backlight=video, acpi_osi=, and video.use_native_backlight=1. Unfortunately, none of these worked. Some caused the brightness option to disappear entirely, while others had no effect.
3. Tried Alternative Backlight Controls and Different Distros: I tested alternative backlight control methods and booted from a live USB with another distro, but nothing resolved the issue.

Currently, the brightness is stuck at maximum, and although adjusting it updates the /sys/class/backlight/amdgpu_bl1/brightness file, the actual screen brightness doesn't change. I'm out of ideas and would appreciate any suggestions or insights from the community on how to fix this issue. Thanks in advance!

 

[MikeWalsh]

Never used Debian as such. The current flagship build of 'Puppy' Linux IS based on Debian 12, but although our package management system pulls from their repos not many people actually use it.

In Puppyland, it's all about the community building and running its own home-brewed applications (we have some very talented coders, and many of these 'home-made' apps are surprisingly good). We've built several brightness controls over the years, all of which work well.

On my elderly 2008 Dell Latitude lappie (yah, I know it's ancient, but that's Puppy's reason for existing - to keep old hardware out of the landfill/recycling system by keeping it still useful), I don't need to use a software brightness control. Dell built them into the keyboard AND hardwired them directly into the backlight system. Result? It works perfectly, all the time, regardless of OS AND it even functions at startup before the OS loads....

it's just a basic lighting system with a dimmer control, when it boils down to it. What could be simpler?


Mike.

 

[vky5]

You almost convinced me to delete debian and install Puppy Linux . But I need debian because I like it. It worked flawlessly on my old laptop and if you have any solution to fix this issue please post that.

Never used Debian as such. The current flagship build of 'Puppy' Linux IS based on Debian 12, but although our package management system pulls from their repos not many people actually use it.

In Puppyland, it's all about the community building and running its own home-brewed applications (we have some very talented coders, and many of these 'home-made' apps are surprisingly good). We've built several brightness controls over the years, all of which work well.

On my elderly 2008 Dell Latitude lappie (yah, I know it's ancient, but that's Puppy's reason for existing - to keep old hardware out of the landfill/recycling system by keeping it still useful), I don't need to use a software brightness control. Dell built them into the keyboard AND hardwired them directly into the backlight system. Result? It works perfectly, all the time, regardless of OS AND it even functions at startup before the OS loads....

it's just a basic lighting system with a dimmer control, when it boils down to it. What could be simpler?


Mike.

 

[MikeWalsh]

@vky5 :-

I wish I DID have some pearls of wisdom to offer, I really do. I left mainstream Linux behind a LONG while ago because for me, with the elderly Compaq desktop I had at the time (2004, with an original AMD Athlon64 X2 - the first dual core they ever built), most distros were dropping support for the ancient ATI Radeon XPress 200 GPU it was 'blessed' with.

An acquaintance mentioned Puppy so I tried it. Lo and behold, absolutely everything worked perfectly, OOTB. I was hooked, and have been there ever since.

I confess, this is the first time I've heard of the /sys/class/backlight/xxxxxxx/brightness file getting updated but then NOT passing on the result to the GPU itself. That's stumped me, that has.

Probably a silly question, but I assume you ARE running the current, up-to-date Nvidia driver, yes? And, um.....doesn't the Plasma desktop have a brightness control somewhere in its mess of settings? I vaguely remember that from the last time I used it, several years ago.....but of course, it may well have changed with newer builds.

My own rig is an HP Pavilion desktop. By and large, they work pretty well with Linux, though they DO have some odd quirks!

Some of the other guys'n'gals ought to be able to help further with this. Hang in there. We usually manage to come up with solutions to most things...


Mike.

 

[vky5]

@vky5 :-

I wish I DID have some pearls of wisdom to offer, I really do. I left mainstream Linux behind a LONG while ago because for me, with the elderly Compaq desktop I had at the time (2004, with an original AMD Athlon64 X2 - the first dual core they ever built), most distros were dropping support for the ancient ATI Radeon XPress 200 GPU it was 'blessed' with.

An acquaintance mentioned Puppy so I tried it. Lo and behold, absolutely everything worked perfectly, OOTB. I was hooked, and have been there ever since.

I confess, this is the first time I've heard of the /sys/class/backlight/xxxxxxx/brightness file getting updated but then NOT passing on the result to the GPU itself. That's stumped me, that has.

Probably a silly question, but I assume you ARE running the current, up-to-date Nvidia driver, yes? And, um.....doesn't the Plasma desktop have a brightness control somewhere in its mess of settings? I vaguely remember that from the last time I used it, several years ago.....but of course, it may well have changed with newer builds.

My own rig is an HP Pavilion desktop. By and large, they work pretty well with Linux, though they DO have some odd quirks!

Some of the other guys'n'gals ought to be able to help further with this. Hang in there. We usually manage to come up with solutions to most things...


Mike.

The brightness is being controlled by amdgpu (integrated) and I have updated drivers for both nvidia and amd but the problem still persists. Plamsa does have a brightness control but it is the internal mechanism that is causing the problem because I have tried other packages as well but it didnt work.

 

[osprey]

The brightness is being controlled by amdgpu (integrated) and I have updated drivers for both nvidia and amd but the problem still persists. Plamsa does have a brightness control but it is the internal mechanism that is causing the problem because I have tried other packages as well but it didnt work.

There's a package in debian named: brightnessctl, which is a small utility to control the brightness
of a screen's backlight. Is that of any use?

The xcalib program has brightness controls for X displays. It takes a bit work to handle, but it's quite powerful.

 

[vky5]

There's a package in debian named: brightnessctl, which is a small utility to control the brightness
of a screen's backlight. Is that of any use?

The xcalib program has brightness controls for X displays. It takes a bit work to handle, but it's quite powerful.

I tried that too. Same problem. The value is changing in file but the screen is not reflecting any changes.

 

[MikeWalsh]

@vky5 :-

Whoah, whoah, whoah..... Hang on a minute.

You're running an Nvidia card here, right? I don't understand this; why on earth did you install all that AMD stuff?

This is a layman's comprehension, but.....as I understand it, most mainstream distros include the open-source OpenGL stack, OOTB. They also include components that allow use of the 'radeon' and 'nouveau' kernel modules (for AMD and Nvidia cards, respectively), which have been integrated into the Linux kernel for many years.......so that discrete cards can still work without the need for "official" drivers to be installed.

When "official" AMD or Nvidia drivers are installed, they tend to overwrite the components of the OpenGL stack with their own proprietary versions. This is fine.....until you decide you want to uninstall the "official" driver for any reason, because instead of the normal OpenGL stack, you're then left with a bastardized concoction, consisting of some open-source stuff and some proprietary......which try their best to work with each other. And fail miserably.

~~~~~~~~~~~~~~~~~~~​

I can't figure out why you say you've got both AMD AND Nvidia official drivers installed. Updating both of these are going to keep overwriting those critical parts of the OpenGL stack, first with one proprietary item.....then by another.

My guess is that you've installed a lot of unnecessary stuff that has overwritten first one part of the stack then another......leaving you with a complete mess that no card could hope to work correctly with. I also suspect that the display server has dropped back to the inbuilt "mode-setting" driver in sheer desperation at trying to get things functional.

(This is a very basic driver. I believe it doesn't include brightness control functionality; I don't think it CAN communicate with the parts of the system that will implement such.)

I could be completely wrong. But I'm betting I'm more right than wrong. I'm no 'gamer'; in my case, my Nvidia card is used more for video rendering than anything else. Regardless of use-case, any GPU needs the right stuff installing at the right point during the process.......especially if you're dealing with "official" drivers.

I know this; you cannot "mix'n'match" Nvidia and AMD drivers on the same system. I can't see there's any possibility of AMD software communicating with an Nvidia GPU....

(shrug...)


Mike.

 

[osprey]

@vky5 :-

Whoah, whoah, whoah..... Hang on a minute.

You're running an Nvidia card here, right? I don't understand this; why on earth did you install all that AMD stuff?

This is a layman's comprehension, but.....as I understand it, most mainstream distros include the open-source OpenGL stack, OOTB. They also include components that allow use of the 'radeon' and 'nouveau' kernel modules (for AMD and Nvidia cards, respectively), which have been integrated into the Linux kernel for many years.......so that discrete cards can still work without the need for "official" drivers to be installed.

When "official" AMD or Nvidia drivers are installed, they tend to overwrite the components of the OpenGL stack with their own proprietary versions. This is fine.....until you decide you want to uninstall the "official" driver for any reason, because instead of the normal OpenGL stack, you're then left with a bastardized concoction, consisting of some open-source stuff and some proprietary......which try their best to work with each other. And fail miserably.

~~~~~~~~~~~~~~~~~~~​

I can't figure out why you say you've got both AMD AND Nvidia official drivers installed. Updating both of these are going to keep overwriting those critical parts of the OpenGL stack, first with one proprietary item.....then by another.

My guess is that you've installed a lot of unnecessary stuff that has overwritten first one part of the stack then another......leaving you with a complete mess that no card could hope to work correctly with. I also suspect that the display server has dropped back to the inbuilt "mode-setting" driver in sheer desperation at trying to get things functional.

(This is a very basic driver. I believe it doesn't include brightness control functionality; I don't think it CAN communicate with the parts of the system that will implement such.)

I could be completely wrong. But I'm betting I'm more right than wrong. I'm no 'gamer'; in my case, my Nvidia card is used more for video rendering than anything else. Regardless of use-case, any GPU needs the right stuff installing at the right point during the process.......especially if you're dealing with "official" drivers.

I know this; you cannot "mix'n'match" Nvidia and AMD drivers on the same system. I can't see there's any possibility of AMD software communicating with an Nvidia GPU....

(shrug...)


Mike.

A valid point to ponder.
According to the specs on the machine here:
https://support.hp.com/au-en/document/ish_6400408-6400457-16
the graphics are specified as the following:

Graphics (integrated) AMD Radeon™ Graphics

Discrete graphics card options
NVIDIA® GeForce® RTX 3050 Ti 4 GB GDDR6 Graphics Card
NVIDIA® GeForce® RTX 3050 4 GB GDDR6 Graphics Card
NVIDIA® GeForce® GTX 1650 4 GB GDDR6 Graphics Card

 

[vky5]

A valid point to ponder.
According to the specs on the machine here:
https://support.hp.com/au-en/document/ish_6400408-6400457-16
the graphics are specified as the following:

Yes, I have an NVIDIA 3050. Even when I do a fresh install of Debian or any other distribution that comes with default drivers, the brightness for that device cannot be controlled. I tried using proprietary drivers for both NVIDIA and AMD, but nothing worked. I read somewhere that /sys/class/backlight/amdgpu_bl1 means that the amdgpu driver is controlling the brightness. I don't know if this is true or not, but here's something interesting...

vky5@alpha5:~$ systemctl status systemd-backlight@backlight:amdgpu_bl1.service

● systemd-backlight@backlight:amdgpu_bl1.service - Load/Save Screen Backlight Brightness of backlight:amdgpu_bl1

     Loaded: loaded (/lib/systemd/system/[email protected]; static)

     Active: active (exited) since Sun 2024-09-08 11:05:09 IST; 8min ago

       Docs: man:[email protected](8)

    Process: 477 ExecStart=/lib/systemd/systemd-backlight load backlight:amdgpu_bl1 (code=exited, status=0/SUCCESS)

   Main PID: 477 (code=exited, status=0/SUCCESS)

        CPU: 20ms

Warning: some journal files were not opened due to insufficient permissions.

vky5@alpha5:~$ sudo journalctl -b -u systemd-backlight@backlight:amdgpu_bl1.service

Sep 08 11:05:09 alpha5 systemd[1]: Starting systemd-backlight@backlight:amdgpu_bl1.service - Load/Save Screen Backlight Brightness of backlight:amdgpu_bl1...

Sep 08 11:05:09 alpha5 systemd-backlight[477]: amdgpu_bl1: Saved brightness 0 is too low; increasing to 12.

Sep 08 11:05:09 alpha5 systemd[1]: Finished systemd-backlight@backlight:amdgpu_bl1.service - Load/Save Screen Backlight Brightness of backlight:amdgpu_bl1.

When I use:

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

in GRUB, the brightness is at its maximum and cannot be controlled. But when I use:

GRUB_CMDLINE_LINUX_DEFAULT="quiet amdgpu.backlight=0"

the brightness becomes completely low (0%), and when I try to control it, it gets slightly brighter, around 5%. In the brightness file, the update appears as if everything is working correctly. As of now, I am using the open-source drivers for both nvidia and amdgpu.

 

[vky5]

can someone help me

Yes, I have an NVIDIA 3050. Even when I do a fresh install of Debian or any other distribution that comes with default drivers, the brightness for that device cannot be controlled. I tried using proprietary drivers for both NVIDIA and AMD, but nothing worked. I read somewhere that /sys/class/backlight/amdgpu_bl1 means that the amdgpu driver is controlling the brightness. I don't know if this is true or not, but here's something interesting...

vky5@alpha5:~$ systemctl status systemd-backlight@backlight:amdgpu_bl1.service

● systemd-backlight@backlight:amdgpu_bl1.service - Load/Save Screen Backlight Brightness of backlight:amdgpu_bl1

     Loaded: loaded (/lib/systemd/system/[email protected]; static)

     Active: active (exited) since Sun 2024-09-08 11:05:09 IST; 8min ago

       Docs: man:[email protected](8)

    Process: 477 ExecStart=/lib/systemd/systemd-backlight load backlight:amdgpu_bl1 (code=exited, status=0/SUCCESS)

   Main PID: 477 (code=exited, status=0/SUCCESS)

        CPU: 20ms

Warning: some journal files were not opened due to insufficient permissions.

vky5@alpha5:~$ sudo journalctl -b -u systemd-backlight@backlight:amdgpu_bl1.service

Sep 08 11:05:09 alpha5 systemd[1]: Starting systemd-backlight@backlight:amdgpu_bl1.service - Load/Save Screen Backlight Brightness of backlight:amdgpu_bl1...

Sep 08 11:05:09 alpha5 systemd-backlight[477]: amdgpu_bl1: Saved brightness 0 is too low; increasing to 12.

Sep 08 11:05:09 alpha5 systemd[1]: Finished systemd-backlight@backlight:amdgpu_bl1.service - Load/Save Screen Backlight Brightness of backlight:amdgpu_bl1.

When I use:

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

in GRUB, the brightness is at its maximum and cannot be controlled. But when I use:

GRUB_CMDLINE_LINUX_DEFAULT="quiet amdgpu.backlight=0"

the brightness becomes completely low (0%), and when I try to control it, it gets slightly brighter, around 5%. In the brightness file, the update appears as if everything is working correctly. As of now, I am using the open-source drivers for both nvidia and amdgpu.

Can someone help me please? @osprey @MikeWalsh

 

[CaffeineAddict]

Can someone help me please?

You can only control the brightness of your desktop screen if the screen supports the DDC protocol. Not all do. For ones that do, KDE’s Powerdevil power management system supports using the DDC protocol to control the screen’s brightness.

Which KDE package to adjust screen brightness?

You can only control the brightness of your desktop screen if the screen supports the DDC protocol. Not all do. For ones that do, KDE’s Powerdevil power management system supports using the DDC protocol to control the screen’s brightness.

discuss.kde.org

 

[vky5]

Which KDE package to adjust screen brightness?

You can only control the brightness of your desktop screen if the screen supports the DDC protocol. Not all do. For ones that do, KDE’s Powerdevil power management system supports using the DDC protocol to control the screen’s brightness.

discuss.kde.org

The HP Victus display does support the DDC (Display Data Channel) protocol, as it utilizes the DisplayPort 1.4 standard through its USB-C port. This allows for communication between the laptop and connected displays, enabling features like automatic detection and configuration of display settings.

This is what HP support told me. Can you look at the logs.