Starting with fedora 28 and going through fedora 30, the nouveau driver produces a bad signal when trying to display X on my LG OLEDB6P 4K television.
Weirdly, with what is presumably the same driver, it displays a full UHD resolution when running wayland rather than X. (I really don't understand why something as low level as the video timing would be different between wayland and X, but if someone does know, they probably know where the bug is too :-).
This isn't restricted to fedora either. I've just been testing a multi-boot USB stick, and the drivers on the ubuntu 19.04 live CD and the System Rescue CD 6.0.3 produce the same "bad signal" errors on this monitor.
For details (like X log files) see:
If I add nomodeset and forcevesa kernel parameters, I can boot and see (lower resolution) video rather than a black screen.
Switching to the nvidia binary drivers makes the display work properly again.
Booting the USB stick on different systems with more conventional resolution monitors, nouveau works fine.
FWIW I have a LG C7P which I tested with a GM206 and GP107. Slightly different than your setup, but comparable.
I used this setup for bringup of HDMI 2.0 support, available in kernel 4.20. HDMI 2.0 is required for 4k@60 over HDMI.
Looking at those logs, you appear to be using modeset instead of xf86-video-nouveau (note how it says "modeset" instead of "NOUVEAU"). The logs make it look like modeset is trying to use a 3840x2160 594MHz mode. This requires HDMI 2.0 to work (and should have been filtered out, but nonetheless is the modeline presented).
I'd recommend (a) using xf86-video-nouveau [RH has made local changes to this driver to not load, but I believe this to be a very bad idea, you can override with an xorg.conf iirc], and (b) updating to a 4.20+ kernel so that you get HDMI 2.0 to work to get access to the higher refresh rates.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/484.