Kernel 5.10 addressed a long standing problem with the I2C
implementation for DisplayPort Multi-Stream Transport. Only I2C reads
were implemented, not writes. (See the nearly 4 year long thread
<https://gitlab.freedesktop.org/drm/intel/-/issues/37>at
freedesktop.org.) As a result it was possible to read the EDID, but DDC
communication failed. ddcutil reported such displays as "Invalid".
Unfortunately, there are problems with the implementation in 5.10 that
ddcutil at least partially works around. In particular, the same
display can appear to be connected at 2 different /dev/i2c addresses,
only one of which supports DDC.
All the connectors on a docking station, whether DP, DVI, or HDMI, are
on a DisplayPort MST chain. As Joris notes, the Thunderbolt connection
on recent systems uses MST, so recent Type-C connected displays also
didn't work.
Joris's report is the first indication I've had that there are displays
(HDMI, not on a docking station) which ddcutil 0.9.9 successfully
communicated with prior to kernel 5.10, but on on kernel 5.10 or
later. Modulo that, use of 0.9.9 with kernel 5.10 does not constitute
a regression. ddcutil 0.9.9 continues to work with the vast majority
of displays on kernel 5.10. It simply doesn't add functionality. Joris,
if there really is a loss of functionality, can you submit, either here
or on the ddcutil issue tracker
<https://github.com/rockowitz/ddcutil/issues> at Github) the output of
"ddcutil environment --verbose" for ddcutil 0.9.9 and "ddcutil
environment --very-verbose" for ddcutil 1.1.0 for both kernel 5.10 and
one earlier than 5.10.
There is no simple patch that would bring 0.9.9 up to the functionality
of 1.1.0 for MST displays. The changes were extensive.
On 5/15/21 11:34 AM, Andrey Rahmatullin wrote:
On Sat, May 15, 2021 at 10:36:23AM -0400, Sanford Rockowitz wrote:
ddcutil 1.1.0 was uploaded to mentors on 4/22. Per the sponsor (Andrey
Rahmatulin) it was not moved to sid because of the freeze for Bullseye.
If the package doesn't work with the bullseye kernel it's a grave bug, not
important, and the package should be fixed (or removed).
Ti be eligible for bullseye the update should be a minimal patch added to
the bullseye version.
What do you think?
On 5/14/21 1:10 AM, Joris wrote:
Package: ddcutil
Version: 0.9.9-2
Severity: important
Tags: upstream
X-Debbugs-Cc: jo...@v5.be
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages ddcutil depends on:
ii i2c-tools 4.2-1+b1
ii libc6 2.31-11
ii libdrm2 2.4.104-1
ii libglib2.0-0 2.66.8-1
ii libudev1 247.3-5
ii libx11-6 2:1.7.0-2
ii libxrandr2 2:1.5.1-1
ii pci.ids 0.0~2021.02.08-1
ii usb.ids 2021.03.31-1
ii usbutils 1:013-3
ddcutil recommends no packages.
ddcutil suggests no packages.
-- no debconf information
>From the release information on ddcutil (http://www.ddcutil.com/release_notes/) it seems
Linux kernel 5.10 made changes. They are listed as "docking stations" but in my
experience also apply to directly connected HDMI and Thunderbolt displays.
Ddcutil 1.0.1 and 1.1.0 include workarounds for this kernel. On my system
bringing back the same capabilities I had under kernel 5.8, whereas with
ddcutil 0.9.9 on kernel 5.10 there was simply no device detected.
As 5.10 seems to be the default in the upcoming Debian release, it would be
very nice to get ddcutil updated as well.
I had no issue building ddcutil from source.
