Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 599484 - gnome-base/gdm[wayland] VT switching issues
Summary: gnome-base/gdm[wayland] VT switching issues
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-11 14:59 UTC by Émeric Maschino
Modified: 2019-11-02 15:14 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Émeric Maschino 2016-11-11 14:59:47 UTC
Hi,

VT switching (Ctrl+Alt+F1... F7) doesn't really work. Tested with two different configurations: Weston and GDM/GNOME. Let me explain.

1) Weston 1.11 situation:

No login manager enabled at system startup.
Weston started from VT #1 with weston-launch.
No apparent problem when switching to an other VT and then going back to the one hosting Weston.
But upon closer inspection, if I open a Weston terminal before switching to an other VT, when I go back to the VT hosting the Weston session, I'm no more able to input commands in the Weston terminal window, as if it was unable to gain mouse focus. This can be easily checked: before switching to an other VT, the prompt cursor in the Weston terminal is a solid square, meaning that it has mouse focus and accepts inputs. But once switched to an other VT and back to the VT hosting the Weston session, the prompt cursor in the Weston terminal is now a clear square and it's no more accepting inputs.
Closing and opening an other Weston terminal window solves the problem though.

2) GDM/GNOME 3.20 situation:

2a) GNOME session (defaulting to X11):

Starting with version 3.18 (IIRC), GDM is using Wayland backend by default if Wayland is enabled and available. I've checked that GDM 3.20 is indeed using Wayland by default and also noticed that it's running on VT #7.
Once logged into GNOME Shell, the GNOME session appears to be running on VT #2. I can switch back and forth to other VTs (but VT #7; more on this later) and go back to GNOME Shell (VT #2) without a problem.
But if I mistakenly switch to VT #7, I can briefly see GDM's last status (e.g. lock screen with clock if GNOME session was running for a sufficient long time), the screen goes black (it's _not_ entering into power saving mode, as monitor LED is still solid green) and from there, I'm unable to switch to an other VT or kill the graphics mode (with Ctrl+Alt+Backspace).
The system is _not_ hang though, as I can log in remotely.
Remotely restarting GDM doesn't help either and a restart is needed to recover from there.

2b) GNOME on Wayland session:

