Hello- I'm currently running a kernel directly based upon agd5f's drm-next-4.17-wip (commit aa876beccdd9d6694df78ebbb395eb206d4cb84e at the time of writing this) (I've applied a couple of EFI fixups and tweaked the .gitignore, but none of my cherry-picked commits should be dinking with the DRM/KMS/AMDGPU code). The system boots, and brings up the AMDGPU driver and FB with no issue, but the display (a Samsung S27C650 attached via DisplayPort) fails to sleep. I've tried forcing it into sleep mode via setterm, to no avail. There is no error/warning (or info of any kind) logged to the kernel console. If someone could suggest a kernel command-line boot option to increase the verbosity of the AMDGPU driver, I would be very appreciative. Thank you in advance. -Robin K.
You can try amdgpu.dc_log=1 and drm.debug=4. Does the display blank out and then wake right back up or do you see no change at all on the display when trying to enter dpms?
(In reply to Harry Wentland from comment #1) > You can try amdgpu.dc_log=1 and drm.debug=4. Thanks, I'll try both of these and report back. > > Does the display blank out and then wake right back up or do you see no > change at all on the display when trying to enter dpms? I see no change whatsoever.
Curiously enough this is the first time I've heard of setterm. I'm not sure if it's really supported but I tried amdgpu, non-amdgpu (i.e. vbios), and an Intel platform and on neither I can get setterm --powersafe on/off to do anything, no matter whether in a VT or in X (seems like it's intended for VT). We do support "xset -display :0.0 dpms force off" when you're in X.
I believe setterm uses vesa vbi calls (i.e., calls into the legacy vesa real mode vbi interface) to blank the screen which only works on boards with a legacy vbi interface (i.e., won't work UEFI systems). Doing that goes behind the driver's back and touches the hw directly. Additionally, vbi support for multiple displays is pretty much non existent so even if your board supports vbi, it's not likely to work if you have multiple displays or are using a display configuration different from what came up at boot.
(In reply to Harry Wentland from comment #3) > Curiously enough this is the first time I've heard of setterm. I'm not sure > if it's really supported but I tried amdgpu, non-amdgpu (i.e. vbios), and an > Intel platform and on neither I can get setterm --powersafe on/off to do > anything, no matter whether in a VT or in X (seems like it's intended for > VT). > > We do support "xset -display :0.0 dpms force off" when you're in X. Huh, interesting. I can't (yet) test 'xset -display :0.0 dpms force off', since in still having issues bringing X/Wayland up, but that's a separate bug. No useful output from amdgpu.dc_log=1 and drm.debug=4 set yet, but I'm trying agd5f's latest push to drm-next-4.17-wip, which has a commit that looks like it may contain a fix, so we'll see.
Reopening since the DPMS timeout (that *used to* work) still isn't working.
Works with current-ish drm-next-4.18-next commit (52132fd03504140b4cc58c01b19e82929a03af7a), most recent issue was an omission on my part (failing to put consoleblank=600 (or some other non-zero integer value) in the kernel commandline). Don't know which commit fixed things, as I haven't bisected my way through a few (at least) weeks of commit history. I can have a go at it if someone really wants me to.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.