You are not logged in.
Hi everyone
I use a laptop using an encrypted disk and the plymouth pass prompt through sd-encrypt
Since updating to 6.15, the Plymouth screen for disk encryption password is showing with very low screen brightness.
I'm not sure if it's an issue on the kernel or something i have to change somewhere else.
Booting with Linux LTS still shows that screen with good brightness.
The laptop is a Framework 13
Offline
Offline
I'm seeing the same behavior, but only on my Framework 13" AMD's internal 2.8k display.
Brightness control has no effect, either. Normal brightness returns just as Plymouth hands off to gdu.
Last edited by shawnyeager (2025-07-31 17:14:21)
Offline
Where are you adding the dcdebugmask param to? If the kernel cmdline and amdgpu in the initramfs as part of the kms hook or explicitly should probably load this early enough, no?
Offline
Where are you adding the dcdebugmask param to? If the kernel cmdline and amdgpu in the initramfs as part of the kms hook or explicitly should probably load this early enough, no?
I touched none of this. Out-of-the-box `systemd-boot` + LUKS + Plymouth, then `sbctl`.
Offline
Did you click the link in #2?
Offline
@seth: I did. That's a different device, the Framework 16", and the bigger issue is that, having changed nothing, there's a breaking change.
Offline
Ignore the framework, this is a known change in the amdgpu kernel module and that thread contains information on which kernel cmdline parameters can be used to switch to the old behaviour
Offline
Parameters can be used to do all manner of things, of course. The issue is why would a change that causes an arbitrary dimming of just the Plymouth screen be introduced and not considered a bug? Brightness prior to and after are normal/as before.
Offline
Nobody here can tell you why AMD figured it was a good idea to change the brightness level behavior in two different minor kernel versions.
If you want my personal opinion, it's dumb as fuck and a pointless waste of everyones time because some intern needed a SoC project.
Now, have you tested whether restoring the old profile has any impact on your situation or are we going to continue based on lofty assumptions and disregard for Yes shouldland reality?
What's most likely going on is that plymouth restores or relies on a systemd-restored or hardcoded default and then some userspace daemon starts and sets a relative brightness level and since the new profile isn't linear, if you cross a certain level you'll return to the previous behavior.
But w/o feedback on the status quo I could just as much reason that god hates you and put gremlins into your computer - a theory based on the same level factual knowledge.
Offline