Paul, re your concerns/questions:As to the API capabilities diverging from the command line capabilities, the current set of API functions reflect my experience building a Qt based C++ GUI, ddcui. The API has been stable for some time now. What's absent from the API are features that only make sense in the command line environment, or that have proven not particularly useful. If additional services prove necessary in the API, they can be added, but I prefer to add them only as need becomes apparent - the API is already quite large.
I'm unaware of plans to support DDC in the Linux kernel. The lower layers of what ddcutil does would be appropriate in the kernel, e.g. an I2C bus would directly be associated with a display instead of having to be discovered, I2C command retry, tuning I2C bus frequency, adjusting sleeps mandated by the DDC protocol. 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. For example, the DDC/CI spec mandates that an unsupported feature bit be set in the response to a query for the value of an unsupported feature. Some monitors instead misuse the DDC Null Message for this purpose, and others simply return successfully but with all value bytes 0.
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 KDE-Neon folks currently use a private copy of libddcutil for this purpose.)
On 1/25/20 9:14 PM, Paul Wise wrote:
On Sat, Jan 25, 2020 at 11:13 PM Sanford Rockowitz wrote:What's unusual is that the command line version does not depend on the shared library. Both versions are built from the same source package...Is this design just atypical, or does it violate Debian practice in some way?It is hard to say without reviewing a lot libraries, but think the practices of different upstreams vary widely, some tools solely wrap shared libraries, some have an additional "private" shared library, some use your approach. I don't think it violates any Debian practice that I can think of. One downside in the case of ddcutil is that the command-line tools will have a different set of capabilities to any tools built on the shared library (GUIs etc). BTW, are you aware of any effort to support DDC in the Linux kernel? It would be useful to be able to control monitor brightness etc from standard graphical interfaces that can currently only control laptop screen brightness.