doesn't open after logging in Xorg session "cannot open display"

[fastoslinux]

Fedora Silverblue 31 Version: 31.20191006.n.1

1 - login in wayland 2- GNOME Boxes it works 3 - logout 4 - login in GNOME Xorg 5 - GNOME Boxes do not open

if I reboot and go to Xorg, it works

Error: $ flatpak run org.gnome.Boxes Unable to init server: Não foi possível conectar: Conexão recusada

(gnome-boxes:2): Gtk-WARNING **: 13:15:49.272: cannot open display:

Info $ flatpak info org.gnome.Boxes

Caixas GNOME - Máquinas virtuais e remotas simples

    ID: org.gnome.Boxes
   Ref: app/org.gnome.Boxes/x86_64/stable
  Arq.: x86_64
  Ramo: stable
Versão: 3.34.0

Licença: LGPL-2.1+ Origem: flathub Coleção: org.flathub.Stable Instalação: system Instalado: 611,7 MB Runtime: org.gnome.Platform/x86_64/3.34 Sdk: org.gnome.Sdk/x86_64/3.34

Commit: c464779c7bdfbd056c52c519dd7f4022fad382380a6f174f087f4ddf05bf1b13
   Pai: fb1b815fa89f283b240136a2b3668f05e29feeaf58c34adc6750ff25277cc2f8

Assunto: Release 3.34.0 (bdcc216a) Data: 2019-09-13 12:16:42 +0000

Vídeo: $ glxinfo | grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.33.0, 5.3.2-300.fc31.x86_64, LLVM 9.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.2.0 OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.2.0 OpenGL shading language version string: 4.50 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.2.0 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 OpenGL ES profile extensions:

[felipeborges]

Thanks for reporting this bug!

I see the same issue also for GNOME Builder. It is interesting that if I boot directly into an X session, it works. But if I logout from a Wayland session and login into a X session, I get the same bug.

I will bring the discussion to my colleagues working in Wayland to see what could have introduced this regression.

[felipeborges]

Apparently, it works if you remove the --socket=fallback-x11 in the permission. Could you verify whether that works for you?

Regardless, it is still a bug. I just want to confirm it is a Flatpak one. :) Thanks!

[A6GibKm]

@felipeborges, as far as I know GNOME apps work just fine with the sockets wayland and x11-fallback, while many Kde apps require wayland and x11 in order to work on X. In this particular case the app is using both x11-fallback and x11 and it should use only one, maybe it could be related to that.

[debarshiray]

Did this get fixed on GNOME 3.38 hosts?

The cannot open display error makes me suspect that this is related to the way Mutter sets up Xwayland in the user's session. Especially since it manifests itself when switching from a Wayland session to an Xorg one.

X11 servers can listen on two local sockets -- one abstract, and the other a file system socket at `/tmp/.X11-unix. Flatpak applications (or X11 clients) only use the file system socket, because Flatpak containers have a separate network namespace that prevents them from connecting to the abstract socket.

Prior to GNOME 3.38, Mutter used to only listen for X11 clients connecting to the abstract socket. If the first X11 client inside a Wayland session was a Flatpaked one, then Mutter wouldn't launch Xwayland, and the application would fail to start. In GNOME 3.38, Mutter was changed to only listen for connections to the file system socket to address the issue.

I haven't fully thought this through, but it's worth checking if this issue is still relevant.

[felipeborges]

Did this get fixed on GNOME 3.38 hosts?

No, it doesn't seem so. I just tried to reproduce the steps pointed by OP above and I still get the "cannot open display" warning, and the app doesn't launch.

The cannot open display error makes me suspect that this is related to the way Mutter sets up Xwayland in the user's session. Especially since it manifests itself when switching from a Wayland session to an Xorg one.

Sounds like this could be the culprit. I recall @grulja was mentioning a similar issue with KDE applications. I'm not sure tho.