You are not logged in.

#1 2019-11-14 16:38:07

tsjost
Member
Registered: 2019-11-14
Posts: 2

[SOLVED] DisplayPort Daisy Chaining broken in nvidia 440.31

I've been daisy chaining 3 Dell U2715H on an RTX 2080 for a while which has been working fine, except having to xset dpms force off ; xset dpms force on at boot to wake all-but-the-first monitor up.

An hour ago I performed a sysupgrade that bumped nvidia from 435.21-13 to 440.31-2, and now the other monitors no longer wake up with the above command. All monitors show up as connected in both xrandr and nvidia-settings -- the only difference is they don't wake up after xset dpms force off.

I downgraded back to 435.21-13 and linux to 5.3.7.arch1-1, and the monitors are back to working.

Since I'm used to things just working, I'm not sure how to debug this further. If this is indeed a regression in the graphics driver, how do I rigorously prove it's an upstream issue in order to file a bug report with nvidia?

In the meantime, I hope there's a way to figure out a workaround so I don't need to keep the kernel et al. on old versions?

Last edited by tsjost (2019-11-17 09:04:16)

Offline

#2 2019-11-15 08:48:53

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 7,949

Re: [SOLVED] DisplayPort Daisy Chaining broken in nvidia 440.31

One change in that driver is that it enabled HardDPMS by default, you might want to try a xorg config to set that to false instead again: http://us.download.nvidia.com/XFree86/L … l#HardDPMS

Offline

#3 2019-11-17 09:03:13

tsjost
Member
Registered: 2019-11-14
Posts: 2

Re: [SOLVED] DisplayPort Daisy Chaining broken in nvidia 440.31

You nailed it! Setting it to false made everything go back to "normal", thank you!

"DPMS was originally designed for CRT monitors, and includes intermediate states that are redundant for LCDs" – if this is indeed a legacy thing, it's strange that daisy chaining still requires a "force off" command.

Offline

Board footer

Powered by FluxBB