The brightness is set to what is configured in plasma surely. That seems consistent with what the UI communicates.

(In reply to Harald Sitter from comment #1)
> The brightness is set to what is configured in plasma surely. That seems
> consistent with what the UI communicates.
Thank for your quick response.
In a Wayland Desktop, the brightness can be changed normally. However, after entering the Wayland session, the brightness in the TTY is always set to 255. At this point, neither KDE tools nor brightnessctl can adjust the TTY brightness anymore, so this appears to be a bug.
If you do not log into Wayland, then both the SDDM and TTY brightness can be controlled successfully with brightnessctl.

> At this point, neither KDE tools nor brightnessctl can adjust the TTY brightness anymore

I am not sure I understand. If KDE tools can't change the brightness then how does this work:

> In a Wayland Desktop, the brightness can be changed normally.

Thank you for the response.
I would like to clarify the problem further, because it seems there may have been a misunderstanding:

When I am not logged into the Wayland desktop, brightness can be freely adjusted both in SDDM and in any TTY using brightnessctl or similar tools.

When I log into the Wayland KDE Plasma session, brightness is adjusted as expected inside the desktop environment. However, at this point:

The brightness of the TTY switches to the maximum level (255).

After that, neither KDE tools nor brightnessctl can change the TTY brightness anymore, even if I switch back to TTY or log out of the desktop session.



This behavior is reproducible every time.
From a user perspective, it effectively makes TTY brightness permanently locked after starting a Wayland session, unless I reboot the system.

I believe this is a usability problem (or a bug), since it is not documented or expected that using the desktop session would permanently disable brightness control in other virtual consoles.

If this is indeed intentional design, could you please confirm it explicitly? Otherwise, I think it should be considered at least a usability issue.

> since it is not documented or expected that using the desktop session would permanently disable brightness control in other virtual consoles.

Seeing as brightness is not per-VT that is entirely within expectation on Linux, seeing as Plasma needs to control its brightness.

Thank you for clarifying that brightness is shared globally across VTs. I do understand and fully accept that fact.

However, the specific behavior I am seeing does not seem to match simply “shared brightness”:

When I log into the Wayland KDE Plasma session, the brightness of the desktop is set to a normal level (e.g., 50%).

At the same moment, the brightness of the TTY switches to 255 (full brightness).

Even though the desktop is running with a lower brightness, the TTY stays stuck at 255.

After logging out of the desktop session, the brightness cannot be adjusted anymore in the TTY by any means (brightnessctl, KDE tools, etc.).


Effectively, the brightness set in KDE Plasma is not actually applied consistently to the TTY or SDDM—instead, it is forced to maximum brightness, which makes it difficult to use the system outside the desktop session.

This is why I think this behavior goes beyond simply “brightness is shared across VTs,” and appears more like a bug or unintended interaction.

Could you please confirm whether this specific behavior (TTY forced to max brightness even if Plasma uses a lower level) is intended?

> After logging out of the desktop session, the brightness cannot be adjusted anymore in the TTY by any means (brightnessctl, KDE tools, etc.).

Well, either that is a kernel bug or something else is manipulating the brightness. When you log out of plasma there's nothing from us running anymore seeing as you are logged out.