Brightness slider disappears after few minutes on v2.2.6-dev

[YanEx13]

Problem Description

The brightness control slider for an external monitor (Philips 27M2N5500) connected via DisplayPort (USB-C) is available immediately after boot but consistently disappears from the system settings/tray after 2-5 minutes of uptime.
This issue is NOT present in version 2.1.4. In the older version, the brightness slider remains stable and visible throughout the entire session.

The "Nvidia Workaround" Findings

I discovered that applying the following setting in /etc/modprobe.d/nvidia_i2c.conf resolves the issue for the 2.2.x branch:
options nvidia NVreg_RegistryDwords=RMUseSwI2c=0x01;RMI2cSpeed=100

With this parameter, the slider remains stable on the latest versions. However, this was NOT required for version 2.1.4.

Environment

Operating System: CachyOS Linux
KDE Plasma Version: 6.5.5
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.19.0-2-cachyos (64-bit)
Graphics Platform: Wayland
Processors: 12 × 11th Gen Intel® Core™ i5-11400H @ 2.70GHz
Memory: 16 ГиБ of RAM (15.3 ГиБ usable)
Graphics Processor 1: NVIDIA GeForce RTX 3060 Laptop GPU
Graphics Processor 2: Intel® UHD Graphics
Manufacturer: HP
Product Name: Victus by HP Laptop

Additional Information

Related KDE Bug Report: https://bugs.kde.org/show_bug.cgi?id=516066

Video demonstration: https://github.com/user-attachments/assets/36c3bba1-04c2-4b11-b6c1-c1c1405c0527

ddcutil_interrogate.txt

[rockowitz]

The interrogate output submitted does not correspond to the bug description. It's for an Asus Z170A desktop system using the amdgpu driver. Incidentally, as configured ddcutil/libddcutil will execute only if run as root, as permissions for non-root users are not configured. It will not work with powerdevil.

First, built from branch 2.2.6-dev. All the following should be done on that branch.

Execute ddcutil interrogate both as root and as a non-root use, and submit the output.

Next, ensure your $HOME/.config/ddcutil/ddcutilrc file contains at least the following:

[global]
options: --trace-to-syslog
options: --trace conn 
options: --trcfunc all_edids_readable_using_i2c
options: --trcfunc i2c_edid_exists  --trcback i2c_edid_exists
options: --trcfunc i2c_check_bus  --trcback i2c_check_bus

For configuration file changes to take effect, you need to log out of KDE Plasma and log back in, or you can use command systemctl --user restart plasma-powerdevil to just restart powerdevil.

Please submit the relevant segment of output from journalctl -b -t org_kde_powerdevil. Each segment starts with a line that begins "Starting libddutil."

Independently, add one then the other of the following lines to the configuration file and restart powerdevil.

options: --disable-try-get-edid-from-sysfs

options: --f27  # disables all_edids_readable_using_i2c() 

Again, extract and submit the relevant journalctl output. Did the behaviour change?

Finally, and separately, there appears to be a bug in interrogate that causes the final portion of the output to be lost. Please run ls -lR /sys/devices and submit the output.

I realize that, in the interest of expediting a solution, I'm asking you to do a lot of work at one time, not all of which will be relevant. Splitting things out into multiple exchanges would take much longer to resolve the problem.

[rockowitz]

Also a basic question I neglected to ask. Does the problem occur when the monitor is connected using HDMI, not DP?

[YanEx13]

Hello, thank you for the quick response, and please accept my apologies for the delay in replying. I have followed your instructions and documented the process step-by-step in the order they were performed. However, I would like to clarify a potential misunderstanding: I do not own an Asus Z170A system with an AMD GPU, and I couldn't find any mention of such hardware in my previous attachments.

1. When using HDMI, the problem persists; the behavior is identical when connected via DP.
2. The package was removed using: sudo pacman -Rsdd ddcutil
3. Build and installation of ddcutil from source were performed.
4. Due to a broken powerdevil, I added the custom build directory to the system shared library search path: echo "/usr/local/lib" | sudo tee /etc/ld.so.conf.d/ddcutil-local.conf
5. I manually added my user to the group using: sudo usermod yanex -aG i2c
6. A configuration file was manually created at $HOME/.config/ddcutil/ddcutilrc with the following content:

ddcutilrc

