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.
