[BUG] Screen freeze when changing brightness

[Rashad-707]

I'm trying to use ddcutil to change brightness of external monitor, sometimes running the command from terminal works and sometimes freeze the screen until I reboot, I also want to use it with eww widget scale to change the brightness but always the screen freeze when I try to change it.

[rockowitz]

Please execute ddcutil environment --verbose as root, and submit the output as an attachment.

Please describe your hardware and software environment.

If you are using an old version of dccutil, which is probably the case if you've used the version included in a distribution, please try with version 1.1.0 or later from this repo,

[Rashad-707]

log.txt gpu is amd radeon rx 5500 xt cpu amd ryzen 3700x system arch linux with kde and dwm this is the otput of ddcutil --version

ddcutil 1.1.0
Built with support for USB connected displays.
Built without function failure simulation.
Built with libdrm services.

Copyright (C) 2015-2021 Sanford Rockowitz
License GPLv2: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[rockowitz]

Hangs like this have been seen before. They are quite elusive to diagnose. See #159 #131 #86.

Are you running ddcutil in a script?

Try running ddcutil --trace i2c --tid setvcp 10 n (where n is your desired brightness level). This should help identify the system call that is hanging. Also, the dmesg output may give a clue as to what is happening. I would expect that ps output will show that ddcutil is in status uninterruptible sleep (D).

[Rashad-707]

Yes I'm running it from script this is the script

#!/usr/bin/env bash
bright=$(printf '%.0f' $1)
ddcutil setvcp 10 $bright --display 1

this is the output of ddcutil --trace i2c --tid setvcp 10 90 log.txt

[rockowitz]

Your script should pose no problems. The concern would be if multiple ddcutil calls occured in succession.

I should have been clearer. I need to see the output of ddcutil --trace i2c --tid setvcp 10 90 for a run that hangs, which should indicate the system call that's hanging. It's a nuisance, I know, to see all that output if the hangs are only occasional. More precisely, I only need to see the last 20 lines or so before the hang, not the full output, so it should be possible to screen scrape the needed information.

[Rashad-707]

I'm not sure if this output works, but I ran this ddcutil --trace i2c --tid setvcp 10 $bright | cat > ~/log2.txt through the script and clear the file when it wasn't hanging until it hang, and this is the output log2.txt

[Rashad-707]

and this ddcutil --trace i2c --tid setvcp 10 90 from the terminal when it hang

[rockowitz]

@sierratango88 @Rashad-707

Having returned from vacation and now having good internet access, I've taken another look at hangs and other failures with the amdgpu driver. What they have in common is a Navi GPU. There was a bug in the amdgpu driver that should have been fixed by now - see sensors-detect causes amdgpu kernel errors when probing i2c bus There's a workaround for this problem in ddcutil 1.1.0, but it may not be robust enough. See issue #194.

As the next step in diagnosing this situation, please run the following command and submit the output as an attachment:

awk '{print FILENAME ":" $0}' /sys/bus/i2c/devices/*/name

[ghost]

@rockowitz

I did notice that bug before when probing the I2C bus with either sensors-detect or ddcutil detect. It would leave some errors in the logs and prevent my secondary monitor from waking after resuming from suspend. Rebooting would not fix it, only pulling the power cable on the monitor did. I don't see the problem anymore except for very recently when I ran ddcutil interrogate.

It is interesting to see Rashad having some success with ddcutil using the same GPU as mine (RX 5500 XT). I have never been able to get ddcutil to detect my monitors after trying for about one year. The subvendor of my GPU is ASUS. Not sure if subvendors alter the GPU in any way that affects DDC/CI.

Here is the output from your requested command:

/sys/bus/i2c/devices/0-0050/name:spd
/sys/bus/i2c/devices/0-0051/name:spd
/sys/bus/i2c/devices/0-0052/name:spd
/sys/bus/i2c/devices/0-0053/name:spd
/sys/bus/i2c/devices/i2c-0/name:SMBus I801 adapter at f000
/sys/bus/i2c/devices/i2c-1/name:AMDGPU DM i2c hw bus 0
/sys/bus/i2c/devices/i2c-2/name:AMDGPU DM i2c hw bus 1
/sys/bus/i2c/devices/i2c-3/name:AMDGPU DM i2c hw bus 2
/sys/bus/i2c/devices/i2c-4/name:AMDGPU DM i2c hw bus 3
/sys/bus/i2c/devices/i2c-5/name:AMDGPU DM aux hw bus 0
/sys/bus/i2c/devices/i2c-6/name:AMDGPU DM aux hw bus 1
/sys/bus/i2c/devices/i2c-7/name:AMDGPU DM aux hw bus 2

[notgood]

Won't open new bugreport, as my issue seems to be similar.

Arch kernel 5.15.5, ddcutil 1.1.0, AMD Radeon RX 6900 XT. List of I2C devices: /sys/bus/i2c/devices/i2c-0/name:AMDGPU SMU /sys/bus/i2c/devices/i2c-1/name:AMDGPU DM i2c hw bus 0 /sys/bus/i2c/devices/i2c-2/name:AMDGPU DM i2c hw bus 1 /sys/bus/i2c/devices/i2c-3/name:AMDGPU DM i2c hw bus 2 /sys/bus/i2c/devices/i2c-4/name:AMDGPU DM i2c hw bus 3 /sys/bus/i2c/devices/i2c-5/name:AMDGPU DM aux hw bus 0 /sys/bus/i2c/devices/i2c-6/name:AMDGPU DM aux hw bus 1 /sys/bus/i2c/devices/i2c-7/name:AMDGPU DM aux hw bus 2

Made two keybindings for brightness control "ddcutil setvcp 10 + 10" (and -10). Slowly changing brightness works OK, but as soon as I quickly spam shortcut key, system just dies, hard hang.

Workaround is adding "--bus 4" to command, it seems without such param ddcutil is touching some other i2c bus in a way AMDGPU doesn't like it.