I just tried with current drm-intel (head d2a1764437d8b4c30948704ff6c64e4bbfd1df7c) and the issue is still there.

Can you please try to bisect where this regression has been introduced. dmesg has unfortunately no hints as to what's going wrong.

This is still happening for me. Now on T450. Same symptoms.

kernel 4.0.4-303.fc22.x86_64

As Daniel requested on comment 2, could you please bisect?

I'm trying to bisect. The regression appeared in between 3.16 and 3.17. Turned out it is a bit tricky to compile kernel this old on fedora 22 :) Stay tuned, it might take a week or so.

Please try kernel v4.4.

(In reply to Jani Nikula from comment #7)
> Please try kernel v4.4.

Timeout, presumed fixed, closing. Please reopen if the problem persists with latest kernels.

This issue is still present on 4.8.4-200.fc24.x86_64
Now I'm running it on T460

Hi Jiri,
What is the status of this issue? Do you still see it on the latest kernel?
Could you try it with 4.10-rc5?

Regards
Manasi

The issue is still present with 4.9.5-100.fc24.x86_64

Hi Jiri,

Do you have a single monitor connected? If so could you test this with a direct DP cable going between laptop and monitor without MST hub. Please make sure you also turn off DP MST on the monitor. Let's see what happens in the SST configuration first and take it from there.
Please do this test and let me know what you see and attach the dmesg logs if you still see the issue.

Regards
Manasi

(In reply to Manasi from comment #12)
> Hi Jiri,
> 
> Do you have a single monitor connected? If so could you test this with a

Yes, a single monitor. As I described in the original bug description of this BZ.

> direct DP cable going between laptop and monitor without MST hub. Please
> make sure you also turn off DP MST on the monitor. Let's see what happens in
> the SST configuration first and take it from there.

I don't know what MST hub is. But the issue happens if I connect laptop directly to display. The issue is present with both HP ZR2440w and HP Z27i displays.

> Please do this test and let me know what you see and attach the dmesg logs
> if you still see the issue.

There's a debug dmesg output already attached to this BZ. Isn't that enough?

This is trivial to reproduce. Am I the only one experiencing this issue? This is clearly a regression between 3.16 and 3.17. Having this issue on multiple laptops, multiple displays, multiple kernels.

(In reply to Jiri Pirko from comment #13)
> There's a debug dmesg output already attached to this BZ. Isn't that enough?

Please run a recent (v4.10-rcN or drm-tip) kernel and attach dmesg all the way from boot to reproducing the issue, with drm.debug=14 module parameter set.

> This is trivial to reproduce. Am I the only one experiencing this issue?
> This is clearly a regression between 3.16 and 3.17. Having this issue on
> multiple laptops, multiple displays, multiple kernels.

Bisect early on would have been great, perhaps it would still help, but I doubt we can revert anything such old stuff.

Created attachment 129358 [details]
dmesg output with drm.debug=14, take 2

(In reply to Jani Nikula from comment #14)
> (In reply to Jiri Pirko from comment #13)
> > There's a debug dmesg output already attached to this BZ. Isn't that enough?
> 
> Please run a recent (v4.10-rcN or drm-tip) kernel and attach dmesg all the
> way from boot to reproducing the issue, with drm.debug=14 module parameter
> set.
> 

Attachment created. I ran 4.10-rc6


> > This is trivial to reproduce. Am I the only one experiencing this issue?
> > This is clearly a regression between 3.16 and 3.17. Having this issue on
> > multiple laptops, multiple displays, multiple kernels.
> 
> Bisect early on would have been great, perhaps it would still help, but I
> doubt we can revert anything such old stuff.

Next weekend maybe, if I'll find the time. But you can the the bisection yourself...

Thanks for testing with 410-rc6.
I tried to reproduce it here at my end with 4.10-rc6 and I can't. But again in my case, the dmesg log says "Sink is not MST capable". But in your case, whats confusing is:

[    2.492671] [drm:intel_dp_read_desc [i915]] DP branch: OUI 90-cc-24 dev-ID SYNA HW-rev 1.0 SW-rev 2.17
[    2.493030] [drm:intel_dp_detect [i915]] Sink is MST capable


This means somehow there is a branch device in the patch of laptop's DP and DP on the monitor. Are you using any kind of an adapter? Does your laptop have multiple DP connectors?

Could you also run this command and tell me what the output is with the monitor on and then after you see the problem:

sudo su
cat /sys/kernel/debug/dri/0/i915_display_info

Regards
Manasi

(In reply to Manasi from comment #17)
> Thanks for testing with 410-rc6.
> I tried to reproduce it here at my end with 4.10-rc6 and I can't. But again
> in my case, the dmesg log says "Sink is not MST capable". But in your case,
> whats confusing is:
> 
> [    2.492671] [drm:intel_dp_read_desc [i915]] DP branch: OUI 90-cc-24
> dev-ID SYNA HW-rev 1.0 SW-rev 2.17
> [    2.493030] [drm:intel_dp_detect [i915]] Sink is MST capable
> 
> 
> This means somehow there is a branch device in the patch of laptop's DP and
> DP on the monitor. Are you using any kind of an adapter? Does your laptop
> have multiple DP connectors?

There is a docking station in between. I just ordered microdisplayport-display port cable to be able to test this directly.


> 
> Could you also run this command and tell me what the output is with the
> monitor on and then after you see the problem:
> 
> sudo su
> cat /sys/kernel/debug/dri/0/i915_display_info

Will provide this at weekend. (I don't have the testing laptop with me now)


> 
> Regards
> Manasi

(In reply to Jiri Pirko from comment #18)
> (In reply to Manasi from comment #17)
> > Thanks for testing with 410-rc6.
> > I tried to reproduce it here at my end with 4.10-rc6 and I can't. But again
> > in my case, the dmesg log says "Sink is not MST capable". But in your case,
> > whats confusing is:
> > 
> > [    2.492671] [drm:intel_dp_read_desc [i915]] DP branch: OUI 90-cc-24
> > dev-ID SYNA HW-rev 1.0 SW-rev 2.17
> > [    2.493030] [drm:intel_dp_detect [i915]] Sink is MST capable
> > 
> > 
> > This means somehow there is a branch device in the patch of laptop's DP and
> > DP on the monitor. Are you using any kind of an adapter? Does your laptop
> > have multiple DP connectors?
> 
> There is a docking station in between. I just ordered
> microdisplayport-display port cable to be able to test this directly.
> 

Okay, I tested with directly connected display. Works fine. So this is only issue when display is connected through docking station.

Created attachment 129507 [details]
i915_display_info 1st port - before

4.10-rc6

Created attachment 129508 [details]
i915_display_info 1st port - after

4.10-rc6

Created attachment 129509 [details]
i915_display_info 2nd port - before

4.10-rc6

Created attachment 129510 [details]
i915_display_info 2nd port - after

4.10-rc6

So according to the attached i915_display_info, it looks like when connected through docking station, after display off/on there is a new port (DP-X) created. Should be rather the original (DP-Y). Odd.

I was unable to do bisection. Unable to compile 3.16 kernel on my system. I even tried older gcc, no luck :/

Uff, just finished the bisection.

So the breaking commit is:
commit 0e32b39ceed665bfa4a77a4bc307b6652b991632
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri May 2 14:02:48 2014 +1000

    drm/i915: add DP 1.2 MST support (v0.7)

Note that this is not an issue using Gnome. It apparently has some smart daemon listening on events and reshuffling displays back again ofter off/on. You have to use some stupid window manager like xmonad in order to reproduce this.

(In reply to Jiri Pirko from comment #26)
> Note that this is not an issue using Gnome. It apparently has some smart
> daemon listening on events and reshuffling displays back again ofter off/on.
> You have to use some stupid window manager like xmonad in order to reproduce
> this.

It is actually userspace policy to enable connected displays, not a kernel decision. I'm not even sure why it would work with the directly connected case.

(In reply to Jani Nikula from comment #27)
> (In reply to Jiri Pirko from comment #26)
> > Note that this is not an issue using Gnome. It apparently has some smart
> > daemon listening on events and reshuffling displays back again ofter off/on.
> > You have to use some stupid window manager like xmonad in order to reproduce
> > this.
> 
> It is actually userspace policy to enable connected displays, not a kernel
> decision. I'm not even sure why it would work with the directly connected
> case.

It would work correctly if the kernel would expose display under same DP number (same connector). But after boot it is DP-X and later on after every off/on it is on DP-Y. That I believe is a bug, don't you think?

Maybe. The connectors for DP MST come and go dynamically, so I don't think stable connector numbers are guaranteed.

(In reply to Jani Nikula from comment #29)
> Maybe. The connectors for DP MST come and go dynamically, so I don't think
> stable connector numbers are guaranteed.

Yeah, but one would expect that the same physical connector should present himself under same ip/name every time, right?

Perhaps it is a HW issue. I tried to looks this up in the intel mst/drm mst code yesterday, but as I'm completely unfamiliar with the code it takes me ages to figure out what's what (although the code is written nicely). I will continue to dig it next weekend.

It looks to me that in the DP MST case, the userspace driver is not handling the short pulses for MST sideband communication properly.
So the connector (now different id) does not get detected as Connected and modeset doesn't happen on this.
Now, that we know it only happens in the docking station case and works fine on a single DP connection (DP SST), Could you capture a log with DP connected through the docking station on the latest kernel?

Regards
Manasi

jiri@resnulli.us - can you please help Manasi? See comment 31.

(In reply to Jari Tahvanainen from comment #32)
> jiri@resnulli.us - can you please help Manasi? See comment 31.

I won't have time this week, traveling the next week. Will do the test and provide data here during the week starting 2017-04-10. Thanks.

Hi Jiri,

Did you get a chance to retest this issue on the latest kernel from drm-tip?
Please provide a full dmesg log with drm.debug=0xe for all 3 cases:

1. DP display connected
2. Turn off monitor
3. Turn on the monitor

What platform are you running it on again? T440 is BDW?

Manasi

Manasi please make sure you also change the assignee to the person who you are waiting information. the submitter in this case...

Jiri Please provide information requested by Manasi, if the issue is now gone with the latest configuration please let us know so we can close the bug.

Created attachment 131327 [details]
boot

Created attachment 131328 [details]
after off

Created attachment 131329 [details]
after on

the requested dmesg outputs attached. drm-tip head 417babaa12ad98dad2c39f361612f1afe6894816

I see that the display is getting detected in the last log, but there is no modeset from the userspace. Can you post the output of
`xev -event randr` or (`xev -display :0 -event randr` if you are using ssh) while turning the display on again? 
This will help us confirm how the user space driver is handling the hotplug event from the kernel (assuming the kernel sends it).

Also, what happens if you set the mode manually with xrandr after turning the display on ?

Can you also post xorg.0.log?

Since you say, "Note that this is not an issue using Gnome. It apparently has some smart daemon listening on events and reshuffling displays back again ofter off/on. You have to use some stupid window manager like xmonad in order to reproduce this.", can you please provide more information about the userspace. 

1) Xorg.0.log should tell whether you have xf86-video-intel or -modesetting.
2) xev -event randr should tell us whether randr events are being sent to DE.

I noticed an interesting debug message

[   59.999079] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00400000, dig 0x10101210, pins 0x00000040
[   59.999116] [drm:intel_hpd_irq_handler [i915]] digital hpd port C - long
[   59.999151] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 6 - cnt: 0
[   59.999217] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port C - long
[   59.999258] [drm:i915_hotplug_work_func [i915]] running encoder hotplug functions
[   59.999297] [drm:i915_hotplug_work_func [i915]] Connector DP-2 (pin 6) received hotplug event.
[   59.999332] [drm:intel_dp_detect [i915]] [CONNECTOR:63:DP-2]
[   59.999368] [drm:intel_dp_detect [i915]] MST device may have disappeared 1 vs 1

When I turn off the DP monitor connected to a Startech MST hub device, I see a "short" pulse. But, the Lenovo dock here is sending a "long" pulse.

I tried the same experiment with a  Lenovo x260 + Lenovo dock. There was no interrupt (short or long pulse) when I turned off the monitor connected to the dock. The display comes up fine after I turn it on.

But, with Jiri's configuration, the dock seems to send a long pulse indicating a dock unplug. Therefore, the connectors get destroyed. I don't think the kernel is doing anything wrong here. We'll need more debug information to confirm that the userspace isn't able to deal with new connectors.

While there are DP-MST issues that need to be resolved. Some of the earlier comments here indicate problems with port labels too. Can you please try this patch? - 
https://patchwork.freedesktop.org/patch/162609/
This patch fixes a regression that caused DP-port label renaming.

(In reply to Dhinakaran Pandiyan from comment #45)
> While there are DP-MST issues that need to be resolved. Some of the earlier
> comments here indicate problems with port labels too. Can you please try
> this patch? - 
> https://patchwork.freedesktop.org/patch/162609/
> This patch fixes a regression that caused DP-port label renaming.

I tried current drm-tip tree which includes this patch. HEAD is:
417babaa12ad98dad2c39f361612f1afe6894816

However, still does not work. also, for some reason that might be related so some other thing, the display won't work even using Gnome. Odd. I'm going to attach dmesgs in a jiff.

(In reply to Jiri Pirko from comment #46)
> (In reply to Dhinakaran Pandiyan from comment #45)
> > While there are DP-MST issues that need to be resolved. Some of the earlier
> > comments here indicate problems with port labels too. Can you please try
> > this patch? - 
> > https://patchwork.freedesktop.org/patch/162609/
> > This patch fixes a regression that caused DP-port label renaming.
> 
> I tried current drm-tip tree which includes this patch. HEAD is:
> 417babaa12ad98dad2c39f361612f1afe6894816

Sorry, the head is different, from today (by mistake I took this from older notes).

> 
> However, still does not work. also, for some reason that might be related so
> some other thing, the display won't work even using Gnome. Odd. I'm going to
> attach dmesgs in a jiff.

Will attach dmesgs on Friday, as I left them on testing a laptop 200km far away :)

Created attachment 132403 [details]
dmesg.boot

dmesg after boot with drm-tip_head 1789a777702e41b11133dd23578edbd0b47ccf40

Created attachment 132404 [details]
dmesg.after_off

dmesg after display off with drm-tip_head 1789a777702e41b11133dd23578edbd0b47ccf40

Created attachment 132405 [details]
dmesg.after_on

dmesg after display on again with drm-tip_head 1789a777702e41b11133dd23578edbd0b47ccf40

Created attachment 132406 [details]
i915_display_info.boot

i915_display_info after boot with drm-tip_head 1789a777702e41b11133dd23578edbd0b47ccf40

Created attachment 132407 [details]
i915_display_info.after_off

i915_display_info after display off with drm-tip_head 1789a777702e41b11133dd23578edbd0b47ccf40

Created attachment 132408 [details]
i915_display_info.after_on

i915_display_info after display on again with drm-tip_head 1789a777702e41b11133dd23578edbd0b47ccf40

Thanks for the logs. Can you please try the patch that the bug reporter has attached in https://bugs.freedesktop.org/show_bug.cgi?id=101461 ? Updating the connector status should help the user space detect the unplug.

Created attachment 133187 [details] [review]
Update connector status and keep aux powered up.

Can(In reply to Dhinakaran Pandiyan from comment #55)
> Created attachment 133187 [details] [review] [review]
> Update connector status and keep aux powered up.

Can you please test if this works?

Jiri - can you please help us out and check if the fix referenced on comment 55 works?

https://patchwork.freedesktop.org/patch/176708/ should fix the monitor switching issue, waiting for the patch to merge.

A patch refenrencing this bug was committed as

commit 5ea2355a100a3c6304901d058aee06d3a6be69bc
Author: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Date:   Tue Oct 3 17:22:11 2017 +0300

    drm/i915/mst: Use MST sideband message transactions for dpms control

Does this fix the issue?

Jiri, can you comment if patch merged will solve your issue?

(In reply to Jani Saarinen from comment #60)
> Jiri, can you comment if patch merged will solve your issue?

Will test during following weekend. Added note to my calendar. Thanks.

OK, thanks. If no response on monday we will close.

Hi,
Lets close now as fixed and JIRI as reporter to re-open if still issue.

(In reply to Jiri Pirko from comment #61)
> (In reply to Jani Saarinen from comment #60)
> > Jiri, can you comment if patch merged will solve your issue?
> 
> Will test during following weekend. Added note to my calendar. Thanks.

I tried to compile the kernel over the weekend on the laptop I see the issues on, however I found out it is apparently broken as it repeatedly froze during compilation :/ Lets assume this is fixed. I will reopen if I cross this one again. Thanks.

I'm now running kernel 4.15.7-300.fc27.x86_64 which includes the mentioned fix (" drm/i915/mst: Use MST sideband message transactions for dpms control"). The issue is still there. Nothing changed for me.

Hi, could you share dmesg with the latest kernel with the fix? Thank you.

First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.

(In reply to Jiri Pirko from comment #65)
> I'm now running kernel 4.15.7-300.fc27.x86_64 which includes the mentioned
> fix (" drm/i915/mst: Use MST sideband message transactions for dpms
> control"). The issue is still there. Nothing changed for me.

More fixes in drm-tip. Please retest.

ad260ab32a4d ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
be1c63c8017b ("drm/i915/dp: Send DPCD ON for MST before phy_up")

Ping for retesting drm-tip.

(In reply to Jani Nikula from comment #69)
> Ping for retesting drm-tip.

No updates in more than a week, dropping to high.

Closing, please re-open if still occurs.

I'm testing with drm-intel git HEAD c4c252590951704947d216a2565ee9dec21f704d
Nothing changed at all. The issue is still there.
I'm a bit tired about trying random patches. Could someone please reproduce this locally and fix it? It is quite easy to reproduce. In short, you power off and power off the external display, and you can see that with every on, there is another connector added. Will attach output of i915_display_info, but basically if looks like this:

->boot
connector 92: type DP-4, status: connected
->off,on,manual xrandr
connector 93: type DP-5, status: connected
->off,on,manual xrandr
connector 100: type DP-6, status: connected
->off,on,manual xrandr
connector 96: type DP-5, status: connected
->off,on,manual xrandr
connector 100: type DP-6, status: connected
....

Looks random to me. I would expect the connector number to stay the same every time. This is the core of the bug. I reported this in January 2015, spent non-trivial amount of time on this and getting a bit frustrated. Please fix.

Created attachment 138967 [details]
dmesg.boot

Created attachment 138968 [details]
dmesg.after_off

Created attachment 138969 [details]
dmesg.after_on

Created attachment 138970 [details]
dmesg.after_manual_xrandr

Created attachment 138971 [details]
display_info.boot

Created attachment 138972 [details]
display_info.after_off

Created attachment 138973 [details]
display_info.after_on

Created attachment 138974 [details]
display_info.after_manual_xrandr

Jiri,

Sorry about the bug getting closed, I haven't worked on this for a while. There were no patches merged to address the connector ID change, so the retest on drm-tip wasn't necessary IMO. However, there was another related issue (monitor on-off) with the same configuration that got fixed. This was the reason for @c58 and it seems like the thread got sidetracked since that point.

A quick note about the connector IDs. The connectors for displays attached to the docking station are created and destroyed dynamically during during hotplug/monitor off-on. This is why the ID's change and the flip-flopping of connector ID's is probably due to the order in which connectors are destroyed and created again. User space is typically able to handle this. Connector ID's are stable only for ports directly connected to the GPU. For e.g., connector 82: type DP-2 for the docking station is what is going to stay the same.

As long as the kernel updates the connection status correctly and sends hotplug events, user space is expected to deal with change in connector IDs. I am not familiar with xmonad, so I don't know what's going on there. Let me see if I can find out more.

(In reply to Dhinakaran Pandiyan from comment #81)
> Jiri,
> 
> Sorry about the bug getting closed, I haven't worked on this for a while.
> There were no patches merged to address the connector ID change, so the
> retest on drm-tip wasn't necessary IMO. However, there was another related
> issue (monitor on-off) with the same configuration that got fixed. This was
> the reason for @c58 and it seems like the thread got sidetracked since that
> point.
> 
> A quick note about the connector IDs. The connectors for displays attached
> to the docking station are created and destroyed dynamically during during
> hotplug/monitor off-on. This is why the ID's change and the flip-flopping of
> connector ID's is probably due to the order in which connectors are
> destroyed and created again. User space is typically able to handle this.
> Connector ID's are stable only for ports directly connected to the GPU. For
> e.g., connector 82: type DP-2 for the docking station is what is going to
> stay the same.
> 
> As long as the kernel updates the connection status correctly and sends
> hotplug events, user space is expected to deal with change in connector IDs.
> I am not familiar with xmonad, so I don't know what's going on there. Let me
> see if I can find out more.

The thing is, there has to be some userspace daemon monitoring the events and pushing the setting down accordingly. I have no such daemon.
Previously, before patch 0e32b39ceed665bfa4a77a4bc307b6652b991632, the ids were stable so all worked fine even without need to any additional userspace daemon.
Could you make the connector IDs stable again?

(In reply to Jiri Pirko from comment #82)
> (In reply to Dhinakaran Pandiyan from comment #81)
> > Jiri,
> > 
> > Sorry about the bug getting closed, I haven't worked on this for a while.
> > There were no patches merged to address the connector ID change, so the
> > retest on drm-tip wasn't necessary IMO. However, there was another related
> > issue (monitor on-off) with the same configuration that got fixed. This was
> > the reason for @c58 and it seems like the thread got sidetracked since that
> > point.
> > 
> > A quick note about the connector IDs. The connectors for displays attached
> > to the docking station are created and destroyed dynamically during during
> > hotplug/monitor off-on. This is why the ID's change and the flip-flopping of
> > connector ID's is probably due to the order in which connectors are
> > destroyed and created again. User space is typically able to handle this.
> > Connector ID's are stable only for ports directly connected to the GPU. For
> > e.g., connector 82: type DP-2 for the docking station is what is going to
> > stay the same.
> > 
> > As long as the kernel updates the connection status correctly and sends
> > hotplug events, user space is expected to deal with change in connector IDs.
> > I am not familiar with xmonad, so I don't know what's going on there. Let me
> > see if I can find out more.
> 
> The thing is, there has to be some userspace daemon monitoring the events
> and pushing the setting down accordingly. I have no such daemon.
> Previously, before patch 0e32b39ceed665bfa4a77a4bc307b6652b991632, the ids
> were stable so all worked fine even without need to any additional userspace
> daemon.
> Could you make the connector IDs stable again?

They were never actually stable. You just got lucky earlier.

(In reply to Ville Syrjala from comment #83)
> (In reply to Jiri Pirko from comment #82)
> > (In reply to Dhinakaran Pandiyan from comment #81)
> > > Jiri,
> > > 
> > > Sorry about the bug getting closed, I haven't worked on this for a while.
> > > There were no patches merged to address the connector ID change, so the
> > > retest on drm-tip wasn't necessary IMO. However, there was another related
> > > issue (monitor on-off) with the same configuration that got fixed. This was
> > > the reason for @c58 and it seems like the thread got sidetracked since that
> > > point.
> > > 
> > > A quick note about the connector IDs. The connectors for displays attached
> > > to the docking station are created and destroyed dynamically during during
> > > hotplug/monitor off-on. This is why the ID's change and the flip-flopping of
> > > connector ID's is probably due to the order in which connectors are
> > > destroyed and created again. User space is typically able to handle this.
> > > Connector ID's are stable only for ports directly connected to the GPU. For
> > > e.g., connector 82: type DP-2 for the docking station is what is going to
> > > stay the same.
> > > 
> > > As long as the kernel updates the connection status correctly and sends
> > > hotplug events, user space is expected to deal with change in connector IDs.
> > > I am not familiar with xmonad, so I don't know what's going on there. Let me
> > > see if I can find out more.
> > 
> > The thing is, there has to be some userspace daemon monitoring the events
> > and pushing the setting down accordingly. I have no such daemon.
> > Previously, before patch 0e32b39ceed665bfa4a77a4bc307b6652b991632, the ids
> > were stable so all worked fine even without need to any additional userspace
> > daemon.
> > Could you make the connector IDs stable again?
> 
> They were never actually stable. You just got lucky earlier.

Well, they were for many years. That is much longer than "never".

Jiri - what version of xmonad are you using?

Also, does the issue currently reproduce on Gnome, or just on xmonad?

(In reply to James Ausmus from comment #85)
> Jiri - what version of xmonad are you using?

xmonad-0.13-5.fc28.x86_64


> 
> Also, does the issue currently reproduce on Gnome, or just on xmonad?

No, as I mentioned before, Gnome apparently has some daemon that takes care of the changing connector IDs.

Lowering the priority as it sounds more like an enhancement than a bug.

(In reply to Lakshmi from comment #87)
> Lowering the priority as it sounds more like an enhancement than a bug.

This is a proper regression!

As explained, DP MST is a hotplugging bus. If you're desktop manager doesn't handle hotplugs (like gnome and pretty much all the others do), then pls don't hotplug monitors. Or write a script which listens to these hotplug events, checks the edid ID or dp mst path property and sets up the right config again.

Closing as wontfix, please don't reopen. There's no point in reopening, all you achieve is piss of developers.

Thanks, Daniel