Both GDM and GNOME session are running Wayland.
I'm unable to tell which VT is occupied by GDM and which one is used by the GNOME session (or if both are sharing the same VT), since as soon as I switch to an other VT (e.g. VT #1), I'm then unable to go back to the graphics mode (I've cycled through the entire F1-F7 range).
Restarting GDM from e.g. VT #1 doesn't help and a system restart is required to recover graphics mode.

All this on ia64 workstation with r300g driver. Well, I suppose: GNOME session (so X11 backend) reports video adapter as Gallium 0.4 on ATI R300 whereas GNOME on Wayland session simply reports video adapter as Wayland.

Are you experiencing the same issues on other arches?

Thanks,

     Émeric
Comment 1 Émeric Maschino 2016-11-11 15:01:16 UTC
emerge --info output:

Portage 2.2.26 (python 3.4.3-final-0, default/linux/ia64/13.0/desktop/gnome/systemd, gcc-4.9.3, glibc-2.22-r4, 4.1.15-gentoo-r1 ia64)
=================================================================
System uname: Linux-4.1.15-gentoo-r1-ia64-Madison-with-gentoo-2.2
KiB Mem:    24984848 total,  23191408 free
KiB Swap:     524272 total,    524272 free
Timestamp of repository gentoo: Thu, 10 Nov 2016 22:30:01 +0000
sh bash 4.3_p48
ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
app-shells/bash:          4.3_p48::gentoo
dev-lang/perl:            5.22.2::gentoo
dev-lang/python:          2.7.10-r1::gentoo, 3.4.3-r1::gentoo
dev-util/cmake:           3.3.1-r1::gentoo
dev-util/pkgconfig:       0.28-r2::gentoo
sys-apps/baselayout:      2.2::gentoo
sys-apps/openrc:          0.21.7::gentoo
sys-apps/sandbox:         2.10-r1::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69::gentoo
sys-devel/automake:       1.11.6-r1::gentoo, 1.14.1::gentoo, 1.15::gentoo
sys-devel/binutils:       2.25.1-r1::gentoo
sys-devel/gcc:            4.5.4::gentoo, 4.9.3::gentoo
sys-devel/gcc-config:     1.7.3::gentoo
sys-devel/libtool:        2.4.6::gentoo
sys-devel/make:           4.1-r1::gentoo
sys-kernel/linux-headers: 4.3::gentoo (virtual/os-headers)
sys-libs/glibc:           2.22-r4::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000

my_ebuilds
    location: /var/lib/layman/my_ebuilds
    masters: gentoo
    priority: 0

ACCEPT_KEYWORDS="ia64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="ia64-unknown-linux-gnu"
CFLAGS="-O2 -pipe -mtune=itanium2"
CHOST="ia64-unknown-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe -mtune=itanium2"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe -mtune=itanium2"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe -mtune=itanium2"
GENTOO_MIRRORS="ftp://mirrors.linuxant.fr/distfiles.gentoo.org/"
LANG="fr_FR.utf8"
LDFLAGS="-Wl,-O1"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac acl acpi alsa berkdb branding bzip2 cairo cdda cdr cli colord cracklib crypt cups cxx dbus dri dts dvdr eds encode evo exif fam firefox flac fortran gdbm gif glamor gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk ia64 iconv introspection ipv6 jpeg lcms ldap libnotify libsecret mad mng modules mp3 mp4 mpeg nautilus ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt3support qt4 readline sdl session spell ssl startup-notification svg systemd tcpd tiff tracker truetype udev udisks unicode upower usb vorbis wayland wxwidgets xattr xcb xml xv xvid zlib" ALSA_CARDS="fm801" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" L10N="fr" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="fr" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" VIDEO_CARDS="radeon fbdev" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Comment 2 Émeric Maschino 2016-11-11 15:02:40 UTC
emerge -pqv output:

[ebuild   R   ] dev-libs/wayland-1.11.0  USE="-doc -static-libs"
Comment 3 Jonas Stein gentoo-dev 2016-11-11 19:13:54 UTC
Émeric, thank you for the report. 
The problem seems to be a bit more complicate and we need more details to locate the origin of the trouble.
I could not reproduce it here.

Please contact our support channels [1] and add details here so that the maintainer can fix the problem.


[1] https://www.gentoo.org/support/
Comment 4 Émeric Maschino 2017-03-28 20:14:59 UTC
(In reply to Jonas Stein from comment #3)
> Émeric, thank you for the report. 
> The problem seems to be a bit more complicate and we need more details to
> locate the origin of the trouble.
> I could not reproduce it here.
> 
> Please contact our support channels [1] and add details here so that the
> maintainer can fix the problem.
> 
> 
> [1] https://www.gentoo.org/support/

Jonas, which support channel is preferred for this issue?

For the records, same problems with GDM/GNOME updated to 3.22 and Wayland updated to 1.12.

     Émeric
Comment 5 Mart Raudsepp gentoo-dev 2017-03-28 20:39:12 UTC
for the record, this isn't a problem on amd64 gnome wayland and it's hard to imagine it being a dev-libs/wayland (a protocol package) issue, though it being an arch specific issue in both weston and gnome-shell does seems a bit suspect and pointing towards something common, like dev-libs/wayland
Comment 6 Jonas Stein gentoo-dev 2017-03-28 21:38:16 UTC
Émeric, that depends on your personal preference. I would suggest to start on the IRC channel #gentoo, because you have to isolate the problem first. There are very experienced and helpful users. The problem seems not trivial, but perhaps they have a clue.

Prepare your logfiles and a pastebin tool like app-text/pastebinit.

I close the ticket here and suggest you open a new ticket if necessary with the precise description. From my experience maintainers often can fix bugs with a precise two line report like "dependency dev-python/pyx-1.2b is missing" within a few days, while a 200 line quest takes forever. 
Good luck. JS
Comment 7 Émeric Maschino 2017-03-28 21:51:50 UTC
(In reply to Mart Raudsepp from comment #5)
> for the record, this isn't a problem on amd64 gnome wayland and it's hard to
> imagine it being a dev-libs/wayland (a protocol package) issue, though it
> being an arch specific issue in both weston and gnome-shell does seems a bit
> suspect and pointing towards something common, like dev-libs/wayland

Exactly. That's why I did open this BR against dev-libs/wayland.

Dumb question: how do you enable GNOME Wayland on amd64 arch? On ia64, there's no such profile. Only:

  [1]   default/linux/ia64/13.0
  [2]   default/linux/ia64/13.0/desktop
  [3]   default/linux/ia64/13.0/desktop/gnome
  [4]   default/linux/ia64/13.0/desktop/gnome/systemd *
  [5]   default/linux/ia64/13.0/developer
  [6]   hardened/linux/ia64

And desktop/gnome/systemd profile I'm currently running doesn't set wayland USE flag. So to enable Wayland support on ia64, I currently have USE="${USE} wayland" in /etc/portage/make.conf.

That may not be the right way to enable Wayland system-wide (hence the problems I'm reporting here) but Gentoo Wiki's Wayland [1] isn't very verbose about how to enable Wayland support globally.

     Émeric

[1] https://wiki.gentoo.org/wiki/Wayland
Comment 8 Mart Raudsepp gentoo-dev 2017-03-28 22:44:29 UTC
@jstein: Thanks for the bug wrangling, but I don't think it's appropriate to close this invalid after all this time on our valued ia64 arch tester who clearly has a real potentially arch specific bug here. Though it might be appropriate to change the assignee to gnome@, pending further investigation

@emeric: for GNOME Wayland you would indeed have USE=wayland on many packages, then have gdm actually use wayland itself and then be able to log into "GNOME on Wayland" session out of the choices. There are some known issues on actually having GDM succeed to run a wayland session on initial boot, but if "GNOME on Wayland" shows up in the settings, it succeeded. The issue mentioned might be constrained to amd64 or intel hardware as I haven't seen widespread reports of it.
Comment 9 Émeric Maschino 2017-03-29 20:57:10 UTC
(In reply to Mart Raudsepp from comment #8)
> @jstein: Thanks for the bug wrangling, but I don't think it's appropriate to
> close this invalid after all this time on our valued ia64 arch tester who
> clearly has a real potentially arch specific bug here. Though it might be
> appropriate to change the assignee to gnome@, pending further investigation

No problem here :-)

In fact, when I was asking Jonas if there was a preferred support channel, I was thinking that Jonas had knowledge of some Wayland upstream developers who are running Gentoo and could be reached on IRC, rather than forums or anything else.

> @emeric: for GNOME Wayland you would indeed have USE=wayland on many
> packages, then have gdm actually use wayland itself and then be able to log
> into "GNOME on Wayland" session out of the choices. There are some known
> issues on actually having GDM succeed to run a wayland session on initial
> boot, but if "GNOME on Wayland" shows up in the settings, it succeeded. The
> issue mentioned might be constrained to amd64 or intel hardware as I haven't
> seen widespread reports of it.

This is where I'm lost ;-)

I know that gnome-base/gdm accept wayland USE flag, but I don't know which other package(s) need(s) it too to enable GNOME on Wayland session. Indeed, passing wayland USE flag to gnome-base/gdm only enable GDM to run on Wayland by default. But it doesn't enable GNOME on Wayland session. For this, you have to pass wayland USE flag to other package(s), but which one(s)? x11-wm/mutter comes to mind, but what else?

So when people were talking about enabling global wayland USE flag, I thought that they were talking about adding wayland USE flag to make.conf. This is what I (inappropriately, as it seems) did and this ended up building the following packages with wayland USE flag set:
- app-i18n/ibus
- dev-cpp/gtkmm
- gnome-base/gdm
- gnome-base/gnome-control-center
- gnome-base/gnome-settings-daemon
- media-libs/clutter
- media-libs/clutter-gtk
- media-libs/cogl
- media-libs/gst-plugins-bad
- media-libs/mesa
- net-libs/webkit-gtk
- x11-base/xorg-server
- x11-libs/gtk+:3
- x11-wm/mutter

Now from this list, without having added wayland USE flag to make.conf, how would have I guessed which package(s) also need(s) it to enable GNOME on Wayland session? Is it x11-wm/mutter? Or gnome-base/gnome-control-center? Or maybe gnome-base/gnome-settings-daemon? Or a combination of all of these?

All I know is that I can select and run GNOME on Wayland session from the GDM login screen. I simply don't know which package(s) is(are) responsible for it and if everything else is correctly configured on my system to make use of Wayland globally.

See what I mean?

     Émeric
Comment 10 Émeric Maschino 2017-03-29 22:31:03 UTC
(In reply to Émeric Maschino from comment #0)
> 
> VT switching (Ctrl+Alt+F1... F7) doesn't really work. Tested with two
> different configurations: Weston and GDM/GNOME. Let me explain.
> 
> 1) Weston 1.11 situation:
> 
> No login manager enabled at system startup.
> Weston started from VT #1 with weston-launch.
> No apparent problem when switching to an other VT and then going back to the
> one hosting Weston.
> But upon closer inspection, if I open a Weston terminal before switching to
> an other VT, when I go back to the VT hosting the Weston session, I'm no
> more able to input commands in the Weston terminal window, as if it was
> unable to gain mouse focus. This can be easily checked: before switching to
> an other VT, the prompt cursor in the Weston terminal is a solid square,
> meaning that it has mouse focus and accepts inputs. But once switched to an
> other VT and back to the VT hosting the Weston session, the prompt cursor in
> the Weston terminal is now a clear square and it's no more accepting inputs.
> Closing and opening an other Weston terminal window solves the problem
> though.

This issue is now gone for Weston with =dev-libs/wayland-1.12.0 and =dev-libs/weston-1.12.0 :-)

For GDM/GNOME 3.22, the situation hasn't changed. So, as proposed by Mart Raudsepp in comment #8, I think it's indeed "appropriate to change the assignee to gnome@, pending further investigation".

Now updating BR title to reflect the situation.

     Émeric
Comment 11 Mart Raudsepp gentoo-dev 2017-03-30 10:38:25 UTC
(In reply to Émeric Maschino from comment #9)
> So when people were talking about enabling global wayland USE flag, I
> thought that they were talking about adding wayland USE flag to make.conf.

Globally setting it does sound appropriate. While you might not need it for everything, they might not work optimally if not done. As we reverted GNOME 3.22 default back to Xorg prior to stabilization, I haven't personally looked into brushing up any documentation on it yet - that would be on my TODO before 3.24 stabilization I suppose.

> This is what I (inappropriately, as it seems) did and this ended up building
> the following packages with wayland USE flag set:

Some random comments on what I think the flags do on these

> - app-i18n/ibus

I don't know what it does here, it probably adds some wayland suppor code. I'm not sure if this is necessary for advanced input methods (japanese, chinese, etc) in gnome-shell as of yet, or if that still goes via Xwayland.

> - dev-cpp/gtkmm

This probably enables compiling the gtk+ wayland specific functions.

> - gnome-base/gdm

This makes gdm try to run in wayland itself, and thus reads available wayland sessions out of /usr/share/wayland-sessions/
gnome-base/gnome-session installs a "gnome.desktop" in there regardless (For 3.22 due to our revert a "GNOME on Wayland" session still as gnome-wayland.desktop). So technically to have "GNOME on Wayland" you only need gdm[wayland] as gnome-session installs a wayland-session file unconditionally.
In 3.24 we will go back to upstream defaults, which means there will be both /usr/share/wayland-sessions/gnome.desktop and /usr/share/xsessions/gnome.desktop so if you have "gnome" as your selected session saved in AccountsService configuration (/var/lib/AccountsService/users/$USER), you will have a GNOME session that logs to wayland if gdm is in wayland and fallbacks to Xorg if gdm is using Xorg (either by USE=-wayland or because something crashed with wayland and it fell back to Xorg itself due to that). gdm manages that AccountsService configuration and saves a different one when you change it in the menu and proceed to log in with it. In 3.24 there will be a /usr/share/xsessions/gnome-xorg.desktop "Gnome on Xorg" to force Xorg even if gdm is using wayland - this is also so in 3.22 upstream, but we patch it with files/3.22.3-xorg-default.patch in gnome-session package.

> - gnome-base/gnome-control-center
> - gnome-base/gnome-settings-daemon

These add wayland support into them. This mostly means having code to detect if the running session in Wayland and then acting accordingly. E.g, some settings-daemon plugins shouldn't run under Wayland, some need to query information differently, etc. As core GNOME package, it's of course a good idea to have USE=wayland enabled here for GNOME Wayland sessions.

> - media-libs/clutter
> - media-libs/clutter-gtk
> - media-libs/cogl

These probably add native Wayland support like gtk+ itself (they are essentially a separate toolkit package really, a pre-cursor to what will be in GTK4 itself).
You probably should have USE=wayland here, but x11-wm/mutter itself (the WM part of gnome-shell) in 3.22 bundles its own clutter and cogl (and doesn't use clutter-gtk).

> - media-libs/gst-plugins-bad

This as one thing enables building of a wayland gstreamer plugin with a wayland video output sink element that can output directly to a wayland window/surface. This isn't all that interesting other than gst-launch-1.0 manual usage imho, however more important this USE flag also enables wayland support for other components (when those are enabled):
Wayland wsys (windowing system) support for the OpenGL helper library, so that the gl elements can output to wayland (severely simplified technical purpose). Enabled with gst-plugins-bad[egl,opengl,wayland] or gst-plugins-bad[egl,gles2,wayland].
Wayland wsys support for the Vulkan helper library, so that the Vulkan elements can output to wayland like the GL elements. USE=vulkan stuff isn't exposed in the Gentoo package yet, but once I get to that, that's what it'll do in combination with USE="vulkan wayland"
Wayland support for the gtkglsink (a helper plugin to integrate an OpenGL video sink into a GTK+:3 application, essentially an upcoming replacement to clutter-gst), enabled with gst-plugins-bad[gtk,egl,wayland]. Applications would probably want to RDEPEND on gst-plugins-bad[gtk] then if they use gtkglsink, but e.g totem hasn't converted away to it yet from clutter-gst.

> - media-libs/mesa

Adds wayland wsys support to your enabled open source drivers. This is required by gdm[wayland] and I believe is expressed there with USE dependencies.
This might change with 3.24, as 3.24 supports proprietary nvidia-drivers EGLStreams based different wayland support as well (you'd still need mesa[wayland] if not using nvidia-drivers though).

> - net-libs/webkit-gtk

Adds wayland support. Might work otherwise too natively on Wayland, but this adds knowledge of wayland subsurfaces and an internal wayland compositor and other stuff to be able to keep e.g html5 video hardware accelerated

> - x11-base/xorg-server

Enables building of Xwayland for non-native wayland apps to continue working via that. Currently gnome-shell itself requires Xwayland as well, and so GNOME3 can't yet be ran without Xwayland even when your limited set of applications are all known to support wayland natively.

> - x11-libs/gtk+:3

The main thing for gtk wayland. Without this, GTK3 apps don't know native wayland and would use something else (probably X11 on linux). Without this, gtk apps would still work on wayland desktops via Xwayland, but gdm/gnome-shell etc probably need native wayland support in gtk+ (but one might be using a wayland plasma session or something).

> - x11-wm/mutter

Mutter embeds clutter now, so it needs wayland enabled for clutter to be able to do wayland natively and thus gnome-shell to work at all with wayland, and gdm[wayland] uses gnome-shell, so... :)

> Now from this list, without having added wayland USE flag to make.conf, how
> would have I guessed which package(s) also need(s) it to enable GNOME on
> Wayland session? Is it x11-wm/mutter? Or gnome-base/gnome-control-center? Or
> maybe gnome-base/gnome-settings-daemon? Or a combination of all of these?

I apparently myself have a per-package set on gtk+, mesa, gdm, cogl, clutter, clutter-gtk, xorg-server, mutter, gnome-settings-daemon, gnome-control-center, libva, libva-intel-driver and mpv. But this is only because I was validating USE=wayland USE deps or some such and haven't yet gotten around to setting it globally. I should go do that.

> All I know is that I can select and run GNOME on Wayland session from the
> GDM login screen. I simply don't know which package(s) is(are) responsible
> for it and if everything else is correctly configured on my system to make
> use of Wayland globally.

With Wayland VT switching has to be implemented by the compositor. So basically mutter or gnome-shell (well, same thing, gnome-shell is a plugin to mutter) is responsible for catching VT switching keys and then doing it. This works for me in 3.22 and also did work in 3.20. Due to the compositor being responsible for it, not a separate process xorg-server anymore, then if the desktop is frozen, VT switching might not work too, while ssh'ing and chvt'ing or something might still work. But I presume you have issues with switching while things otherwise work.
Comment 12 Émeric Maschino 2017-04-02 18:34:15 UTC
(In reply to Mart Raudsepp from comment #11)

<snip>

Many thanks for the detailed explanation of the wayland USE flag per package. This sheds some light here.

<snip>

> > - gnome-base/gdm
> 
> This makes gdm try to run in wayland itself, and thus reads available
> wayland sessions out of /usr/share/wayland-sessions/
> gnome-base/gnome-session installs a "gnome.desktop" in there regardless (For
> 3.22 due to our revert a "GNOME on Wayland" session still as
> gnome-wayland.desktop). So technically to have "GNOME on Wayland" you only
> need gdm[wayland] as gnome-session installs a wayland-session file
> unconditionally.
> In 3.24 we will go back to upstream defaults, which means there will be both
> /usr/share/wayland-sessions/gnome.desktop and
> /usr/share/xsessions/gnome.desktop so if you have "gnome" as your selected
> session saved in AccountsService configuration
> (/var/lib/AccountsService/users/$USER), you will have a GNOME session that
> logs to wayland if gdm is in wayland and fallbacks to Xorg if gdm is using
> Xorg (either by USE=-wayland or because something crashed with wayland and
> it fell back to Xorg itself due to that). gdm manages that AccountsService
> configuration and saves a different one when you change it in the menu and
> proceed to log in with it. In 3.24 there will be a
> /usr/share/xsessions/gnome-xorg.desktop "Gnome on Xorg" to force Xorg even
> if gdm is using wayland - this is also so in 3.22 upstream, but we patch it
> with files/3.22.3-xorg-default.patch in gnome-session package.

Right now (gnome-base/gdm-3.22.3), I have:
- /usr/share/wayland-session/gnome-wayland.desktop (GNOME on Wayland)
- /usr/share/xsessions/gnome-custom-session.desktop (dunno)
- /usr/share/xsessions/gnome.desktop (GNOME on X11)
- /usr/share/xsessions/Xsession.desktop (irrelevant here; I think it's twm).

As an exercise, I've switched from global wayland USE flag to per package. It seems that gnome-base/gdm[wayland] only needs media-libs/clutter[wayland], media-libs/cogl[wayland], media-libs/mesa[wayland] and x11-libs/gtk+:3[wayland]. x11-wm/mutter[wayland] isn't listed.

<snip>

> > - x11-base/xorg-server
> 
> Enables building of Xwayland for non-native wayland apps to continue working
> via that. Currently gnome-shell itself requires Xwayland as well, and so
> GNOME3 can't yet be ran without Xwayland even when your limited set of
> applications are all known to support wayland natively.

Haha, that's interesting. Under GNOME on Wayland, I've noticed that gnome-shell itself was sometimes eating 100% CPU. Since Xwayland leverages glamor and glamor can't be initialized on my FireGL X1 graphics adapter, it switches to Gallium 0.4 on softpipe as OpenGL renderer whereas under GNOME on X11, glxinfo is reporting Gallium 0.4 on ATI R300, which is fine. I've opened a bug upstream [1] with the root cause of this, though it's not necessarily a bug, maybe just a lack of explanation. It's nevertheless problematic for GL apps that are barely usable as-is under GNOME on Wayland, while running fine under X11.

> > - x11-wm/mutter
> 
> Mutter embeds clutter now, so it needs wayland enabled for clutter to be
> able to do wayland natively and thus gnome-shell to work at all with
> wayland, and gdm[wayland] uses gnome-shell, so... :)

As reported earlier, gnome-base/gdm[wayland] doesn't seem to require x11-wm/mutter[wayland]. Maybe Wayland support is always enabled in Mutter nowadays.

> I apparently myself have a per-package set on gtk+, mesa, gdm, cogl,
> clutter, clutter-gtk, xorg-server, mutter, gnome-settings-daemon,
> gnome-control-center, libva, libva-intel-driver and mpv. But this is only
> because I was validating USE=wayland USE deps or some such and haven't yet
> gotten around to setting it globally. I should go do that.

Did you also tried to switch off USE=wayland on all packages, but gnome-base/gdm  and try emerge -avuDN @world to see which other packages also need USE=wayland flag? Do you get the same short list than the one I've provided earlier?

> With Wayland VT switching has to be implemented by the compositor. So
> basically mutter or gnome-shell (well, same thing, gnome-shell is a plugin
> to mutter) is responsible for catching VT switching keys and then doing it.
> This works for me in 3.22 and also did work in 3.20. Due to the compositor
> being responsible for it, not a separate process xorg-server anymore, then
> if the desktop is frozen, VT switching might not work too, while ssh'ing and
> chvt'ing or something might still work. But I presume you have issues with
> switching while things otherwise work.

Exactly. So at the moment, systemctl stop/start gdm.service is a workaround.

     Émeric

[1] https://bugs.freedesktop.org/show_bug.cgi?id=100529
Comment 13 Mart Raudsepp gentoo-dev 2017-04-02 20:52:48 UTC
(In reply to Émeric Maschino from comment #12)
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=100529

I read something about gnome-shell using Xwayland there. What I meant here was that gnome-shell requires Xwayland for some stuff to work. It doesn't use Xwayland for rendering itself, it's a native wayland compositor - you don't have wayland otherwise, otherwise it's just an IPC protocol or so. It uses Xwayland for some stuff that isn't yet working natively on Wayland that it needs, like some XKB related stuff maybe, etc, but it doesn't render anything with it (Xwayland provides the whole stack of Xorg, not just rendering), unless it needs to run an application that is using X11 - then it sets up Xwayland stuff including rendering for that app to use or so.

For the rest I need to think and try or whatnot. But global USE=wayland is what I suggest - the rest is just technical QA USE dependency correctness or whatnot.
Comment 14 Mart Raudsepp gentoo-dev 2019-02-26 23:42:59 UTC
Is anything left to handle in this bug to keep it open?
Comment 15 Émeric Maschino 2019-03-01 21:13:43 UTC
(In reply to Mart Raudsepp from comment #14)
> Is anything left to handle in this bug to keep it open?

Well, I'm simply unable to test again since my HDD crashed and I had to reinstall everything from scratch. I'm actually stuck with bug #671538.
Comment 16 Émeric Maschino 2019-11-02 15:14:53 UTC
(In reply to Émeric Maschino from comment #15)
> (In reply to Mart Raudsepp from comment #14)
> > Is anything left to handle in this bug to keep it open?
> 
> Well, I'm simply unable to test again since my HDD crashed and I had to
> reinstall everything from scratch. I'm actually stuck with bug #671538.

A lot of things have changed in the passed months and I'm no more seeing the issues I was reporting there with GNOME 3.30 (still with =gnome-base/gnome-shell-3.26.2-r4 and =x11-wm/mutter-3.26.2-r1 because ia64 isn't keyworded at all for >gnome-base/gnome-light-3.26.2), =dev-libs/wayland-1.17.0 and =dev-libs/wayland-protocols-1.18.

For completeness, GDM is on VT #1 and GNOME Shell on VT #7.