Hi, Since wayland does not yet support prime and esp. not slave outputs, gdm really should fallback to Xorg if there are 2 /dev/dri/card# devices. Otherwise external connectors on laptops which are only connected to the discrete gpu will not be usable (without manually switching to a gnome on xorg session). I guess this has been a problem wrt the login screen not showing on such external displays for a while now, but although for the login screen this typically is not a big problem, this is a problem with the actual gnome-session, think e.g. not being able to use a projector on conferences because of this. Regards, Hans
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