Description of problem: When a DisplayPort display is powered off, an xrandr event is received indicating that the display was disconnected (this may be worth its own bug report in fact!). When the display is powered back on, it is not recognized or configured by xfsettingsd; it just remains blank. Note that this event is not received if a DVI or HDMI display is powered off. Version-Release number of selected component (if applicable): 4.12.0 How reproducible: 100% Steps to Reproduce: 1. Connect a native DisplayPort display to a DisplayPort on the video interface. 2. Configure system normally. 3. Power cycle display and observe results. Actual results: Display is not configured. Expected results: Display configuration is restored. Additional info:
So we actually have a patch from that upstream bug applied... but I guess it doesn't fix things in your case. ;( I'll revisit the upstream bug and see if there's anything additional we can do here.
Ah, bummer. Still it makes me glad that I decided to open the issue. I should mention that there's a theoretical workaround - disabling the disconnect events within the Xorg config itself - but due to the relatively onerous nature of that workaround (i.e. amount of screwing around needed) I haven't tried it yet. It seems weird that DisplayPort behaves the way it does in this regard compared to HDMI though, and that it seems to be a driver-spanning sort of problem. It seems likely to me that the *real* issue is possibly in Xorg itself, that it doesn't seem to account for the possibility that a DP display is present but powered down. I don't know enough about the protocols involved to say for sure though. Anyway thanks for looking into it.
Here's what happens when I run xev and then turn off the DP display: RRNotify event, serial 37, synthetic NO, window 0x4a00001, subtype XRROutputPropertyChangeNotifyEvent output DP1, property EDID, timestamp 332349944, state Delete RRScreenChangeNotify event, serial 37, synthetic NO, window 0x4a00001, root 0xd7, timestamp 319493783, config_timestamp 332350217 size_index 65535, subpixel_order SubPixelUnknown rotation RR_Rotate_0 width 3840, height 1920, mwidth 1016, mheight 508 RRNotify event, serial 37, synthetic NO, window 0x4a00001, subtype XRROutputChangeNotifyEvent output DP1, crtc 63, mode 1920x1920 (1920x1920) rotation RR_Rotate_0 connection RR_Disconnected, subpixel_order SubPixelUnknown Compare to turning off the HDMI display, which generates zero events. So I guess the root problem is really in the X server itself. It's not reading DP events in a reasonable manner - or perhaps it really is impossible to distinguish between power-off and disconnect on a DP display, but somehow I doubt that.
bug 1285521 might be related here... I can try a scratch build with that patch for people to test soon.
Can you please try this scratch build and see if it helps: https://koji.fedoraproject.org/koji/taskinfo?taskID=15643779 (I'm assuming folks are using f24 here as that is what this bug was reported against). If f25 or rawhide this version was just submitted as an update.
I don't really know how to do that!
I'd be happy to try though if there are instructions somewhere.
it's pretty easy. ;) Go to https://koji.fedoraproject.org/koji/taskinfo?taskID=15643779 You will then want to click on the build for the architecture you have. Do a 'uname -p' in a terminal. It's likely x86_64. Click on the build for that arch: https://koji.fedoraproject.org/koji/taskinfo?taskID=15643782 then you want the actual package build, so click on: https://kojipkgs.fedoraproject.org//work/tasks/3782/15643782/xfce4-settings-4.12.1-1.fc24.x86_64.rpm your browser should download it. Possibly to a Downloads directory or the like. go to that directory in a terminal and do: sudo dnf update xfce4-settings-4.12.1-1.fc24.x86_64.rpm and it should ask your password and then ask if you want to update that package. Say yes and let it update. Then logout and back on, or reboot and test again to see if the bug is still there. ;) Hope that helps.
Nice! Thanks, I'll try that ASAP.
This does not appear to fix the issue unfortunately - or at least not wholly. Before the patch, I'd power off the DP display and power it back on and it would remain disabled and unconfigured. With the patch I see a new behavior: the display seems to be configured and enabled in the display settings app but it is still black. In addition it says "Mirrored" in the arrangement area but the "Mirror displays" checkbox is unchecked. I have to go through a series of disabling and reenabling things in order for the displays to be arranged correctly.
I was afraid of that. Will see what upstream comes up with here...
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.