Description of problem: When using lightdm, and launching 'Gnome' (not Gnome on Xorg or Gnome Classics), the value of $XDG_SESSION_TYPE=x11 and echo $WAYLAND_DISPLAY result in nothing. When enabling GDM and disabling LightDM, this problem goes away. Version-Release number of selected component (if applicable): [paul@localhost ~]$ sudo dnf repoquery --installed|grep lightdm [sudo] Mot de passe de paul : lightdm-0:1.30.0-8.fc32.x86_64 lightdm-gobject-0:1.30.0-8.fc32.x86_64 lightdm-gtk-0:2.0.6-3.fc32.x86_64 How reproducible: Tested it only once Steps to Reproduce: 1. Have default F32 Workstation installed 2. sudo dnf install lightdm 3. sudo systemctl disable gdm 4. sudo systemctl enable lightdm 5. reboot 6. Select user 7. In upper-right, choose 'Gnome' session type 8. Login 9. Open terminal 10. echo $WAYLAND_DISPLAY Actual results: empy line Expected results: wayland-0
lightdm by default lists sessions from any of these directories: lightdm.conf:#sessions-directory=/usr/share/lightdm/sessions:/usr/share/xsessions:/usr/share/wayland-sessions I take it you probably have a gnome-related one in both /usr/share/xsessions and /usr/share/wayland-sessions? Is it possible they're both named the same thing?
(In reply to Rex Dieter from comment #1) > lightdm by default lists sessions from any of these directories: > > lightdm.conf:#sessions-directory=/usr/share/lightdm/sessions:/usr/share/ > xsessions:/usr/share/wayland-sessions > > I take it you probably have a gnome-related one in both /usr/share/xsessions > and /usr/share/wayland-sessions? > > Is it possible they're both named the same thing? I removed /usr/share/wayland-sessions because it wasn't possible to launch wayland sessions https://src.fedoraproject.org/rpms/lightdm/c/1c37d517f59a3e89ee967ad6ae4803e6f0c57132?branch=master Feel free to revert it if you can launch wayland sessions, I couldn't even on Intel hardware.
OK, so sounds like this was done on purpose. Nevermind my question then.
(In reply to Rex Dieter from comment #1) > lightdm by default lists sessions from any of these directories: > > lightdm.conf:#sessions-directory=/usr/share/lightdm/sessions:/usr/share/ > xsessions:/usr/share/wayland-sessions > > I take it you probably have a gnome-related one in both /usr/share/xsessions > and /usr/share/wayland-sessions? > > Is it possible they're both named the same thing? Deleting /usr/share/xsessions/gnome.desktop and reverting this commit enables gnome wayland https://src.fedoraproject.org/rpms/lightdm/c/1c37d517f59a3e89ee967ad6ae4803e6f0c57132?branch=master Do you think the commit should be reverted and this issue reassigned to gnome so they can address the session desktop files with the same name?
the gnome issue should be considered a separate issue/bug that said, I have doubts they will be willing to fix it on their side. I predict they'll claim it should be the display manager's job to distinguish between X/wayland sessions (since that's what gdm does, the expectation is that other display managers follow suit)
(In reply to Rex Dieter from comment #5) > the gnome issue should be considered a separate issue/bug > > that said, I have doubts they will be willing to fix it on their side. I > predict they'll claim it should be the display manager's job to distinguish > between X/wayland sessions (since that's what gdm does, the expectation is > that other display managers follow suit) Upstream have a report https://github.com/canonical/lightdm/issues/58 I could revert the lightdm commit and ignore the gnome issue as it's no my duty to fix.
FEDORA-2020-e65f3355b1 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-e65f3355b1
FEDORA-2020-c4ccb19308 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c4ccb19308
FEDORA-2020-87c60d66ee has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-87c60d66ee
FEDORA-2020-c4ccb19308 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-c4ccb19308` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c4ccb19308 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-e65f3355b1 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-e65f3355b1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-e65f3355b1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-87c60d66ee has been pushed to the Fedora 30 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-87c60d66ee` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-87c60d66ee See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-e65f3355b1 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-87c60d66ee has been pushed to the Fedora 30 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-c4ccb19308 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.