| Bug ID | 104888 |
|---|---|
| Summary | DPMS issue w/ GFX8/Polaris10/Ellesmere/Rx-480-8GiB & agd5= f's drm-next-4.17-wip |
| Product | DRI |
| Version | XOrg git |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | robink@creosotehill.org |
Hello-
I'm currently running a kernel directly based upon agd5f's
drm-next-4.17-wip (commit aa876beccdd9d6694df78ebbb395eb206d4cb84e at the t=
ime
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 someo=
ne
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=3D1 and drm.debug=3D4. Does the display blank out and then wake right back up or do you see no cha= nge at all on the display when trying to enter dpms?
(In reply to Harry Wentland from comment #1) > You can try amdgpu.dc_log=3D1 and drm.debug=3D4.= Thanks, I'll try both of these and report back. >=20 > 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 I= ntel 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.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | NOTABUG |
I believe setterm uses vesa vbi calls (i.e., calls into the le= gacy 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 behi= nd the driver's back and touches the hw directly. Additionally, vbi support f= or 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 hea= rd 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). >=20 > We do support "xset -display :0.0 dpms force off" when you'r= e 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 b= ug. No useful output from amdgpu.dc_log=3D1 and drm.debug=3D4 set yet, but I'm = trying agd5f's latest push to drm-next-4.17-wip, which has a commit that looks lik= e it may contain a fix, so we'll see.
| What | Removed | Added |
|---|---|---|
| Status | RESOLVED | REOPENED |
| Resolution | NOTABUG | --- |
Reopening since the DPMS timeout (that *used to* work) still i= sn't working.
| What | Removed | Added |
|---|---|---|
| Version | XOrg git | unspecified |
| What | Removed | Added |
|---|---|---|
| Resolution | --- | WORKSFORME |
| Status | REOPENED | RESOLVED |
Works with current-ish drm-next-4.18-next commit (52132fd03504140b4cc58c01b19e82929a03af7a), most recent issue was an omissi= on on my part (failing to put consoleblank=3D600 (or some other non-zero integ= er value) in the kernel commandline). Don't know which commit fixed things, a= s 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.