On 1/26/20 11:45 PM, Paul Wise wrote:
On Sun, 2020-01-26 at 23:01 -0500, Sanford Rockowitz wrote:

I'm unaware of plans to support DDC in the Linux kernel.
I just discovered the ddcci-driver-linux project. It is available in
Debian in the ddcci-dkms binary package. I've tried it locally but it
doesn't appear to be very useful for me yet.

https://gitlab.com/ddcci-driver-linux/ddcci-driver-linux
I checked out this project a couple years ago.  It could conceivably replace the very lowest layers of ddcutil. I will take a closer look.
a Qt based C++ GUI, ddcui
I note that this isn't available in Debian yet, I am assuming that is
why you have brought this discussion to the list.
ddcui is not in Debian because, simply put, it's not ready for prime time.  In particular, the Qt code related to layout and formatting needs to be reworked.  i's need to be dotted, and t's crossed.

The libddcutil API, on the other hand, is solid and stable, and so belongs in Debian.  There had been a suggestion that it was odd for the command line version of ddcutil to not use the library.  My question to the list was whether this is acceptable, which it appears to be.

If you're curious, the latest libddcutil and ddcui can be found at my PPA, https://launchpad.net/~rockowitz/+archive/ubuntu/ddcutil. <https://launchpad.net/~rockowitz/+archive/ubuntu/ddcutil>
I'd very much appreciate any feedback you might have.
On the other hand, there are things that ddcutil does to accommodate
variations in monitor DDC/CI implementations that probably don't
belong in the kernel.
I think the Linux kernel already deals with quirks for various types of
hardware, so I don't think it would be too much trouble to maintain the
code for the DDC quirk types in the Linux kernel and the application of
those quirks in udev. I think that this is typically how hardware
quirks are applied on Linux based distributions.

Finally, unifying brightness control means alternatively using ACPI for
laptop displays and DDC for others. It seems to me that even if the
kernel supported DDC, this ACPI/DDC unification is more appropriately
done at a higher level than the kernel, probably in xrandr.  For the
time being, an application can unify these facilities using libddcutil
for DDC.
The Linux kernel already exposes LED information and control, display
brightness and control and so on in standard ways, which are then
consumed by userland tools, either directly or via daemons. So I think
it isn't too much of a stretch for those to be available for DDC too.
xrandr isn't used by Wayland based shells so that isn't the appropriate
layer to introduce this feature. Keeping the DDC code out of the Linux
kernel means that every single desktop has to add support for
libddcutil instead of just adding it to Linux. Since Wayland shells run
as the user rather than root, Wayland apps are not allowed to be run as
root and accessing i2c devices on Linux typically requires root,
control of monitor brightness via DDC won't be available for Wayland
shells/apps, only via terminal or X11 applications run via sudo.

(The KDE-Neon folks currently use a private copy of libddcutil
for this purpose.)
Any particular reason they can't use the official version?

Because it's not in Debian.  Once it is, they will stop using a private copy.

PS: are you aware of the ddccontrol project (also in Debian)?
It has a monitor database, shared library, command-line tools and GUI.

https://github.com/ddccontrol/ddccontrol
https://github.com/ddccontrol/ddccontrol-db
This is a very old project that was briefly resurrected a few years ago.  Its design makes it very brittle.  See http://www.ddcutil.com/ddccontrol/#comparison-with-ddccontrol. Because ddcutil relies on /dev/i2c instead of trying to program I2C devices at the PCI level, ddcutil does a much better job of detecting and communicating with monitors, and coping with new device drivers.  ddccontrol relies on its monitor database for feature interpretation.  Trying to keep that up to date is like sweeping sand on a beach.  ddcutil, on the other hand, relies on a detailed understanding of the Monitor Control Command Set (MCCS) specification for feature interpretation.  See the output of command "ddcutil vcpinfo --verbose", to get a sense of what ddcutil knows, or look at how ddcui reports features.
It would be great if yourself and the folks from ddcci-driver-linux and
ddccontrol could work together in order to come up with a modern design
and implementation for supporting control of monitors under Linux.


Reply via email to