Bug 1375171 - xfsettingsd loses settings for DisplayPort displays when they are powered off
Summary: xfsettingsd loses settings for DisplayPort displays when they are powered off
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: xfce4-settings
Version: 24
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-12 11:38 UTC by David M. Lloyd
Modified: 2017-08-08 17:18 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2017-08-08 17:18:38 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Xfce 11107 None None None 2016-09-12 11:38 UTC

Description David M. Lloyd 2016-09-12 11:38:13 UTC
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:

Comment 1 Kevin Fenzi 2016-09-12 15:44:08 UTC
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.

Comment 2 David M. Lloyd 2016-09-12 18:44:24 UTC
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.

Comment 3 David M. Lloyd 2016-09-13 15:36:50 UTC
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.

Comment 4 Kevin Fenzi 2016-09-14 16:39:37 UTC
bug 1285521 might be related here... I can try a scratch build with that patch for people to test soon.

Comment 5 Kevin Fenzi 2016-09-15 15:51:53 UTC
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.

Comment 6 David M. Lloyd 2016-09-15 16:20:20 UTC
I don't really know how to do that!

Comment 7 David M. Lloyd 2016-09-15 16:21:06 UTC
I'd be happy to try though if there are instructions somewhere.

Comment 8 Kevin Fenzi 2016-09-15 19:17:56 UTC
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.

Comment 9 David M. Lloyd 2016-09-15 19:35:42 UTC
Nice! Thanks, I'll try that ASAP.

Comment 10 David M. Lloyd 2016-09-16 17:16:22 UTC
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.

Comment 11 Kevin Fenzi 2016-09-25 00:16:04 UTC
I was afraid of that. Will see what upstream comes up with here...

Comment 12 Fedora End Of Life 2017-07-25 22:59:40 UTC
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.

Comment 13 Fedora End Of Life 2017-08-08 17:18:38 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.