PowerDevil in Plasma 6.0 and beyond

Community Blogs
1

Hi, I'm Jakob and this is my new KDE blog. Let's see how this goes as I haven't blogged for literally decades.

This is a companion discussion topic for the original entry at https://blogs.kde.org/2024/04/23/powerdevil-in-plasma-6.0-and-beyond/
10 Likes
2

Great read, thanks for the write-up!
I don’t think the performance icon is on spot. The lightnings made me think of electricity which I associate more with energy savings than performance. I propose a sprinter, or something with comic-like speed lines. A speed-meter with the indicator at max / right is a common icon, too.

2 Likes
3

I like that idea! CC @Anditosan with his icon design expertise. Personally I associate the speedometer icon also more with “speed” rather than balanced, even though on closer look the needle isn’t on the far right. Making an icon that intuitively conveys balanced a.k.a. “not too much of either” is no easy feat :stuck_out_tongue:

4

An actual balance? People might mistake that for law or justice. Yin and Yang or Taijitu might stand for balance, too. But it is associated with a religion.

5

In fact, when I search online, it seems that the symbol for performance most used is the one we use for balanced performance.

https://www.flaticon.com/search?word=performance%20power

6

Great blog post. Super comprehensive.

Your initial description of what powerdevil does makes me feel like there’s a substantial amount of conceptual overlap with KWin, at least on Wayland. Notably, KWin on Wayland ate monitor arrangement configuration in Plasma 6; KScreen is no longer involved except on X11 where it’s been feature-frozen.

Food for thought.

1 Like
7

Indeed. Note the sentence toward the bottom where it says that we want to move brightness handling into KWin. Here’s how I figure this will happen:

  1. We finish the work on per-monitor brightness support, with all the necessary refactoring and D-Bus API for the brightness applet to access.
  2. We take ScreenBrightnessController out of PowerDevil and put it into libkscreen as a library, similar to how DPMS has already been moved out.
  3. PowerDevil keeps using it on X11, but on Wayland, KWin uses the library and adds some fancy extra functionality that pure backlight adjustments can’t provide. PowerDevil forwards D-Bus calls to KWin via a new Wayland protocol.

There’s been some good discussion in this KWin issue, which I didn’t link from the blog post but is definitely on my mind as I go about further changes.

DPMS is already implemented by KWin in Wayland, with PowerDevil only figuring out when the screens should get turned off.

3 Likes
8

Hi Jacob,

I’m the developer of ddcutil. Very informative post, and looking at your code I’m impressed by what you’ve done. Please send me email at rockowitz@minsoft.com so we can communicate directly.

Regards,
Sanford

2 Likes
9

I’ve recently encountered a NVRAM limit on an old HP ZR24w that confirms the need for caution (at least for older monitors):

Quoting the latest vdu_controls README.md:

How many writes VDU NVRAM can accommodate is unknown, it is likely to vary by model and vintage. VDUs from past decades are likely to have NVRAM that can accommodate 10,000 to 100,000+ writes depending on the technology employed. For a ten year lifespan this might indicate a sustainable limit of only 2.7 writes per day or 27 writes per day respectively. Some modern types of NVRAM have upper limits that are for practical purposes unlimited, but the level of uptake of such technologies by the manufacturers is unknown (brighter back-lights, along with scene and gaming options, would appear to require increased durability).

I can confirm that a vintage-2010 VDU, which has been used for four years of intensive testing of vdu_controls, now reverts to its factory defaults whenever it loses power. This experience may indicate a write limit of at least 100,000 for a VDU of this vintage. I’ve subsequently implemented the initialization-preset feature as a replacement for failed NVRAM.

1 Like
10

Thanks. I think this makes a good case that we shouldn’t even apply dimming to external monitors in the future (at least by default).

1 Like
11

That would be preferable. I guess modern monitors might cope with more writes, so it would be reasonable to retain dimming as an option for those who feel like their monitors would be OK.

Note also that libddcutil does not check existing values before rewriting them. If it likely that a new value might equal the existing value, perhaps that could be checked before doing an unnecessary write.

My particular situation is somewhat unusual. I used this very old monitor to develop and test dimming-like transitions for vdu_controls. I did this repeatedly as part of my software release cycle. So I was really pounding on the NVRAM. In fact I first noticed the problem during release testing.

The NVRAM seems to be behaving better now. Probably because my frequency of writes to NVRAM has returned to normal (after I finished testing and released the software). Now the NVRAM changes mostly stick, and only sometimes fail. It feels like the monitor has a bad-block somewhere, and occasionally it gets allocated, but mostly not (maybe the firmware cycles through available NVRAM).

13

Bugs are reported only to https://bugs.kde.org.
A new thread is a good idea, this is irrelevant to this blog post.

1 Like
14

Brightness via DDC/CI will not be animated anymore in order to minimize the risk of shortened monitor lifespans.

I assume that was supposed to be “automated” and not “animated”?

15

I’m pretty sure that animation refers to stepping the brightness through intermediate values between the starting and finishing value. So going from 100% to 50% will now just be an abrupt change with only one ddcutil write to the monitor’s NVRAM, rather than including a bunch of NVRAM writes between the two values.

2 Likes
16

Another reason not to apply dimming to external displays by default is for laptops.

If the laptop is rebooted while disconnected from the display, when reconnecting the brightness control on the external monitor will not actually manipulate the external monitor’s brightness. It will instead use some sort of overlay or display gamma value manipulation to make it appear dimmer.

At least for my use case, there are times when I am out and about and need to Windows, so rebooting my device to access it via dual-boot is something I do often. While not a major issue, it is annoying to have to reboot the device every time I get home.

I tried using the disable environment variable as outlined in this blog post, but even when that is set the external monitor will use the software-based “brightness” control.

I have no idea how to stop this from happening, and combined with other weird KDE bugs I have experienced, I’ve just moved to Kubuntu 24.10, which can only change the laptop display’s brightness.

I did submit a bug report (id: 495433) on this, but I am not sure if this is a ddcutil issue or something else that KDE uses.

17

Following up on the “frugal writes” story, I just submitted a merge request to read and compare the brightness value in PowerDevil prior to writing it. I didn’t see @digitaltrails in the user list of KDE Invent, but feel free to review the patch anyway!