Bug 107297

Summary:	Changing resolution with xrandr causes display to turn off.
Product:	xorg	Reporter:	i.kalvachev
Component:	Driver/Radeon	Assignee:	xf86-video-ati maintainers <xorg-driver-ati>
Status:	RESOLVED FIXED	QA Contact:	Xorg Project Team <xorg-team>
Severity:	normal
Priority:	medium	Keywords:	bisected, patch, regression
Version:	git
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description i.kalvachev 2018-07-19 17:20:15 UTC

For some reason Slackware-current upgraded the radeon ddx driver to git-f533b1f6.
With it, when doing `radeon -s 1024x768` or `xrandr --output HDMI-0 --mode 1024x768`, the monitor would turn off.

Switching away from X to a kms console does restore image, but going back to X still turns the monitor off. Trying to restore the original video mode (typing blindly) also doesn't seem to fix the problem.


Here are some excerpts from logs that I find interesting:

xrandr -s 1024x768
---
Failed to change the screen configuration!
---

Xorg.0.log:
---
[ 39474.254] (II) RADEON(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[ 39474.317] (EE) RADEON(0): drmmode_do_crtc_dpms cannot get last vblank counter
[ 39474.318] (II) RADEON(0): Allocate new frame buffer 1024x768
[ 39474.319] (II) RADEON(0): VRAM usage limit set to 222746K
[ 39474.319] failed to add FB for modeset
[ 39474.351] (II) RADEON(0): EDID vendor "DEL", prod id 41055
[ 39474.351] (II) RADEON(0): Using hsync ranges from config file
[ 39474.351] (II) RADEON(0): Using vrefresh ranges from config file
[ 39474.351] (II) RADEON(0): Printing DDC gathered Modelines:
[ 39474.351] (II) RADEON(0): Modeline "1920x1080"x0.0  148.50  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP)
---

dmesg | grep -n 2
---
[39474.318762] radeon 0000:01:00.0: No GEM object associated to handle 0x0000000C, can't create framebuffer
[39474.318767] radeon 0000:01:00.0: No GEM object associated to handle 0x00000300, can't create framebuffer
---


Since the problem is regression I tried to bisect.
I finally landed on:
---
commit 3c4c0213c11d623cba7adbc28dde652694f2f758
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Jun 29 17:57:03 2018 +0200

    glamor: Use GBM for BO allocation when possible
    
    Inspired by amdgpu. This avoids various issues due to a GEM handle
    lifetime conflict between us and Mesa with current glamor.
---

It made sense, since I am using glamor on my AMD HD5670 (Redwood Evergreen).

After reporting my finding on IRC, MrCooper (Michel Dänzer) provided link to a patch:
https://patchwork.freedesktop.org/patch/239365/

I tested the patch and I can confirm that it does work.

Something more, it also seems to solve another cosmetics issue that appeared after upgrading to xorg 1.20.0 server. Sometimes doing xrandr mode switching, the desktop would go black or the image would get corrupted, until each desktop elements are redrawn. 
The patch seems to fix that too.

Please, don't delay fixing this issue.
I have to report it to my distribution, too.

Comment 1 Michel Dänzer 2018-07-20 07:16:45 UTC

(In reply to iive from comment #0)
> Something more, it also seems to solve another cosmetics issue that appeared
> after upgrading to xorg 1.20.0 server. Sometimes doing xrandr mode
> switching, the desktop would go black or the image would get corrupted,
> until each desktop elements are redrawn. 

That was probably bug 105381, fixed by the commit you bisected to.

The regression caused by that is already fixed in Git master:

commit 499d2f9d5d301ef1efd4ffc2952677609ef05122
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Tue Jul 17 11:43:12 2018 +0200

    glamor: Invalidate cached GEM handle in radeon_set_pixmap_bo

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.