After turning the monitor on again, there is no signal on the DP output. HDMI still works fine. I first found the issue in 3.18 and it's still present in 4.0.7. Doing 'xrandr --output DP2 --off; xrandr --output DP2 --auto' makes it work again, but it has to be done from X, with the monitor switched to DP. My HW is 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
(In reply to Anton Khirnov from comment #0) > Doing 'xrandr --output DP2 --off; xrandr --output DP2 --auto' makes it work > again, but it has to be done from X, with the monitor switched to DP. "has to be done from X"... do you have some userspace running responding to hotplug signals from the driver?
(In reply to Jani Nikula from comment #1) > (In reply to Anton Khirnov from comment #0) > > Doing 'xrandr --output DP2 --off; xrandr --output DP2 --auto' makes it work > > again, but it has to be done from X, with the monitor switched to DP. > > "has to be done from X"... do you have some userspace running responding to > hotplug signals from the driver? Not that I know, unless it's Xorg itself. I don't have any fancy DE, just X with FVWM. What I meant by the sentence you quoted is that I usually switch to HDMI (which is working), enter "sleep 10; xrandr....", then switch to DP and wait for xrandr to run. Running xrandr while the monitor is switched to HDMI, or when i'm switched from X to a different VT, won't work.
Do I understand correctly that you have the machine hooked up to the same monitor using both DP and HDMI? The symptoms do sound like your userspace is not fancy enough to handle the hotplug uevents. What to do on hotplug (or hot-unplug, or switching the sink on/off) is a userspace policy decision. I'm guessing the driver keeps transmitting the signal even after you've switched off the display, your userspace does nothing, and when you switch the display back on, HDMI has a fighting chance to recover, however the DP link doesn't recover like that.
(In reply to Jani Nikula from comment #3) > Do I understand correctly that you have the machine hooked up to the same > monitor using both DP and HDMI? > Yes. I added the HDMI connection there just for re-enabling DP because of this problem, otherwise I don't use it since it doesn't support my monitor's full resolution. > The symptoms do sound like your userspace is not fancy enough to handle the > hotplug uevents. What to do on hotplug (or hot-unplug, or switching the sink > on/off) is a userspace policy decision. I'm guessing the driver keeps > transmitting the signal even after you've switched off the display, your > userspace does nothing, and when you switch the display back on, HDMI has a > fighting chance to recover, however the DP link doesn't recover like that. Well, before kernel 3.18 my setup worked just fine without any fancy userspace hotplug handlers.
(In reply to Anton Khirnov from comment #4) > (In reply to Jani Nikula from comment #3) > > Do I understand correctly that you have the machine hooked up to the same > > monitor using both DP and HDMI? > > > > Yes. I added the HDMI connection there just for re-enabling DP because of > this problem, otherwise I don't use it since it doesn't support my monitor's > full resolution. > > > The symptoms do sound like your userspace is not fancy enough to handle the > > hotplug uevents. What to do on hotplug (or hot-unplug, or switching the sink > > on/off) is a userspace policy decision. I'm guessing the driver keeps > > transmitting the signal even after you've switched off the display, your > > userspace does nothing, and when you switch the display back on, HDMI has a > > fighting chance to recover, however the DP link doesn't recover like that. > > Well, before kernel 3.18 my setup worked just fine without any fancy > userspace hotplug handlers. I wonder how that is possible for DP. The DP link goes down when you switch the display off. We never automatically trained the link on hotplugging.
Please test http://lists.freedesktop.org/archives/intel-gfx/2015-August/074150.html
I guess this is fixed or the reporter is gone...
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.