I. Summary This report details two related issues concerning screen brightness control in the KDE Plasma environment: When the screen brightness is already at its maximum level (100%), pressing the designated shortcut key to increase brightness (e.g., Fn+F6) elicits no visual feedback via the On-Screen Display (OSD). This behavior is inconsistent with the volume control OSD, which does provide feedback even when the volume is at 100%. A more critical issue arises when the Plasma shell incorrectly assumes the brightness is at 100% (even when it is not). In this state, attempts to increase brightness using the shortcut key fail to produce any change in brightness or any OSD feedback. To increase brightness, the user must first decrease it, after which the increase function becomes responsive again, and the OSD appears as expected. This behavior, particularly the lack of OSD feedback at maximum brightness, appears to be a regression of a previously fixed issue (Bug #387284). II. Environment Operating System: Arch Linux KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.1 Kernel Version: 6.12.33-1-lts (64-bit) Graphics Platform: Wayland Processors: 12 × Intel® Core™ i7-10750H CPU @ 2.60GHz Memory: 15.4 GiB of RAM Graphics Processor 1: NVIDIA GeForce GTX 1650 Graphics Processor 2: Intel® UHD Graphics Manufacturer: LENOVO Product Name: 82CG System Version: IdeaPad Gaming 3 15IMH05 III. Steps to Reproduce Scenario 1: No OSD feedback when brightness is at 100% Manually increase the screen brightness to its maximum level (100%) using the brightness control shortcut keys (e.g., Fn+F6). Observe that the brightness OSD appears during the increase. Once at 100% brightness, press the "increase brightness" shortcut key again. Scenario 2: Inability to increase brightness when Plasma incorrectly assumes 100% This state may occur under conditions not yet fully identified, but it manifests as the system believing brightness is at 100% when it is observably lower. Attempt to increase screen brightness using the "increase brightness" shortcut key (e.g., Fn+F6). Observe the brightness level and whether an OSD appears. If no change occurs, press the "decrease brightness" shortcut key (e.g., Fn+F5) once or multiple times. Observe that the brightness decreases and the OSD appears. Now, press the "increase brightness" shortcut key again. IV. Actual Results Scenario 1: When the "increase brightness" shortcut key is pressed while brightness is already at 100%, there is no OSD pop-up to indicate the current brightness level or that it is at its maximum. The system provides no visual feedback that the command was received or processed. Scenario 2: When attempting to increase brightness (step III.2.2), the screen brightness does not change, and no OSD appears. It gives the impression that the key press was not registered or that the brightness control is unresponsive. After decreasing the brightness (step III.2.4), attempting to increase brightness again (step III.2.6) now successfully increases the brightness, and the OSD appears as expected, showing the current brightness level. V. Expected Results Scenario 1: When the "increase brightness" shortcut key is pressed and the brightness is already at 100%, the OSD should appear, displaying the current brightness level (100%) and indicating that it is at the maximum. This behavior would be consistent with the volume OSD, which appears and shows "100%" when attempting to increase volume beyond its maximum. This consistency is important for user experience and feedback. Scenario 2: The Plasma shell should accurately reflect the actual screen brightness. If the brightness is not at 100%, pressing the "increase brightness" shortcut key should always increase the brightness and display the OSD with the updated level. It should not be necessary to first decrease brightness to enable the increase brightness functionality when the actual brightness is below maximum. VI. Additional Information and Analysis The observed lack of OSD feedback when attempting to increase brightness at 100% is inconsistent with other system feedback mechanisms, such as the volume control. The volume OSD correctly provides feedback even when the volume is at its maximum or minimum. This inconsistency can lead to user confusion, as it may seem like the brightness shortcut key is not functioning. More significantly, this specific issue (lack of OSD at 100%) appears to be a regression. Bug #387284 ("Brighness Key Show When Brightness is 100%") addressed this exact problem, stating, "When the brightness is already at the maximum (or minimum) value, hitting the keyboard shortcut to increase (resp. decrease) it does not bring up the OSD, there is no visual feedback. This is not consistent either with the volume which handles this correctly." This bug was marked as RESOLVED FIXED in Powerdevil 5.14.0, with the associated commit 4b8ae4d708a6f4cc854ea82ca96987f0b47ea722. The re-emergence of this behavior suggests that the previous fix may have been inadvertently reverted or is no longer effective in current versions. The second scenario, where Plasma incorrectly believes brightness is at 100% and prevents increases until a decrease is performed, is a more severe usability impediment. It directly hinders the user's ability to control a fundamental aspect of their display. This "false 100%" state could potentially be related to how KWin and PowerDevil interact regarding brightness settings. For instance, there are observations in other contexts (Bug #494408, Comment 4) where "KWin defaults the brightness of every monitor to 100%... KWin will ask PowerDevil to max out the brightness for any display without this entry, even if hardware brightness is currently lower than max". While that bug discusses a different specific scenario (brightness resetting on session startup/monitor wake-up), the described mechanism of KWin instructing PowerDevil to set maximum brightness could be a factor in the system erroneously concluding that brightness is at 100%, thus ignoring further increase commands until the state is reset by a decrease action. This suggests a potential area for investigation into the state management of brightness levels within Plasma.
I can reproduce the first scenario, I can't think of a way to trigger the other. This is also better off as two separate bugs.
You can reproduce scenario 2 on intel by setting the brightness to 25% on comand line (requires root): # echo $(( $(cat /sys/class/backlight/intel_backlight/max_brightness) / 4 )) | sudo tee /sys/class/backlight/intel_backlight/brightness (I imagine that for other manufacturers it must be a very similar command) After that, press the increase brightness shortcut (Fn+F6, here), and brightness will not increase. So you can try to decrease brightness (Alt+F5, here) and it will actually increase from 25% to 90%. Scenario 1 and 2 are the same bug because both have the same cause. They are only distinguished by the severity with which they affect the user. In scenario 1, it affects a lack of information (OSD), in scenario 2, which is more serious, it affects broken functionality (brightness don't increase where it should).
Please only report one issue per bug report. Also if you could try to be brief in explaining the issue, that's also helpful. > When the screen brightness is already at its maximum level (100%), pressing the designated > shortcut key to increase brightness (e.g., Fn+F6) elicits no visual feedback via the On-Screen > Display (OSD). This is Bug 494719 and secondarily also Bug 464771; no need for another report for it. > A more critical issue arises when the Plasma shell incorrectly assumes the brightness is at > 100% (even when it is not). We need to dig into why Plasma's impression of the brightness differs from reality; that's the bug we need to fix. Because when this is out of sync, you'll see all sorts of havoc. We need to fix the actual issue, and then the havboc will go away. Can you open a new bug report about only that issue, and also try to identify the conditions under which it happens? Without that, it's very doubtful we'll be able to figure out the root cause of the problem. Thank you!
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.