<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Changing resolution with xrandr causes display to turn off."
href="https://bugs.freedesktop.org/show_bug.cgi?id=107297">107297</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Changing resolution with xrandr causes display to turn off.
</td>
</tr>
<tr>
<th>Product</th>
<td>xorg
</td>
</tr>
<tr>
<th>Version</th>
<td>git
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86-64 (AMD64)
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Keywords</th>
<td>bisected, patch, regression
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>Driver/Radeon
</td>
</tr>
<tr>
<th>Assignee</th>
<td>xorg-driver-ati@lists.x.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>iive@yahoo.com
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>xorg-team@lists.x.org
</td>
</tr></table>
<p>
<div>
<pre>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 <<a href="mailto:michel.daenzer@amd.com">michel.daenzer@amd.com</a>>
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:
<a href="https://patchwork.freedesktop.org/patch/239365/">https://patchwork.freedesktop.org/patch/239365/</a>
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>