https://bugs.kde.org/show_bug.cgi?id=438476
Sanford Rockowitz <kdeb...@minsoft.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kdeb...@minsoft.com
--- Comment #4 from Sanford Rockowitz <kdeb...@minsoft.com> ---
I am the developer of ddcutil. I have a few general comments, and a question.
First, the ddcutil related code in PowerDevil is a proof-of-concept
implementation, originally written to a pre 1.0 release of ddcutil. Its use of
the current API is convoluted, and it doesn't handle multiple monitors. To be
production quality it needs to be rewritten.
Second, monitors vary in the quality of their DDC/CI implementation. Most are
stable at the spec'd standard I2C bus speed of 100K and using the delays
between operations mandated by the DDC/CI spec. Communication errors can
sometimes be addressed by increasing the time ddcutil spends sleeping between
DDC/CI operations (the "sleep-multiplier" value). Unfortunately, no video
driver allows for tuning the speed of the I2C bus below the lowest spec'd value
of 100K.
Third, the DDC/CI implementation in the proprietary Nvidia driver (which is
what I assume "Nvidia blob" refers to) is, shall we say, problematic. The
special Nvidia settings (options nvidia
NVreg_RegistryDwords=RMUseSwI2c=0x01;RMI2cSpeed=100) force the I2C bus speed to
the standard 100K value. Apparently the Nvidia driver defaults to a higher
speed. Some monitors will work at the higher speed, many will not, which would
explain the "sometimes it makes a difference, sometimes it does not" behaviour
of the special Nvidia settings.
Also, ddcutil 1.3 simplified communication with driver i2c-dev by using its
ioctl() interface exclusively, as opposed to the higher level file io
write()/read() operations. The ioctl() and write()/read() interfaces invoke
video driver operations using different functions in the driver API (for any
driver). It turned out that, depending on how the Nvidia driver was built, it
would reject calls to the function used for the file io interface. According
to the i2c subsystem folks, this is because the Nvidia driver incorrectly
interpreted a flag by which i2c-dev tells the video driver that i2c-dev is
capable of DMA transfers to instead mean that DMA transfer is required. The
net result for ddcutil is that a painfully large amount of code had to go back
into release 1.4 to handle this special case.
Regarding the problems of using libddcutil in a daemon, first I have to say
that I haven't tried it. Building such a daemon is on the "sometime in the
future" to do list. One issue is that there's no way to prevent different
instances of applications, not just ddcutil, from using the I2C bus, and
clobbering each other. The best that libddcutil can do at present is prevent
different threads in the libddcutil instance from opening the same /dev/i2c
bus.
Beyond that issue of contention, it's not apparent to me why libddcutil should
be unusable when used with dlopen() etc., and I'd like to understand what the
problem is. zvova, please send me your test code. You can use either my email
address (rockow...@minsoft.com) or (even better) as an issue on the github bug
tracker (https://github.com/rockowitz/ddcutil/issues).
--
You are receiving this mail because:
You are watching all bug changes.
