In order to make this backport of MR !333 happen, I added to the branch a cherry-pick of commit db4a6c79 (as separate commit) as well as the function signature change of generateDisplayId() from commit a6b9cf5f (merged into the main commit).
Paths are not the same in master anymore, and the old version of DDCutilDisplay still uses r/w locks instead of a worker thread for calling the ddcutil brightness setter. Nonetheless, the changes themselves transferred to the old version without significant conflicts and I'd consider this safe enough to have it on Plasma/6.0 as well.
Since libddcutil implemented functionality for per-monitordevice lock files, other programs that are also using libddcutil(such as the ddcutil CLI itself) were blocked from performingmonitor commands because PowerDevil kept all its handles open.
The better way of interacting with libddcutil as a long-runningprogram is to store a DDCA_Display_Ref for each monitor in question,use it to get a temporary display handle, and close it again.
Now we can peacefully coexist with other libddcutil programs,and users can e.g. query their monitor properties again.
As a slight downside, this means it's possible for another programto set display brightness independently without PowerDevil noticing.That seems like a smaller evil though, and can't be fixed by simplyusing libddcutil itself as it cannot signal any VCP changes.Common infrastructure such as digitaltrails/ddcutil-service or afuture kernel DRM interface for DDC/CI could help to mitigate this.
BUG: 481793FIXED-IN: 6.0.4
(cherry picked from commit db4a6c79)
(generateDisplayId() changes extracted from commit a6b9cf5f)