You can try the livecd at https://nouveau.pmoreau.org/ which should have a more up-to-date stack.

Created attachment 123468 [details]
Qubes OS 3.1 dmesg output

Attached "Qubes OS 3.1 dmesg output" for the K1200 case.
OSes tried:
* Qubes OS R3.1 (kernel 4.1.13)
* Fedora Core 23 Live
* OpenSuSe Leap 42.1

Looks like some sort of issue training the DP link. Can you try a more recent kernel? A bunch of DP things have been fixed since kernel 4.1.

@Ilia,

Done. Slapped on Fedora Core 23 (the installer runs 4.2.x kernel, which seems to have the same issue as its 4.1.x cousins), but upon an update run, kernel 4.4.8-300 was installed, and things work. 

Attached the dmesg output from the 4.4.8-300, for reference. 

The overall goal is to run Qubes OS, so not sure if a later kernel is possible. Not sure if there's a way to backport 4.4.8's nouveau/drm into a 4.1.3 (probably not, but hey, I can haz hopes?)

Cheers.

Created attachment 123485 [details]
Fedora Core 23, kernel 4.4.8-300 output.

In kernel 4.1.x's output, there are "link training failed" messages, but in 4.4.x's, there are EDID checksum error messages instead. Wonder if 4.4.x's version simply handles ASUS' EDID brainfart better than 4.1.x?

(In reply to Regular Guy from comment #5)
> The overall goal is to run Qubes OS, so not sure if a later kernel is
> possible. Not sure if there's a way to backport 4.4.8's nouveau/drm into a
> 4.1.3 (probably not, but hey, I can haz hopes?)

Not sure what backport means... like grabbing the 4.4.8 kernel and editing Makefile to say that the version is 4.1.3? Anyways, this sort of thing isn't something we tend to worry about -- enough troubles as it is.

Link training and EDID fetch are moderately separate items. I think a number of changes went into the DP logic to harden it against various things that monitors do.

Since this is fixed in recent kernels, I'm going to close this.