System cannot enter S0ix sleep after running ddcutil detect

[fanzhuyifan]

On my ASUS ROG Zephyrus G16, I cannot enter S0ix sleep after running ddcutil detect. Running arch linux with ddcutil 2.1.4. Also tested on ddcutil 2.0.0-release and 2.1.5-dev, and the issue exists on all.

Steps to reproduce:

• run cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us && sudo rtcwake -m mem -s 15 && cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us. Verify that the second number is bigger than the first, showing that the system has entered into s0ix sleep.
• run ddcutil detect
• rerun the first command. See that the two numbers are the same, showing that the system has not entered into s0ix sleep.

Other information

This happens both with and without setting the nvidia driver options in https://www.ddcutil.com/nvidia/.

Useful logs

Output of sudo ddcutil interrogate --verbose:
ddcutil-interrogate.txt
Output of ddcutil detect: ddcutil-detect.txt
Output of S0ixSelftestTool after running ddcutil detect (failed entry into s0ix):
20240611-15-32-s0ix-output.log
Output of S0ixSelftestTool before running ddcutil detect (successful entry into s0ix):
20240611-15-39-s0ix-output.log

System information

Operating System: Arch Linux
KDE Plasma Version: 6.1.80
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.1
Kernel Version: 6.9.3-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 20 × 13th Gen Intel® Core™ i9-13900H
Memory: 15.2 GiB of RAM
Graphics Processor: Mesa Intel® Graphics
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: ROG Zephyrus G16 GU603VV_GU603VV
System Version: 1.0

[rockowitz]

This Plasma merge request might be relevant to you: https://invent.kde.org/plasma/powerdevil/-/merge_requests/379

[fanzhuyifan]

This Plasma merge request might be relevant to you: https://invent.kde.org/plasma/powerdevil/-/merge_requests/379

Thanks! I am actually the author of that MR 😂

[rockowitz]

Once you've completely disabled powerdevil's use of libddcutil by using your patch, does running ddcutil detect still block entry to SI0x sleep?

[fanzhuyifan]

Once you've completely disabled powerdevil's use of libddcutil by using your patch, does running ddcutil detect still block entry to SI0x sleep?

Yes -- I verified that on a virtual console without entering any graphics environment. In fact powerdevil's use of libddcutil also blocked entry to S0ix sleep, and that's why I submitted the patch.

[rockowitz]

Let's try disabling parts of the initialization code using options --skip-ddc-checks and/or --bus with getvcp 10.

[fanzhuyifan]

Below are the commands I ran and the corresponding outputs. s0ix did not work after running any of them.

• ddcutil getvcp 10: Display not found
• ddcutil getvcp 10 --skip-ddc-checks:
  VCP (aka MCCS) version for display is undetected or less than 2.0. Interpretation may not be accurate.
  VCP code 0x10 (Brightness ): Maximum retries exceeded
• ddcutil getvcp 10 --bus 0 --skip-ddc-checks: No monitor detected on bus /dev/i2c-0
• ddcutil getvcp 10 --bus 0: No monitor detected on bus /dev/i2c-0

I restarted after running each command, and verified that s0ix works before running the commands. Then, I ran the command and verified that s0ix does not work.

[fanzhuyifan]

Did some testing with gdb breakpoints, and I narrowed down the first point of failure to be after the call to i2c_get_parsed_edid_by_fd.

[rockowitz]

I have one system here, a recent Lenovo Thinkpad P16 Gen 1 (Intel), capable of entering into S0ix sleep. Executing your commands always returns 0. Unfortunately, the S0ix self test tool fails on that system, with the symptoms reported in S0ix issue 23. I'll retry when there is a fix.

If the problem is in i2c_get_parsed_edid_by_fd(), the problem probably lies in called function i2c_get_raw_edid_by_fd(). There are multiple alternative paths through that code. The first is specified by option --use-file-io. The second is (currently) specified by utility option --f5. Does execution with either of these options trigger the problem?

Command get-edid similarly reads the EDID over the I2C bus. Does get-edid N|parse-edid trigger the problem where N is the number of some /dev/i2c-N device connected to an EDID? Where N is not?