OS: Fedora 26
Videocard: AMD ATI Radeon HD5750 (Juniper)
Monitor: Philips 231T
Video driver: radeon

I post this in the hope more people find this simple solution.

Problem description:
When booting into Fedora (passing grub), during boot the screen shortly goes black (switching from a lower to higher resolution), then randomly:
1. The monitor does not get a signal anymore and displays: no signal
Only thing that is possible to do is to switch off the computer
or
2. The computer displays boot messages in higher resolution and boots normally (I don't have "quiet" in my kernel line)

What is happening?
The kernel takes over from grub and is using kernel mode setting (KMS) to display the screen.
(Read here why KMS is nice: https://wiki.archlinux.org/index.php...l_mode_setting). KMS is by default enabled.
There are some sources that state that Radeon cards cannot handle KMS.

Solution:
You *could* add "nomodeset" or "radeon.modeset=0" to the line that loads the kernel in grub. This disables KMS, but also causes resolution problems once booted.

The solution for me:
Connecting the monitor via a hdmi cable to the videocard. A black screen is still displayed shortly (<5s), but all boots succeed normally.
It was connected via a dvi to vga cable. Of course was better to connect the monitor via hdmi anyway.

Summarized:
old [random blank screen]: dvi-out videocard - cable(dvi->vga) - vga-in monitor
new [working]: hdmi videocard - cable(hdmi) - hdmi-in monitor

Greetings,
moon

KMS should never be disabled in current and recent distributions except for: 1-troubleshooting; 2-in complying with proprietary driver instructions, or; 3-(uncommon/old) gfxchips lacking Xorg driver support. Without KMS, with all mainstream gfxchips, only VESA modes, none of which match any widescreen mode, are available.

Current kernels have driver functionality built-in. The radeon "driver" in the kernel is automatic, and distinct from the radeon driver for Xorg and Wayland. For Xorg, its built-in modesetting driver typically works better for older AMD/ATI gfx than the optional radeon driver.

I remember similarly inexplicable behavior in the past with my HD5450 and two or three displays. The HD5450 is a marginally newer design than moon300's HD5750, so probably the latter is like the former in having only 2 PLL clocks to feed its 3 physical output connectors. With all three in use, the PLL limitation requires the same clock be used for at least two of the displays to keep all three active.

Just now I booted F26 and F27 into multi-user.target with 2 displays connected. Everything was fine until KMS kicked in, at which point the HDMI-connected display went into power save. Then I connected a third display and booted openSUSE Tumbleweed. Two displays lit up to start, but one of the two went dark and the third lit up when KMS kicked in. Then I tried Debian Stretch the same way as TW. Two displays lit up to start, and when KMS kicked on, the third lit up along with the first two. Next I booted F26 with kernel cmdline's video parameters exactly matching those for Stretch, and got exactly the same ultimate three outputs as with Stretch. I repeated TW with the same cmdline video as Stretch, and KMS again switched the DVI off and the VGA on, but I repeated once more exactly the same, and all three stayed on.

The displays I used were 1680x1050 native on VGA, 1920x1080 native on HDMI and 2560x1080 native on DVI-D. The kernels were 4.9 on Stretch and 4.14 on Fedora and openSUSE.

For each three-connected test, always the initial display appeared on the HDMI and DVI ports. For the only two tests the (primary) DVI was unconnected.

The gist seems to be that kernel (KMS) seems to be mis-handling feedback from these triple output gfxcards unless their primary (DVI, physically closest to PCIe slot) connector is in use. When the primary is not connected, results seem to be unpredictable.