Bug#988489: ddcutil: Kernel 5.10 changes require ddcutil 1.1

Joris

unread,

May 14, 2021, 1:20:03 AM5/14/21

to

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.

Sanford Rockowitz

unread,

May 15, 2021, 10:50:03 AM5/15/21

to

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.

Andrey Rahmatullin

unread,

May 15, 2021, 12:10:04 PM5/15/21

to

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?

--
WBR, wRAR

signature.asc

Sanford Rockowitz

unread,

May 15, 2021, 4:20:04 PM5/15/21

to

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 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 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.

Joris

unread,

May 19, 2021, 11:10:04 AM5/19/21

to

Hi,

After some digging, I think we should position it to grave. I was unable to find a scenario with ddcutil working in linux 5.10 but my test setups are limited.

The version number jumps may feel significant, but the changes (http://www.ddcutil.com/release_notes/ + http://www.ddcutil.com/prior_announcements/) appear to be limited (yet critical!) and "inside" the binary (heuristics) - but I'm not suited to properly judge that.

There are no reverse dependencies, so that really limits the risk of updating I think.

Kind regards,

Op za 15 mei 2021 om 17:35 schreef Andrey Rahmatullin <wr...@debian.org>:

Sanford Rockowitz

unread,

May 19, 2021, 12:10:04 PM5/19/21

to

Joris, if there's been a loss of functionality of ddcutil 0.9.9 with kernel 5.8 (or earlier) vs kernel 5.10 (or later) I need to understand what that is, irrespective of the decision on inclusion of ddcutil in bullseye (well above my pay grade). To date I've had no other problem reports in that category. Please submit the output of "ddcutil environment --verbose" for ddcutil 0.9.9 on both kernel 5.9 (or earlier) and 5.10 (or later). Thank you.