[global]
options: --trace-to-syslog
options: --trace conn
options: --trcfunc all_edids_readable_using_i2c
options: --trcfunc i2c_edid_exists --trcback i2c_edid_exists
options: --trcfunc i2c_check_bus --trcback i2c_check_bus

7. The command "ddcutil interrogate" was run with and without sudo.

interrogate_user_yanex.txt

interrogate_sudo_yanex.txt

8. Output journalctl -b -t org_kde_powerdevil obtained:

journalctl_yanex_1.txt

8.1. The first line options: --disable-try-get-edid-from-sysfs was added to the configuration file. Output obtained:

journalctl_yanex_2.txt

8.2. The second line options: --f27 # disables all_edids_readable_using_i2c() was added to the configuration file. Output obtained:

journalctl_yanex_3.txt

As a result, I had a config with the following content, but the behavior did not change at all:

ddcutilrc

[global]
options: --trace-to-syslog
options: --trace conn
options: --trcfunc all_edids_readable_using_i2c
options: --trcfunc i2c_edid_exists --trcback i2c_edid_exists
options: --trcfunc i2c_check_bus --trcback i2c_check_bus
options: --disable-try-get-edid-from-sysfs
options: --f27 # disables all_edids_readable_using_i2c()

9. Output ls -lR /sys/devices obtained:

sys_devices_yanex.txt

[rockowitz]

I have an answer for you, and I don't.

What I see in the journalctl output is that API call ddca_set_non_table_vcp_value() fails with status code -3023, which is DDCRC_VERIFY. That is, after setting the new value the call reads the value to confirm it has been set, but the value is not what is expected. When this happens (after several retries) Powerdevil removes the monitor from its list. So that explains why the monitor disappears after a while. As a workaround, try putting line options: --noverify in ddcutilrc. Does this resolve the problem?

The question, of course, is why you suddenly need the Nvidia settings for communication to work. This I cannot answer. The interrogate output includes the dynamic sleep cache, which shows that the current sleep-multiplier is at 0. Try putting options: --disable-dynamic-sleep in ddcutilrc, or even setting a high-sleep-multiplier using options: --sleep-multiplier 2.0. However, this would not explain why you did not need the Nvidia settings with 2.1.4 but do with 2.2.6-dev.

Keep in mind that for changed configuration settings in ddcutilrc to take effect, you need to log out or at least restart powerdevil using systemctl --user restart plasma-powerdevil.

[YanEx13]

Adding options: --noverify indeed fixed the issue. The brightness changes correctly and the slider no longer disappears.

Here are the results of testing the other options independently (with options: --noverify removed):

1. options: --disable-dynamic-sleep - the slider still disappears after a while; I didn't notice any difference in behavior.
2. options: --sleep-multiplier 2.0 - the situation is different here: the brightness slider does not appear at all.

If necessary, I can perform additional tests, specifically with version 2.1.4.

[rockowitz]

Re (2), I suspect there may have been a typo in your config file, which would cause libddcutil startup to fail. If that's the case, shortly after the "Starting libddcutil" line in the system journal there would be a message in this regard. If that's not the case, send me the journal output. At this point, the voluminous trace output just clutters the log, so delete the trace related lines from ddcutilrc.

[YanEx13]

It seems the issue was indeed a typo (or a syntax error...?). With this change:

[global] 
options: --sleep-multiplier 2 

it starts correctly, but the slider still disappears after a while.

journalctl_yanex_sd.txt

[rockowitz]

To summarize, DDC communication was likely marginal to begin with. Some change in ddcutil pushed it over the edge and you now need to use the documented special nvidia settings. There's nothing more to do from a ddcutil perspective in this regard.

What's unfortunately confusing is how PowerDevil quietly drops the monitor because of a validation error. There is one line in the journalctl output that reports the monitor is being dropped, but that is easily missed. and one need to know to look in the system journal. The error is not reported at the user interface level. I have encountered something similar with a Samsung monitor that always reports 0 as the current brightness value. By contrast, ddcui disables verification on ddca_set_non_table_vcp_value(), then explicitly reads the current value and puts up a dialog box if the current value does not match the value set. I have suggested to the PowerDevil folks that they also disable verification so the ddca_set_non_table_vcp_value() call does not fail, but that is a user-interface design decision.

Given this analysis, I am removing the Bug label from this issue. The problems are in the Nvidia driver and how PowerDevil handles the error.