Filed upstream as:
https://bugzilla.gnome.org/show_bug.cgi?id=771442

Lets track this there.

let's use this bug to track the bodhi update

mutter-3.22.1-4.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-018689d0e7

mutter-3.22.1-4.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Well it's a problem for me as I can no longer run gnome on wayland session on my Dell Latitude E6540 (intel + AMD hybrid graphics).
 
Whereas it was working fine before this update, even with an external monitor plugged in.

I'm sorry that things stopped working for you.  This suggests that there are some connectors on your laptop that are only hooked up to the AMD card.

Can you post the output of

ls /sys/class/drm/*

?

As a near term workaround, you can put MUTTER_ALLOW_HYBRID_GPUS=1 in /etc/environment and it should revert to the old behavior.

(In reply to Ray Strode [halfline] from comment #6)
> I'm sorry that things stopped working for you.  This suggests that there are
> some connectors on your laptop that are only hooked up to the AMD card.

Or they are connected via a mux, so both GPUs will appear to have connectors at the drm driver level, but only outputs connected to the primary GPU (the one selected in the BIOS as default) are routed to the outside.

I'm afraid that there is no way to detect this, the mux routing (if there is a mux) cannot be determined via any known means. So people with a mux will typically see a ton of connectors in xrandr and only be able
to plug cables into some of them.

I do believe that falling back to Xorg by default is the right thing to do here, since we simply do not know if there are external connectors routed only to the secondary GPU and we don't want people to end up being unable to plug a projector into their laptop.

One good thing here is that (judging from my limited sample set) more and more laptops seem to forgo the mux and there the dgpu does typically report 0 outputs.

FYI - here is the output of ls /sys/class/drm/*


/sys/class/drm/version

/sys/class/drm/card0:
card0-VGA-2  dev  device  power  subsystem  uevent

/sys/class/drm/card0-VGA-2:
device  dpms  edid  enabled  modes  power  status  subsystem  uevent

/sys/class/drm/card1:
card1-DP-1      card1-HDMI-A-3  gt_act_freq_mhz  gt_RP1_freq_mhz  uevent
card1-DP-2      card1-VGA-1     gt_cur_freq_mhz  gt_RPn_freq_mhz
card1-eDP-1     dev             gt_max_freq_mhz  l3_parity
card1-HDMI-A-1  device          gt_min_freq_mhz  power
card1-HDMI-A-2  error           gt_RP0_freq_mhz  subsystem

/sys/class/drm/card1-DP-1:
device  drm_dp_aux1  enabled  modes  status     uevent
dpms    edid         i2c-15   power  subsystem

/sys/class/drm/card1-DP-2:
device  drm_dp_aux2  enabled  modes  status     uevent
dpms    edid         i2c-16   power  subsystem

/sys/class/drm/card1-eDP-1:
device  drm_dp_aux0  enabled  intel_backlight  power   subsystem
dpms    edid         i2c-14   modes            status  uevent

/sys/class/drm/card1-HDMI-A-1:
device  dpms  edid  enabled  modes  power  status  subsystem  uevent

/sys/class/drm/card1-HDMI-A-2:
device  dpms  edid  enabled  modes  power  status  subsystem  uevent

/sys/class/drm/card1-HDMI-A-3:
device  dpms  edid  enabled  modes  power  status  subsystem  uevent

/sys/class/drm/card1-VGA-1:
device  dpms  edid  enabled  modes  power  status  subsystem  uevent

/sys/class/drm/controlD64:
dev  device  power  subsystem  uevent

/sys/class/drm/controlD65:
dev  device  power  subsystem  uevent

/sys/class/drm/renderD128:
dev  device  power  subsystem  uevent

/sys/class/drm/renderD129:
dev  device  power  subsystem  uevent

/sys/class/drm/ttm:
buffer_objects  memory_accounting  power  subsystem  uevent