Summary: | I changed my brightness by mistake, the second screen is stuck on a wrong brightness value | ||
---|---|---|---|
Product: | [Plasma] Powerdevil | Reporter: | V <c9lyw0a2x> |
Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jpetso, me, natalie_clarius, nate |
Priority: | NOR | Keywords: | usability |
Version: | 6.0.4 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/plasma/powerdevil/-/commit/88aa87f7e6c291de02e6a585a04ccb0ebfcfd006 | Version Fixed In: | 6.2.0 |
Sentry Crash Report: |
Description
V
2024-05-30 19:41:25 UTC
Also specs: CPU: R7 7800X3D RAM: 32Gb GPU: RX 7900 XTX Driver: Mesa 24.0.7 and i run wayland. In a Wayland session you can tweak brightness of the outputs individually using the kscreen-doctor CLI, it even has convenient Tab-completions. In an X11 session there is a utility called xbacklight. So somehow the applet was able to change the brightness of one of your screens at first, but it immediately switched to controlling only the other screen, right? Was there anything suspicious going on in the system journal around the time when it happened? Posting vendor/model numbers of your monitors might be valuable pieces of information here. See also: https://notmart.org/blog/2023/02/how-to-report-multiscreen-bugs/ Git commit 88aa87f7e6c291de02e6a585a04ccb0ebfcfd006 by Jakob Petsovits. Committed on 23/08/2024 at 19:36. Pushed by jpetso into branch 'master'. applets/brightness: Per-display brightness controls This uses the new per-display D-Bus API from PowerDevil. Following this change, the applet does not use the old BrightnessControl D-Bus interface anymore, only the new ScreenBrightnessControl interface. A new ScreenBrightnessDisplayModel class is added to allow the use of QML Repeater objects in the UI. For scrolling on the icon, the applet does not need to know or specify which displays are changed, this responsibility now lies with the daemon and its AdjustBrightnessRatio/AdjustBrightnessSteps methods. Autotests are adapted accordingly, including changes by Fushan Wen. Note that reported brightness for the mocked backlight display will be lower by 1 in the new API, because minimum brightness of 1 (default for internal displays) is subtracted from the underlying brightness value. Hence we now test for values from 0 to 254. Related: bug 431994, bug 481927, bug 353032 M +15 -7 applets/brightness/package/contents/ui/BrightnessItem.qml M +0 -1 applets/brightness/package/contents/ui/CompactRepresentation.qml M +65 -40 applets/brightness/package/contents/ui/PopupDialog.qml M +44 -18 applets/brightness/package/contents/ui/main.qml M +1 -0 applets/brightness/plugin/CMakeLists.txt M +158 -53 applets/brightness/plugin/screenbrightnesscontrol.cpp M +39 -13 applets/brightness/plugin/screenbrightnesscontrol.h A +103 -0 applets/brightness/plugin/screenbrightnessdisplaymodel.cpp [License: GPL(v2.0+)] A +49 -0 applets/brightness/plugin/screenbrightnessdisplaymodel.h [License: GPL(v2.0+)] M +13 -4 autotests/applets/brightnesstest.py https://invent.kde.org/plasma/powerdevil/-/commit/88aa87f7e6c291de02e6a585a04ccb0ebfcfd006 Scrolling the brightness tray icon in Plasma 6.2 will affect the brightness of both your supported screens at once, but only relative to their previous respective brightness values. E.g. monitor 1 may go up from 80% to 85% while monitor 2 goes from 30% to 35%. Previously, for two monitors it would apply the brightness value of monitor 1 to monitor 2 even if they had different value ranges altogether. This worked for most monitors, but didn't make sense in general and could conceivably break if one of both monitors doesn't use the usual 0 to 100 range. Plasma 6.2 now also exposes brightness controls for each supported monitor so you can independently scale down the insanely bright monitor with its corresponding slider in the applet. Feel free to reopen the bug if these changes don't end up fixing the described issue for you. |