https://bugs.kde.org/show_bug.cgi?id=481793
Jakob Petsovits <jpe...@petsovits.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
Latest Commit| |https://invent.kde.org/plas
| |ma/powerdevil/-/commit/db4a
| |6c79bc5f58dccc43805502c5814
| |5ef341ea1
--- Comment #5 from Jakob Petsovits <jpe...@petsovits.com> ---
Git commit db4a6c79bc5f58dccc43805502c58145ef341ea1 by Jakob Petsovits.
Committed on 16/03/2024 at 23:26.
Pushed by jpetso into branch 'master'.
daemon: Avoid constantly locking ddcutil display handles
Since libddcutil implemented functionality for per-monitor
device lock files, other programs that are also using libddcutil
(such as the ddcutil CLI itself) were blocked from performing
monitor commands because PowerDevil kept all its handles open.
The better way of interacting with libddcutil as a long-running
program 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 program
to set display brightness independently without PowerDevil noticing.
That seems like a smaller evil though, and can't be fixed by simply
using libddcutil itself as it cannot signal any VCP changes.
Common infrastructure such as digitaltrails/ddcutil-service or a
future kernel DRM interface for DDC/CI could help to mitigate this.
M +16 -22 daemon/controllers/ddcutilbrightness.cpp
M +79 -14 daemon/controllers/ddcutildisplay.cpp
M +4 -2 daemon/controllers/ddcutildisplay.h
https://invent.kde.org/plasma/powerdevil/-/commit/db4a6c79bc5f58dccc43805502c58145ef341ea1
--
You are receiving this mail because:
You are watching all bug changes.
