Bugs in DDC support, I suppose.

We don't really have control over the list of monitors that ddcutil tells us about. It's unclear to me why your monitor would sometimes be detected and sometimes not. Maybe ddcutil would always detect it after a while, but it doesn't wait long enough before reporting back the list of displays to Plasma's power management service. Not sure.

Chances are, once we react better to changes in detected monitors, this might get fixed in practice. For Plasma 6.1, we've already merged a patch that recognizes added or removed DDC monitors. More work is needed to hook this up to the Brightness and Color applet so the slider gets added and removed on the fly, without having to log in again to restart Plasma.

In the meantime now that I know DDC is a thing I've learned there is something called "ddcci-driver-linux" which provides a kernel module that apparently exposes DDC brightness control as typical brightness control so it just works everywhere

This problem doesn't seem to be present on Plasma 6.0.5 that comes with Manjaro

(In reply to rjawiygvozd from comment #4)
> This problem doesn't seem to be present on Plasma 6.0.5 that comes with
> Manjaro

Actually no, it still exists

I don't think it is my case, but with 6.1 I have issues when the monitor goes to sleep (DPMS). Probably, when it wakes up, Powerdevil tries to work with HDMI/DP i2c too early, and the monitor sometimes isn't yet ready to respond.

I have fixed(seem, still testing) it with this patch:
diff --git a/daemon/controllers/ddcutildisplay.cpp b/daemon/controllers/ddcutildisplay.cpp
index 1e1a274..09a5c93 100644
--- a/daemon/controllers/ddcutildisplay.cpp
+++ b/daemon/controllers/ddcutildisplay.cpp
@@ -49,7 +49,15 @@ DDCutilDisplay::DDCutilDisplay(DDCA_Display_Ref displayRef)
     // backed by libddcutil (like the ddcutil CLI itself) from functioning.
 
     DDCA_Display_Handle displayHandle = nullptr;
-    if (status = ddca_open_display2(m_displayRef, true, &displayHandle); status != DDCRC_OK) {
+    status = ~status;
+    for (int i = 0; i < 2 && status != DDCRC_OK; ++i) {
+        if (status = ddca_open_display2(m_displayRef, true, &displayHandle); status != DDCRC_OK) {
+            QThread::msleep(200);
+            continue;
+        }
+    }
+
+    if (status != DDCRC_OK) {
         qCWarning(POWERDEVIL) << "[DDCutilDisplay]: ddca_open_display2" << status;
         return;
     }

Just a quick fix, but it can potentially confirm my theory. So, maybe it is required to add some mechanism to handle this situations.

Nice, would you like to submit that upstream so the developers can take a look. Generally patches in Bugzilla tickets get overlooked.

Yes, sure. When I am certain it is working, I will make an MR. Today, I encountered the issue again with this patch, so the place I am fixing is probably wrong. Now, I have enabled more logs and am testing another fix.

(In reply to zvova7890 from comment #6)
> I don't think it is my case, but with 6.1 I have issues when the monitor
> goes to sleep (DPMS). Probably, when it wakes up, Powerdevil tries to work
> with HDMI/DP i2c too early, and the monitor sometimes isn't yet ready to
> respond.

Thanks for running this experiment. Might be related to Bug 476540, which is also seemingly related to DPMS. (My theory is that we should disable any brightness commands while DPMS has the monitor turned off, and then apply the last requested brightness after the monitor comes back.)

Could you check what the value of `status` is when ddca_open_display2() fails? ddcutil_status_codes.h doesn't have a "wait and try again" status code like EAGAIN, but I wonder if perhaps DDCRC_DPMS_ASLEEP (value -3030) serves a similar purpose in this case.

I'm getting -3029 error.

Created MR: https://invent.kde.org/plasma/powerdevil/-/merge_requests/393

Git commit 584cfdf0256bc7034be0b3fadf94f7b486597aa6 by Xaver Hugl.
Committed on 28/06/2024 at 13:17.
Pushed by zamundaaa into branch 'master'.

core: reload actions on brightness controller changes

Whether or not the brightness control action is supported depends on the currently
connected list of screens, which is dynamic and can't just be checked on startup.
To fix this, reload actions when devices get added or removed

M  +24   -27   daemon/powerdevilcore.cpp
M  +2    -2    daemon/powerdevilcore.h

https://invent.kde.org/plasma/powerdevil/-/commit/584cfdf0256bc7034be0b3fadf94f7b486597aa6

A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/395

Git commit d91bc62fa6ff93ac62ded148fee3722deab41442 by Xaver Hugl.
Committed on 28/06/2024 at 15:00.
Pushed by zamundaaa into branch 'Plasma/6.1'.

core: reload actions on brightness controller changes

Whether or not the brightness control action is supported depends on the currently
connected list of screens, which is dynamic and can't just be checked on startup.
To fix this, reload actions when devices get added or removed

(cherry picked from commit 584cfdf0256bc7034be0b3fadf94f7b486597aa6)

Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>

M  +4    -0    daemon/controllers/screenbrightnesscontroller.cpp
M  +1    -0    daemon/controllers/screenbrightnesscontroller.h
M  +23   -27   daemon/powerdevilcore.cpp
M  +2    -2    daemon/powerdevilcore.h

https://invent.kde.org/plasma/powerdevil/-/commit/d91bc62fa6ff93ac62ded148fee3722deab41442

Git commit 220b6b9531b21bb3d2cc790c6a3718af3df7aa7b by Volodymyr Zolotopupov.
Committed on 02/07/2024 at 08:35 CET.
Pushed by jpetso into branch 'master'.

ddcutildisplay: give some time before changing brightness after the monitor resumes

M  +4    -1    daemon/controllers/ddcutildisplay.cpp

https://invent.kde.org/plasma/powerdevil/-/commit/220b6b9531b21bb3d2cc790c6a3718af3df7aa7b

And also cherry-picked into Plasma/6.1 (will be released with 6.1.2):
https://invent.kde.org/plasma/powerdevil/-/commit/0c084dcb444173273b60934af7bdb321d39dbf13

rjawiygvozd@gmail.com,

Could you please put this into /etc/environment and catch the situation when you have unavailable brightness controls?
QT_LOGGING_RULES="*powerdevil*.debug=true"

Then save the logs: journalctl -b -t org_kde_powerdevil > /tmp/powerdevil.log
... and attach here. 

Just wan't to understand what is going on.

*** Bug 489563 has been marked as a duplicate of this bug. ***

Created attachment 171302 [details]
powerdevil.log

(In reply to rjawiygvozd from comment #17)
> Created attachment 171302 [details]
> powerdevil.log

I had to restart the session multiple times before I replicated it but the last one has the problem.
This is Plasma 6.1.1

(In reply to rjawiygvozd from comment #18)
> (In reply to rjawiygvozd from comment #17)
> > Created attachment 171302 [details]
> > powerdevil.log
> 
> I had to restart the session multiple times before I replicated it but the
> last one has the problem.
> This is Plasma 6.1.1

Also I don't know if this is relevant but this monitor actually has a horrible startup time and whenever it goes from bios graphics mode or whatever it's called to a proper screen resolution it also spends at least a few seconds in the black screen, to the point that pc boots way before I can actually see anything

and this transition is also happening when it goes from sddm to plasma

It is probably due to a race condition between KWin mode setting up and Powerdevil DDC/CI work. DDC detection should probably also be delayed.

*** Bug 487959 has been marked as a duplicate of this bug. ***

Created attachment 173580 [details]
Log after connection with HDMI-HDMI and brightness slider was shown

Created attachment 173581 [details]
Log after connection with DP-HDMI and brightness slider was missing

I've also had similar odd behaviour so thought I'd record it here. For more than three years using KDE on Tumbleweed I had my monitor (HP M24f 1080p) plugged into my PC via the bundled HDMI cable, and was blissfully unaware that changing the brightness of a monitor from software was even possible. Suddenly – and I forget when exactly this was, but earlier this year – I noticed that a brightness slider had appeared next to the Night Control toggle. And it worked! I assumed that a Plasma update had added either the functionality or the compatibility with my monitor.

I don't remember it being only sporadically available, though I didn't use it all that much.

A short while ago, maybe a month or so but no idea really, I noticed that the option was gone. And it stayed gone, so I assumed it was a regression. I didn't think to report it at the time.

Now I got to wondering why it didn't work any more, did some googling, found this bug report. I yesterday switched to using a DP to HDMI cable rather than the old HDMI cable, and over the course of several reboots and logout/login cycles it doesn't seem to ever work with this cable.

Weirdly, when I now switch back to the old cable, or another HDMI-HDMI cable, the brightness control seems to consistently appear. Which would imply that maybe the new DP-HDMI cable can't carry the DCC signal, something that would be entirely unsurprising – but the thing is, it is only now when I'm fiddling around with it and swapping back and forth that the brightness control appears with the HDMI-HDMI cable, whereas at least for the past few weeks I am absolutely 100% certain that it wasn't. But now I can't reproduce that.

Another point is that if I swap from one cable to another during a session (i.e. the monitor is disconnected then reconnected via a different cable and port on the GPU) there are no new entries printed to the log, and the brightness slider either remains hidden or remains shown, but if I boot with HDMI-HDMI, get shown the slider, then switch to DP-HDMI, the slider is still shown but no longer has any effect (indeed, if I try to change the brightness the widget gets stuck and freezes).

Should it be relevant, the cable in question is this one: https://www.amazon.de/UGREEN-DisplayPort-Uni-Direktional-Multi-Screen-Kompatibel/dp/B07V3RYBVY . It's advertised specifically as being one-way only, but at least some information must flow from the monitor to the PC as it still picks up the model name for instance.

I've attached the log output of both the successful and failed cases. If I ever replicate the brightness slider failing to show with the HDMI-HDMI connection then I'll post a log of that, too.

Git commit 44e6922ae9f06a3e2fa3e7640be7eb32591cd579 by Jakob Petsovits.
Committed on 14/10/2024 at 22:36.
Pushed by jpetso into branch 'master'.

daemon: Retry failed DDC/CI reads and writes repeatedly

DDC/CI communication with monitors can be unreliable,
especially when the monitor is still in the process of
fully waking up. The moment that we receive a connection
or DPMS awake event may not be the moment that brightness
commands start working.

Prior to this commit, `DDCutilDisplay` protected itself against
this case with a drastic measure: if a read or write command
failed, the object would claim brightness controls as
unsupported. This error condition meant that we won't end up
with inconsistent state, but it also makes the monitor's
brightness slider go away (or fall back to software
brightness controls if KWin wants those instead).

This commit still uses the same failure mode, but will try
harder before we give up on the monitor altogether.
Both initialization (reading the initial brightness value)
and `setBrightness()` will now retry a few times if the
first attempt didn't work out. Subsequent retries will be
spaced out further, until we finally give up on that monitor.

To avoid exposing uninitialized `DDCutilDisplay` objects,
a list of pending displays now holds these objects while
they're waiting for another initialization attempt.

`setBrightness()` will only be performed once initialization
has succeeded, so the two operations are mutually exclusive.
We can reuse DDCutilDisplay's existing brightness delay timer
for both kinds of retry operations.
Related: bug 493329

M  +23   -11   daemon/controllers/ddcutildetector.cpp
M  +69   -15   daemon/controllers/ddcutildisplay.cpp
M  +8    -2    daemon/controllers/ddcutildisplay.h

https://invent.kde.org/plasma/powerdevil/-/commit/44e6922ae9f06a3e2fa3e7640be7eb32591cd579

Git commit 48453745b1cfb0fce66e16ec9ef8caf961e79677 by Jakob Petsovits.
Committed on 14/10/2024 at 23:04.
Pushed by jpetso into branch 'Plasma/6.2'.

daemon: Retry failed DDC/CI reads and writes repeatedly

DDC/CI communication with monitors can be unreliable,
especially when the monitor is still in the process of
fully waking up. The moment that we receive a connection
or DPMS awake event may not be the moment that brightness
commands start working.

Prior to this commit, `DDCutilDisplay` protected itself against
this case with a drastic measure: if a read or write command
failed, the object would claim brightness controls as
unsupported. This error condition meant that we won't end up
with inconsistent state, but it also makes the monitor's
brightness slider go away (or fall back to software
brightness controls if KWin wants those instead).

This commit still uses the same failure mode, but will try
harder before we give up on the monitor altogether.
Both initialization (reading the initial brightness value)
and `setBrightness()` will now retry a few times if the
first attempt didn't work out. Subsequent retries will be
spaced out further, until we finally give up on that monitor.

To avoid exposing uninitialized `DDCutilDisplay` objects,
a list of pending displays now holds these objects while
they're waiting for another initialization attempt.

`setBrightness()` will only be performed once initialization
has succeeded, so the two operations are mutually exclusive.
We can reuse DDCutilDisplay's existing brightness delay timer
for both kinds of retry operations.
Related: bug 493329


(cherry picked from commit 44e6922ae9f06a3e2fa3e7640be7eb32591cd579)

Co-authored-by: Jakob Petsovits <jpetso@petsovits.com>

M  +23   -11   daemon/controllers/ddcutildetector.cpp
M  +69   -15   daemon/controllers/ddcutildisplay.cpp
M  +8    -2    daemon/controllers/ddcutildisplay.h

https://invent.kde.org/plasma/powerdevil/-/commit/48453745b1cfb0fce66e16ec9ef8caf961e79677

Hey guys, the commit above is introducing repeated retries for PowerDevil's DDC/CI support. This applies to both initialization and setting brightness. Plasma 6.2.1 will have the change, please test if this fixes any issues for you and leave a comment in case something still isn't working.

Thanks!

Patch applied. I will test it.

(In reply to Julien Delquié from comment #29)
> Patch applied. I will test it.

Didn’t see anything strange, but patch doesn’t apply anymore against powerdevil v6.2.1.

(In reply to Julien Delquié from comment #30)
> Didn’t see anything strange, but patch doesn’t apply anymore against
> powerdevil v6.2.1.

PowerDevil in 6.2.1 already includes it (and a minor fix-up that also always uses repeated tries after monitor wake-up).

(In reply to Jakob Petsovits from comment #31)
> (In reply to Julien Delquié from comment #30)
> > Didn’t see anything strange, but patch doesn’t apply anymore against
> > powerdevil v6.2.1.
> 
> PowerDevil in 6.2.1 already includes it (and a minor fix-up that also always
> uses repeated tries after monitor wake-up).

Oh I remember you already told this in a previous comment, sorry!

This seems very similar to my findings  - https://bugs.kde.org/show_bug.cgi?id=494233

Some kind of regression has been implemented.
This bug was fixed for me, but it came back again a week or so ago.

*** Bug 496676 has been marked as a duplicate of this bug. ***

On 6.2.3, I'm getting a very similar problem, though my setup is more complicated. (But I think that doesn't matter in this case)

I have a Framework 16 laptop
- Integrated GPU
- Dedicated GPU extension
- AMD eGPU

After the initial boot, all the monitors are visible in the brightness applet. I can modify them all.
After a screen lock + screen standby, all of them have disappeared from the widget AND they're all at 30% brightness again.
Then I have to use another tool (like the GTK ddccontrol GUI) to actually change the brightness.

Can also confirm this is still an issue.

Sometimes my external display appears in Plasma's OSD/powerdevil, sometimes there's the laptop display only.

But even when the external display is not "visible", I can still query it and change values (brightness, contrast) via dccutil, and it just works.

This has to mean that the bug is somewhere "higher up" in the stack, i.e. (I guess) Plasma or some other KDE component.

Operating System: openSUSE Tumbleweed 20241202
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.0
Kernel Version: 6.11.8-1-default (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7840U w/ Radeon 780M Graphics
Memory: 30.7 GiB of RAM
Graphics Processor: AMD Radeon 780M
Manufacturer: Framework
Product Name: Laptop 13 (AMD Ryzen 7040Series)
System Version: A7

Some logs from my current session (notice however that the last timestamp, 13:02, is a few hours ago, much before my attempts to change brightness via plasma - might it be that the "connection" broke at that point and wasn't recovered since then?):

```
❯  journalctl -b | grep org_kde_powerdevil | grep ddc
Hint: You are currently not seeing messages from other users and the system.
      Users in the 'systemd-journal' group can see all messages. Pass -q to
      turn off this notice.
Dec 05 09:05:06 andromeda org_kde_powerdevil[2412]: Initializing libddcutil.  ddcutil version: 2.1.4, shared library: /usr/lib64/libddcutil.so.5.1.2
Dec 05 09:05:07 andromeda org_kde_powerdevil[2412]: busno=14, Feature 0xdd should not exist but ddc_get_nontable_vcp_value() succeeds, returning mh=0x00 ml=0x64 sh=0x00 sl=0x64
Dec 05 09:05:07 andromeda org_kde_powerdevil[2412]: busno=14, Feature 0x41 should not exist but ddc_get_nontable_vcp_value() succeeds, returning mh=0x00 ml=0x64 sh=0x00 sl=0x64
Dec 05 09:05:07 andromeda org_kde_powerdevil[2412]: busno=14, Feature 0x00 should not exist but ddc_get_nontable_vcp_value() succeeds, returning mh=0x00 ml=0x64 sh=0x00 sl=0x64
Dec 05 13:02:39 andromeda org_kde_powerdevil[2412]: org.kde.powerdevil: [DDCutilDisplay]: ddca_open_display2 -3030
Dec 05 13:02:40 andromeda org_kde_powerdevil[2412]: org.kde.powerdevil: [DDCutilDisplay]: ddca_open_display2 -3030
Dec 05 13:02:42 andromeda org_kde_powerdevil[2412]: org.kde.powerdevil: [DDCutilDisplay]: ddca_open_display2 -3030
Dec 05 13:02:45 andromeda org_kde_powerdevil[2412]: org.kde.powerdevil: [DDCutilDisplay]: ddca_open_display2 -3030
```

Sharing what seems to be a workaround:

systemctl --user restart plasma-powerdevil.service

I had also tried turning the external display off and on again before that, but that wasn't effective. Restarting powerdevil instead is (or seems to be, for the moment)

With the 6.12 kernel, I encountered a regression again. Something has changed with the connect-disconnect event, causing ddcutils to try to get info from the monitor while it is in DPMS. I reverted back to the 6.11 kernel. I haven't had time to gather more details yet.

won't be reopening my https://bugs.kde.org/show_bug.cgi?id=494233 report but on Arch with kernel 6.12 the issue seems to be back. Now I lose control over both monitors if they were off for some time. Restarting powerdevil services helps.

*** Bug 497146 has been marked as a duplicate of this bug. ***

*** Bug 496295 has been marked as a duplicate of this bug. ***

*** Bug 497287 has been marked as a duplicate of this bug. ***

*** Bug 496952 has been marked as a duplicate of this bug. ***

*** Bug 497382 has been marked as a duplicate of this bug. ***

I never got round to responding to report the result of the fix in 6.2.1 for me, sorry!

In contrast to the other recent reports I can add some positivity to say that every time I have checked recently everything the brightness slider works correctly :) I believe it was fixed with 6.2.1 and has remained fixed for me since then.

Current state of system:

Operating System: openSUSE Tumbleweed 20241211
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.1
Kernel Version: 6.11.8-1-default (64-bit)
Graphics Platform: Wayland
Processors: 4 × AMD Ryzen 3 3200G with Radeon Vega Graphics
Memory: 15.5 GiB of RAM
Graphics Processor: AMD Radeon RX 6600
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B450 I AORUS PRO WIFI

i.e. I am still on kernel 6.11. I'll pay special attention to what happens when the kernel upgrade lands.

*** Bug 496890 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/480

(In reply to Andrea Ippolito from comment #38)
> Sharing what seems to be a workaround:
> 
> systemctl --user restart plasma-powerdevil.service
> 
> I had also tried turning the external display off and on again before that,
> but that wasn't effective. Restarting powerdevil instead is (or seems to be,
> for the moment)

I have this issue too on Plasma 6.2.4. ddcutil works otherwise but thankfully as you suggest restarting powerdevil restores the brightness controls at least for that session.

I tried out the development version of ddcutil (2.2.0-dev) and it improved the reliability of monitor connection/disconnection events for me. If you're still experiencing issues and have access to ddcutil's dev version, e.g. for Arch users through the ddcutil-git package in AUR, give it a shot, it may improve things for you. If it does, please report back. If not, sorry and hopefully we can figure things out eventually!

Hello there! I`m experiencing a similiar problem with. Interesting enough, if I remove and re-add the Brightness and color" widget on one of my toolbars, the controls for brightness for both displays show up and everything is working as expected.
(I hope it was the right move to post into this bug thread; if not forgive me, since I`m new :) I will gladly open a new thread if not).

OS: EndeavourOS x86_64
Kernel: Linux 6.12.4-arch1-1
DE: KDE Plasma 6.2.4

(In reply to captcapslock from comment #51)
> Hello there! I`m experiencing a similiar problem with. Interesting enough,
> if I remove and re-add the Brightness and color" widget on one of my
> toolbars, the controls for brightness for both displays show up and
> everything is working as expected.

Plasma 6.2 has some known bugs with keeping the list of displays in the brightness applet updated in certain scenarios. If your issue is fixed by restarting the applet (or `systemctl --user restart plasma-plasmashell`, to avoid messing with the panel config) then that's good news, because Plasma 6.3 has fixes for all of the known applet updating bugs:

- https://invent.kde.org/plasma/powerdevil/-/commit/c8f60bbfdefebfc336a1b6c1bda89a904c105fc6
- https://invent.kde.org/plasma/powerdevil/-/commit/9d28753c76f4c3dcaa8827277555136c33f9cc8d
- https://invent.kde.org/plasma/powerdevil/-/commit/6f668270a389322ccdb8b8cc92eea308d087fca8

We didn't backport those to 6.2 because they're somewhat more intrusive and wanted to stay on the side of "no unintentional regressions elsewhere". If the brightness key on your keyboard (or an equivalent assigned shortcut) is still working even after the applet loses certain display functionality, you know that you've got an applet bug on your hands.

Plasma 6.3 Beta 1 is coming out in early January and the 6.3.0 a month later, which should at least put those applet bugs to rest. I'm less confident about bugs related to the daemon side of things (using ddcutil). Please retest and keep us updated when you receive new versions of Plasma and/or ddcutil releases. Thanks!

*** Bug 497983 has been marked as a duplicate of this bug. ***

*** Bug 498329 has been marked as a duplicate of this bug. ***

Git commit fcf28649d0f6c3aa04e7ea1e58f9dc9020138048 by Jakob Petsovits.
Committed on 08/01/2025 at 07:13.
Pushed by jpetso into branch 'master'.

daemon: Only use ddcutil display objects for awake monitors

Previously, m_displays in `DDCutilDetector` contained all valid
ddcutil displays, and ASLEEP/AWAKE events would pause/resume
the affected display. Upon resuming, we needed to write the
current brightness value so that it's still in line with any
changes that were made in the meantime.

This has two downsides:

* `DDCutilDetector` exposes a display that it can't control,
  but which may still show a brightness slider to the user in
  certain circumstances.
* We force a long-delayed brightness write that may or may not
  be desired at that point, especially if we've missed previous
  external brightness changes due to DDC/CI limitations.

Instead of trying to figure out how to decide whether we want to
issue a brightness write or emit `externalBrightnessChangeObserved()`,
we can reduce complexity by making use of a more basic concept:
removing and adding displays.

With this commit, a monitor that has gone to sleep will not
expose brightness controls anymore. Once it wakes up, we read its
current brightness again from scratch. If the controller wants to
restore any brightness values upon seeing the display again, it can
set its brightness as a reaction to `displaysChanged()`. Tracking
and restoring brightness across sleep/wake events is not the
responsibility of our DDC/CI classes anymore.

With back-off retries in place for `DDCutilDisplay` initialization,
we don't need to worry about delaying DDC/CI commands after wake-up
as `resumeWorker()` used to do.
Related: bug 493329

M  +7    -21   daemon/controllers/ddcutildetector.cpp
M  +0    -23   daemon/controllers/ddcutildisplay.cpp
M  +0    -2    daemon/controllers/ddcutildisplay.h

https://invent.kde.org/plasma/powerdevil/-/commit/fcf28649d0f6c3aa04e7ea1e58f9dc9020138048

*** Bug 498571 has been marked as a duplicate of this bug. ***

*** Bug 499160 has been marked as a duplicate of this bug. ***

*** Bug 499219 has been marked as a duplicate of this bug. ***

*** Bug 499244 has been marked as a duplicate of this bug. ***

I am using the latest packages for Fedora Rawhide. My Plasma is version 6.2.90. I am still experiencing this issue. I do not believe it to be fully fixed. Is there anything I can do to help track this down?

(In reply to Wren Turkal from comment #60)
> I am using the latest packages for Fedora Rawhide. My Plasma is version
> 6.2.90. I am still experiencing this issue. I do not believe it to be fully
> fixed. Is there anything I can do to help track this down?

ddcutil is coming out with version 2.2.0 within the next few weeks, also featuring massive improvements in display change detection compared to 2.1.4. For anyone experiencing problems, I'd be extremely curious whether upgrading to the new version makes a difference for you (2.2.0-rc2 runs great for me personally).

Apart from that, the biggest help would be finding and describing a case where brightness controls will reliably disappear, even though they shouldn't. I know, that's a hard ask for a bug report with a literal "randomly" in the title. Try to figure out the pattern - and keep in mind that Plasma will make displays disappear from its list if it tries to set brightness via DDC/CI but does not succeed.

At this point, at the time of Plasma 6.3 Beta 1 or Beta 2, most of the reliability improvements I had in mind have been implemented. One thing we should still do is to manual refresh the list of brightness-capable displays from PowerDevil when the user switches to a different session, or when we trigger a monitor's DPMS sleep. (The upcoming ddcutil version will not tell us about DPMS changes, so a monitor operation could conceivably fail if triggered during that time. If it weren't for that, Plasma 6.3.91 a.k.a. Beta 2 would have DPMS covered as well.)

*** Bug 499251 has been marked as a duplicate of this bug. ***

Will definitely try to do that.

However, I will also note that there was more to my bug that I reported that marked as a dupe of this one.

For one, when the brightness slider doesn't disappear, it's not uncommon for it to be set to either 100% or 0% until I move the slider.

Also, when I hook up the monitor, the volume for the audio output on the monitor is usually set to 100%. These things happen even if I have the monitor plugged in during boot and see the SDDM login screen on my external monitor.

I will continue to see if I can find patterns here.

I can tell you that every time my computer wakes from sleep or I login, the slider, when it is showing, is always at to 100%. The actual brightness of the monitor is never set to that. If I skid the slider it correctly sets the brightness to whatever level the slider is at.

There was an initial bug with not being able to change monitor brightness after the monitor wakes up. Have reported it here - https://bugs.kde.org/show_bug.cgi?id=494233
It was fixed with 6.2. Now with 6.3 on Arch when both my monitors wake up (not from suspend, just screen off!), my second monitor (the slower to wake up, acer in my report) now gets defaulted to 100 brightness. My first monitor remains at set brightness. Again, issue was solved for me in late 6.2. Now it is worse. I'd rather have no control and restart the service than wake my screens at noon and be blasted with 100% brightness. If I could provide some logs, tag me.

(In reply to d3vilguard from comment #65)
> Now with 6.3 on Arch when both my monitors wake up
> (not from suspend, just screen off!), my second monitor (the slower to wake
> up, acer in my report) now gets defaulted to 100 brightness. My first
> monitor remains at set brightness. Again, issue was solved for me in late
> 6.2. Now it is worse. I'd rather have no control and restart the service
> than wake my screens at noon and be blasted with 100% brightness. If I could
> provide some logs, tag me.

I'm dying for an insightful set of logs, please do share yours if you can (and also ddcutil version).
The PowerDevil README has instructions on how to produce helpful logs:
https://invent.kde.org/plasma/powerdevil/-/blob/master/README.md#troubleshooting--reporting-bugs

(In reply to Jakob Petsovits from comment #66)
> (In reply to d3vilguard from comment #65)
> > Now with 6.3 on Arch when both my monitors wake up
> > (not from suspend, just screen off!), my second monitor (the slower to wake
> > up, acer in my report) now gets defaulted to 100 brightness. My first
> > monitor remains at set brightness. Again, issue was solved for me in late
> > 6.2. Now it is worse. I'd rather have no control and restart the service
> > than wake my screens at noon and be blasted with 100% brightness. If I could
> > provide some logs, tag me.
> 
> I'm dying for an insightful set of logs, please do share yours if you can
> (and also ddcutil version).
> The PowerDevil README has instructions on how to produce helpful logs:
> https://invent.kde.org/plasma/powerdevil/-/blob/master/README.
> md#troubleshooting--reporting-bugs

Actually there is issue with 6.3 with both my monitors. This is on a AMD rx6800. Kernel wasn't changed when upgrading from plasma 6.2 to 6.3, nor was ddcutil. With 6.1 my issue was that my acer monitor (slower to wake up than my huawei) got it's brightness set to 0 and I lost control over it from plasma (ddcutil had no problem controlling both manually). This happened after letting the monitors be in a sleep state for some time. 6.2 was fixed. Now on 6.3 if I leave the monitors to sleep (no PC suspend, just monitors off) my acer goes to 100% when it wakes up and my huawei drops to 0%. Both should wake up at 15%.

Log after letting the monitors go to complete sleep and waking them up afterwards - https://logpaste.com/8gqSVa47



Log after letting the monitors sleep (no PC suspend, just monitor sleep) - https://logpaste.com/8gqSVa47

(In reply to d3vilguard from comment #67)
> (In reply to Jakob Petsovits from comment #66)
> > (In reply to d3vilguard from comment #65)
> > > Now with 6.3 on Arch when both my monitors wake up
> > > (not from suspend, just screen off!), my second monitor (the slower to wake
> > > up, acer in my report) now gets defaulted to 100 brightness. My first
> > > monitor remains at set brightness. Again, issue was solved for me in late
> > > 6.2. Now it is worse. I'd rather have no control and restart the service
> > > than wake my screens at noon and be blasted with 100% brightness. If I could
> > > provide some logs, tag me.
> > 
> > I'm dying for an insightful set of logs, please do share yours if you can
> > (and also ddcutil version).
> > The PowerDevil README has instructions on how to produce helpful logs:
> > https://invent.kde.org/plasma/powerdevil/-/blob/master/README.
> > md#troubleshooting--reporting-bugs
> 
> Actually there is issue with 6.3 with both my monitors. This is on a AMD
> rx6800. Kernel wasn't changed when upgrading from plasma 6.2 to 6.3, nor was
> ddcutil. With 6.1 my issue was that my acer monitor (slower to wake up than
> my huawei) got it's brightness set to 0 and I lost control over it from
> plasma (ddcutil had no problem controlling both manually). This happened
> after letting the monitors be in a sleep state for some time. 6.2 was fixed.
> Now on 6.3 if I leave the monitors to sleep (no PC suspend, just monitors
> off) my acer goes to 100% when it wakes up and my huawei drops to 0%. Both
> should wake up at 15%.
> 
> Log after letting the monitors go to complete sleep and waking them up
> afterwards - https://logpaste.com/8gqSVa47
> 
> 
> 
> Log after letting the monitors sleep (no PC suspend, just monitor sleep) -
> https://logpaste.com/8gqSVa47

It is not ddcutil. Latest version and last updated in 2024:
[2024-09-24T10:33:54+0300] [ALPM] upgraded ddcutil (2.1.4-1 -> 2.1.4-2)

(In reply to d3vilguard from comment #68)
> (In reply to d3vilguard from comment #67)
> > (In reply to Jakob Petsovits from comment #66)
> > > (In reply to d3vilguard from comment #65)
> > > > Now with 6.3 on Arch when both my monitors wake up
> > > > (not from suspend, just screen off!), my second monitor (the slower to wake
> > > > up, acer in my report) now gets defaulted to 100 brightness. My first
> > > > monitor remains at set brightness. Again, issue was solved for me in late
> > > > 6.2. Now it is worse. I'd rather have no control and restart the service
> > > > than wake my screens at noon and be blasted with 100% brightness. If I could
> > > > provide some logs, tag me.
> > > 
> > > I'm dying for an insightful set of logs, please do share yours if you can
> > > (and also ddcutil version).
> > > The PowerDevil README has instructions on how to produce helpful logs:
> > > https://invent.kde.org/plasma/powerdevil/-/blob/master/README.
> > > md#troubleshooting--reporting-bugs
> > 
> > Actually there is issue with 6.3 with both my monitors. This is on a AMD
> > rx6800. Kernel wasn't changed when upgrading from plasma 6.2 to 6.3, nor was
> > ddcutil. With 6.1 my issue was that my acer monitor (slower to wake up than
> > my huawei) got it's brightness set to 0 and I lost control over it from
> > plasma (ddcutil had no problem controlling both manually). This happened
> > after letting the monitors be in a sleep state for some time. 6.2 was fixed.
> > Now on 6.3 if I leave the monitors to sleep (no PC suspend, just monitors
> > off) my acer goes to 100% when it wakes up and my huawei drops to 0%. Both
> > should wake up at 15%.
> > 
> > Log after letting the monitors go to complete sleep and waking them up
> > afterwards - https://logpaste.com/8gqSVa47
> > 
> > 
> > 
> > Log after letting the monitors sleep (no PC suspend, just monitor sleep) -
> > https://logpaste.com/8gqSVa47
> 
> It is not ddcutil. Latest version and last updated in 2024:
> [2024-09-24T10:33:54+0300] [ALPM] upgraded ddcutil (2.1.4-1 -> 2.1.4-2)

P.S. sory that I'm spamming here but the more I play with it, the worse it gets. I also have no control over my huawei when it wakes up. At the end of the above log I manually set my acer and huawei brightness, you will see. If I could provide further logs, I will. Again sorry that I am spamming.

> Log after letting the monitors go to complete sleep and waking them up afterwards - https://logpaste.com/8gqSVa47
> 
> Log after letting the monitors sleep (no PC suspend, just monitor sleep) - https://logpaste.com/8gqSVa47

Sorry, that's the same link. Perhaps you still have the other one around as well?

> Again sorry that I am spamming.

It's okay, thanks for sharing the logs. I'll have a closer look later. One thing you could do is only quote the specific lines you're replying to, but not the whole message. This will make the thread a lot tidier.

When writing the first comment with the logs I forgot that I pasted the log so it is absolutely the same log two times. Use this, it's cleaner - https://logpaste.com/spgFiNrh

It is taken after enabling powerdevil to log and restarting it. Before sleeping the screen was at 15, yet powerdevil decides to make it 100:
org.kde.powerdevil: [DDCutilDisplay]: "XF243Y P" setting brightness to 100 with temporary display handle. 


Now, before the screens going to sleep I was able with the mouse wheel to control both. After they resume I am able to lower both, but after that with the mouse wheel I can only control my acer (tho not logged. Log is just the screens powering on with one at wrong brightness). Something is very wrong with powerdevil :D

This is not only multimonitor behavior. 

Tested with just the acer connected (one connected monitor). Shutting the monitor down or letting it go to monitor sleep (again no PC suspend states, just monitor sleep. Also disabled DIM) results in it being set to 100% after I wake it up. It should wake up at 15%. Most likely the issue is from the acer taking a few seconds to wake up, while plasma itself is ready to display. This leads to the monitor being recognized as newly connected.

Newly connected monitors in 6.3 are getting set at 100% no matter what the value in the monitor was?! Proving this I had my huawei at 15%. Disconnected it. Booted with just the Acer. Connected the huawei. Huawei gets set at 100% instead of 15%!

Who in their right mind decided to set 100 to connected monitors instead of to read whatever ddc pulls from the monitor and set it... Or even remember states?

To mitigate this I will just disable ddcutil for powerdevil and use ddcutil on its own to control my monitors.
$ systemctl --user edit plasma-powerdevil.service

[Service]
Environment=POWERDEVIL_NO_DDCUTIL=1

$ systemctl --user restart plasma-powerdevil.service

Then make two shortcuts for Up and Down

ddcutil  -b 8 --sleep-multiplier .1 setvcp 10 + 1 &
ddcutil  -b 6 --sleep-multiplier .1 setvcp 10 + 1

ddcutil  -b 8 --sleep-multiplier .1 setvcp 10 - 1 &
ddcutil  -b 6 --sleep-multiplier .1 setvcp 10 - 1

See -b * is being set by ddcutil for your monitors. This will change by 1% on press.

*** Bug 500318 has been marked as a duplicate of this bug. ***

*** Bug 499519 has been marked as a duplicate of this bug. ***

the problem of the disappearance of the screen brightness adjustment seems to have disappeared with the new ddcutil 2.2, even if the anomaly that prevents the monitor from being turned off after a certain amount of time of inactivity remains (or at least it turns off and on again shortly after). evidently the 2 bugs were not connected.

Haven't looked and what got updated buy ddcutil is at 2.2. Can confirm that both monitors remember their % after waking up. Powering off monitors and on results in them remembering the %. After waking up all monitors have control.

Having a weird couple of issues since the update (hopefully not regressions).

I have a single monitor that even if set to 100% brightness, whenever the powerdevil service starts/restarts, it sets the monitor's max brightness to 30% (although reports in the UI that its' set to 100% despite the hardware on the monitor now reporting it being set to 30%).

Turning off/on the monitor restores it back to its max brightness, but if I restart powerdevil, it goes back to 30% brightness on the monitor.

Seeing this in my journalctl:

```
Mar 06 14:09:20 ravenwood org_kde_powerdevil[19736]: org.kde.powerdevil: org.kde.powerdevil.backlighthelper.brightness failed
Mar 06 14:09:20 ravenwood org_kde_powerdevil[19736]: org.kde.powerdevil: Handle button events action could not check for screen configuration
Mar 06 14:09:20 ravenwood org_kde_powerdevil[19736]: org.kde.powerdevil: org.kde.powerdevil.chargethresholdhelper.getthreshold failed "Charge thresholds are not supported by the kernel for this hardware"
```
The monitor is identical (same model) to the other two monitors I have in the setup which work fine.

(In reply to Kweeky from comment #77)
> I have a single monitor that even if set to 100% brightness, whenever the
> powerdevil service starts/restarts, it sets the monitor's max brightness to
> 30% (although reports in the UI that its' set to 100% despite the hardware
> on the monitor now reporting it being set to 30%).

> Turning off/on the monitor restores it back to its max brightness, but if I
> restart powerdevil, it goes back to 30% brightness on the monitor.
 
This is a different issue than the one reported here, which was for the brightness slider not always appearing in the widget. 
If you have an AMD GPU, you could be seeing bug 495003.

Otherwise, it could be bug 492481, or bug 490472. If your issue is one of those, please add some information in a comment:
- How is the monitor connected?
- Has changing screen brightness via Plasma ever worked?
- Can you paste the output of `kscreen-doctor -o`?

Thanks.

(In reply to TraceyC from comment #78)
> This is a different issue than the one reported here, which was for the
> brightness slider not always appearing in the widget. 
> If you have an AMD GPU, you could be seeing bug 495003.

I had the original issue (brightness disappearing from the widget) before, and since the update, this new issue has started occurring (which is why I thought it may be related) I do have an AMD GPU - so it may be as you suggest, the same bug as 495003. I will go provide extra information in the other ticket. Thank you!

I want to report that since the latest update from Fedora Rawhide I have seen that the brightness slider seems to be reliably there and set correctly (with respect to the actual brightness of my monitor) when awaking my laptop from sleep. This is a dramatic shift from a couple weeks ago (not entirely sure when this change landed on my laptop).

Volume also appears to be maintaining a correct level now. I think that change landed after I noticed the brightness slider's improved behavior.

I want to report that since the latest update from Fedora Rawhide I have seen that the brightness slider seems to be reliably there and set correctly (with respect to the actual brightness of my monitor) when awaking my laptop from sleep. This is a dramatic shift from a couple weeks ago (not entirely sure when this change landed on my laptop).

Volume also appears to be maintaining a correct level now. I think that change landed after I noticed the brightness slider's improved behavior.