[Bug 107297] New: Changing resolution with xrandr causes display to turn off.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107297

            Bug ID: 107297
           Summary: Changing resolution with xrandr causes display to turn
                    off.
           Product: xorg
           Version: git
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Keywords: bisected, patch, regression
          Severity: normal
          Priority: medium
         Component: Driver/Radeon
          Assignee: xorg-driver-ati at lists.x.org
          Reporter: iive at yahoo.com
        QA Contact: xorg-team at lists.x.org

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 at 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-driver-ati/attachments/20180719/2e923e16/attachment.html>