Screen goes black during boot with hybrid GPU

[paucommit]

Running omarchy on my Razer Blade 14 (2025) and during boot (just when plymouth pops up if enabled) the screen goes black if I am running on battery.

I have tried changing the HOOKS order, disabling drivers and almost everything I could think of.

The only solution that works is either is to have the laptop plugged in or disable the amdgpu (then I lose usb c display compatibility).

Installed omarchy following the tutorial on a fresh arch.

[ryanrhughes]

Does the screen go black immediately when the Plymouth loader appears, after you've entered your password, or after the loading bar completes?

[Chamal1120]

Hyprland does have a way to force use the integrated gpu for rendering. Give it a try.

You can try adding a environment variable like below to your hyprland.conf

env = AQ_DRM_DEVICES,/dev/dri/card0:/dev/dri/card1

more info: https://wiki.hypr.land/Configuring/Multi-GPU/#telling-hyprland-which-gpu-to-use

[d4vsanchez]

I'm having the same issue, I don't have a hybrid GPU, but an integrated one (Ryzen 9). So it looks like an AMD-related issue.

@ryanrhughes For me, and I guess OP, it happens when the Plymouth loader appears. I see there's a flash, and then the screen is black.

I know Plymouth is working as I'm able to enter the password in the black screen, and then Hyprland loads.

[paucommit]

Exactly.

It is just in plymouth afterwards it works.

For me if I disable the nvidia-drivers it works fine, so I thought it was because of that. I will give take a look into the AMD drivers.

And if i am with the laptop plugged in. Then all works.

[paucommit]

I believe that I have found a solution for the problem.

What is the problem? The brightness of the iGPU is set to 0 on battery boot.

Why? This problem is only present the latest AMD chips. I am not aware that this happens in any other chipset.

How to fix? You can fix the issue by creating a custom udev rule to set the brightness during boot.

sudo vi /etc/udev/rules.d/99-amdgpu-brightness.rules

ACTION=="add", SUBSYSTEM=="backlight", KERNEL=="amdgpu_bl1", RUN+="/bin/sh -c 'echo 320000 > /sys/class/backlight/amdgpu_bl1/brightness'"

The solution is hardware specific but maybe we can create an install script which detects specific chipsets and sets the right rules. What do you think @ryanrhughes ?

Does it solve the problem for you @d4vsanchez ?

[ryanrhughes]

This is a really interesting find and may help resolve the Plymouth screen appearing really dark on Framework 13 laptops as well.

@paucommit did you need to do anything other than create that rules file to make this work?

I also noticed that in my case, the max brightness is 65535 so running echo 320000 > /sys/class/backlight/amdgpu_bl1/brightness results in an error.

Even correcting that, I still get the very dim Plymouth screen but to get a flash of full brightness after it starts to load in so I'm not sure if something else is also battling here or not.

[root@framework ryan]# echo 320000 > /sys/class/backlight/amdgpu_bl1/brightness
bash: echo: write error: Invalid argument

If we can work through some of those details and do some testing, I'd think this would be something we could include to ensure brightness is set consistently for users on these chips.

[paucommit]

This is very much hardware dependent.

In my case, I disabled the plymouth all together during testing and did not enable it back. I have the same behavior as you describe if I enable it back.

I will try creating a custom hook to run it after plymouth. That must be because plymouth tries controlling the screen.

We can play with the custom hook order e.g: ...udev plymouth brightness-hook...

We can play around to find the right place for it.

Also maybe trying the following flag: acpi_backlight=vendor

I will do some tests and come back.

We can then read the max_brightness from the device and set it up dynamically during install to solve these issues for all affected chips. Does the framework 13 also have the latest AMD chipset?

[ryanrhughes]

Mine has the AMD HX 370 and presents with the same thing, the only difference is that brightness set to 0 for me is just very very dim so the screen is at least still barely visible.

I think we're on the right path here though with what's happening. For some reason, they're getting set to 0 so whether it's in firmware or in the boot process, we need to find a way to bring it back up to a reasonable level at least.

[d4vsanchez]

Hey @paucommit ! This is very helpful, this didn't fix the issue completely, but now at least I can see the Plymouth interface just that it's very dim.

I'll need to tweak the values to find if I can increase the brightness further.

I've tested adding the amdgpu.backlight=0 parameter to my kernel, and it does seem to fix the issue, thought I lose the brightness control when in Hyprland. I think this confirms that the backlight/brightness is the culprit.

[paucommit]

Thanks for the feedback @d4vsanchez !

I will try creating a custom hook and share it here so we can all test.

[d4vsanchez]

Just wanted to update that I just created a hook, added it to initramfs and it worked. I had to change the value from 320000 to the value I have in /sys/class/backlight/amdgpu_bl1/max_brightness.

This is what I have in my custom hook, I tried to make it as generic as possible to post it here 😄

run_hook() {
  # Iterate for each device in here, we could pick the first we found.
  # This is done to prevent relying on ls which could be aliased to something else,
  # not sure if the alias is run on an initramfs hook.
  for backlight_path in /sys/class/backlight/*; do
        if [ -d "$backlight_path" ]; then
            max_brightness=$(cat "${backlight_path}/max_brightness")
            echo "$max_brightness" > "${backlight_path}/brightness"

            # Now break...
            break
        fi
    done
}

[paucommit]

What is your hook order now? I’ll try it out maybe @ryanrhughes can also try it so we test it in different hardware.

Thanks!

[d4vsanchez]

@paucommit Sure! This is my current configuration for HOOKS.

HOOKS=(base udev plymouth autodetect microcode modconf kms keyboard keymap consolefont block set-brightness encrypt filesystems fsck)

I added set-brightness (the custom hook) before encrypt.

[pedrodrocha]

I might be experiencing a similar problem on suspend and not boot after upgrading to the 2.0.0. Opened an issue https://github.com/basecamp/omarchy/issues/1125 but might be related to this one.

Basically whenever it goes to suspense, the screen for setting the password does not show and all I get is a black screen. I then need to press the power button to forcefully kill and restart it.

i975 + NVIDIA

[d4vsanchez]

Just wanted to post an update that in 6.16.4 this is fixed for me without any manual config.

@paucommit is this also your case?

[ryanrhughes]

I hadn't gotten around to trying the hooks yet but after updating to 6.16.4, my screen on the FW13 shows up somewhere around 50% brightness on the LUKS screen now.

[paucommit]

I can confirm that for me the issue is also solved. I’ll close the issue.