Bug 46725 - Monitor "disconnected" and refuses to work anymore
Summary: Monitor "disconnected" and refuses to work anymore
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-28 05:41 UTC by Tomi Pieviläinen
Modified: 2019-11-19 08:25 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Xorg log with the disconnect event at the bottom (47.43 KB, patch)
2012-02-28 05:41 UTC, Tomi Pieviläinen
no flags Details | Splinter Review
dmesg (67.91 KB, text/x-log)
2012-02-28 07:57 UTC, Tomi Pieviläinen
no flags Details

Description Tomi Pieviläinen 2012-02-28 05:41:00 UTC
Created attachment 57766 [details] [review]
Xorg log with the disconnect event at the bottom

My monitor is SyncMaster 305Tplus connected to a DP-DLDVI adapter, which is hooked to the dp port of my llano mb. The monitor won't accept any other resolution than 2560x1600 and 1280x800, but EDID doesn't find those. To compensate, I'm using these lines in my .xinitrc:

xrandr --newmode 2560x1600 268.00  2560 2608 2640 2720  1600 1603 1609 1646 +hsync -vsync
xrandr --addmode DisplayPort-0  2560x1600
xrandr --newmode "1280x800"x59.9   71.00  1280 1328 1360 1440  800 803 809 823 +hsync -vsync
xrandr --addmode DisplayPort-0  "1280x800"x59.9 
xrandr --output DisplayPort-0  --mode 2560x1600
xrandr --output DVI-0 --rotate left --auto --right-of DisplayPort-0

Today after closing a window, the monitor suddenly went dark. Xorg log seems to show almost like it was rediscovered, or something, but trying to reset the mode doesn't work:

$ xrandr --newmode 2560x1600 268.00  2560 2608 2640 2720  1600 1603 1609 1646 +hsync -vsync
X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  150 (RANDR)
  Minor opcode of failed request:  16 (RRCreateMode)
  Serial number of failed request:  29
  Current serial number in output stream:  29

Same with trying to add the 1280 mode. So I can't turn the monitor on without rebooting. Not sure what happened there...
Comment 1 Tomi Pieviläinen 2012-02-28 05:46:34 UTC
Just wanted to clarify, that rebooting X was enough, didn't have to reboot the whole machine.
Comment 2 Alex Deucher 2012-02-28 07:43:40 UTC
Are you using an active or passive DP to DVI adapter?  Also please attach your dmesg output.
Comment 3 Tvrtko Ursulin 2012-02-28 07:56:40 UTC
Does you monitor claim it is in power save when it goes dark? If so maybe the root cause is similar to my https://bugs.freedesktop.org/show_bug.cgi?id=46711.
Comment 4 Tomi Pieviläinen 2012-02-28 07:57:12 UTC
Active, powered from USB.
Comment 5 Tomi Pieviläinen 2012-02-28 07:57:43 UTC
Created attachment 57771 [details]
dmesg
Comment 6 Tomi Pieviläinen 2012-02-28 07:59:47 UTC
Yes, it went to powersave. In the desktop manager, before login (and thus before setting the right modes in .xinitrc), it shows primary colors which is the monitor's way of saying that it doesn't understand the signal.
Comment 7 Tomi Pieviläinen 2012-03-12 03:15:07 UTC
This has happened several times more to me. It happens very often when watching a HD video, and some times when viewing photos. Hasn't happened in normal desktop use.

I've also noticed that I can get it back on by forcing it off with xrandr, and then back on.
Comment 8 Tomi Pieviläinen 2012-03-12 03:17:18 UTC
Seems like I can reproduce this every time I view a certain photo taken with my phone in feh...
Comment 9 Alex Deucher 2012-03-12 06:53:28 UTC
Does booting with radeon.disp_priority=2 on the kernel command line in grub help?
Comment 10 Tomi Pieviläinen 2012-03-13 02:00:11 UTC
Unfortunately not.
Comment 11 Martin Peres 2019-11-19 08:25:40 UTC
-- 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/drm/amd/issues/252.


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.