Hello, since the new amd "crimson" driver removed support for older cards and I read that the opensource "radeon" driver is now in a pretty usable state, I decided to try it out a few days ago. I run slackware64-current, and used the included xorg 1.18.0 and mesa 11.0.6. I compiled a fresh kernel from kernel.org - 4.4-rc4 Everything went pretty well, until I noticed that my WQHD Display ( 2560 x 1440 ) connected via Displayport was stuck at 27 Hz instead the usual 60 Hz. ( I also have a second screen 1920 x 1980 connected via DVI which was working correctly at 60Hz ) I tried a few things with xrandr to force it to 60 Hz, but nothing helped. Also xrandr -q displayed it is using 60 Hz, but Monitor Info displayed 27 Hz. Not sure if this is a bug, or 60 Hz via displayport at higher resolutions requires some proprietary magic which is only present in fglrx driver? Anyway I am back on fglrx driver now and have 60 Hz again, so I can't provide any follow up data. But I thought it would still be a good idea to report it in case this is a bug. Kind regards, Michael Stenzel
If you could attach an Xorg.0.log and a dmesg someone could perhaps see what's going on.
Created attachment 120477 [details] dmesg output
Created attachment 120478 [details] Xorg.0.log
Created attachment 120479 [details] output of xrandr -q
Sorry that I did not provide any logs with the report, I was already running fglrx again and did not save them... But I just switched to radeon again to get some logs now :) I also attached the output from xrandr -q because it thinks it runs with 59.95 Hz but the Monitor itself reports 27 Hz glxgears is also capped at 27 FPS. Kind regards, Michael Stenzel
One thing you could try is booting with the kernel command line parameter radeon.audio=0 and see if that helps. I also have some DisplayPort panel from Dell with 2560x1440 native resolution which runs at 67 Hz refresh rate when the kernel/X-Server/RandR think it is running at 60 Hz. Setting other than the native resolution will produce too high or too low refresh rates and/or corrupted display. Disabling audio over Displayport fixed the problem for me. The bug there seems to be some misprogramming of clocks or low level mode timings when audio over Displayport is enabled. This was introduced around Linux 4.0 with DP audio enablement iirc and might still be an issue in the current 4.4-rc kernel. I told Alex and Michel about it around that time and they knew that there might be still work to do to fixup some clock calculations for DP audio. -mario
Hello, I just tested it again with radeon.audio=0 and it works now. Display runs correctly at 2560x1440 with 60 Hz. Thanks! Kind regards, Michael Stenzel
Hello, I would like to also confirm this bug, with some extra information. The problem was resolved (for me) by booting with the kernel command line parameter radeon.audio=0. I have a muti-boot system: a) booting: Win10/ Ubuntu14.04-LTS/ Ubuntu16.04-LTS. b) Cypress PRO [Radeon HD 5850] in crossfire, both are identical XFX cards. c) DELL U2515H (Native 2560x144) connect via DisplayPort The problem only manifests under Ubuntu16.04-LTS, other OS boots work correctly. Ubuntu 14.04 info: Kernel: 3.13.0-86-generic Radeon Driver: [drm] Initialized radeon 2.36.0 20080528 Ubuntu 16.04 info: Kernel: 4.4.0-34-generic Radeon Driver: [drm] Initialized radeon 2.43.0 20080528 Kind Regards Pierre
Hi, In addition to my comment (Comment 8), although the display works at 60Hz, attempting to perform any audio configuration on the OS (change audio output device or microphone source etc.) immediately kills the display output. Thus the work around is great to get the WQHD Displayport from 27 Hz to 60 Hz, the system is a bit hamstrung in that any audio control access now kills the display.. Kind Regards Piere
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/146.
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.