Interactions between Desktop Environments.

ewaller · 2022-03-28 16:46:27

I could use a suggestion on how to troubleshoot this.

I am using Gnome on Wayland started from GDM.

I want to use an i3 session in parallel on a different console -- something I have done many times before with conjunction plasma, other i3 sessions, Openbox, etc.
But, with Gnome on Wayland, if I switch consoles, login and start i3wm using startx, it starts -- but attempting to open a terminal window in i3 appears to do nothing; that is nothing until one switches back to the Gnome console. It turns out the terminal window opened in i3 starts in Gnome.

Any ideas?

Archlin · 2022-03-28 16:59:09

You could try set something like this in your profile

# Start graphical server wayland on tty1 and x on tty2.
[ -z $DISPLAY ] && [ $(tty) = /dev/tty1 ] && MOZ_ENABLE_WAYLAND=1 QT_QPA_PLATFORM=wayland XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session

[ "$(tty)" = "/dev/tty2" ] && ! pgrep -x Xorg >/dev/null && exec startx

Last edited by Archlin (2022-03-28 17:47:54)

jlindgren · 2022-03-28 19:35:57

Some things I'd check:
- Which terminal emulator are you using?
- Is the terminal using some kind of D-Bus activation, or reusing a process that's already running under Gnome?
- Is the terminal using X11 or Wayland protocol?
- If X11, is DISPLAY set correctly?
- If Wayland, can you force the terminal to use X11 protocol (using e.g. GDK_BACKEND or QT_QPA_PLATFORM environment variables)?

Zod · 2022-03-28 19:54:16

You might try using one of the DE as a different user with the same /home/*

In the stackexchange link it talked a little bit about how only wayland or xorg could control the display at a given time.

I'm not sure I understand the question tho...

If I get your drift...
https://unix.stackexchange.com/question … y-in-linux

https://www.reddit.com/r/archlinux/comm … different/

Edit: Thought it might be a good idea to pull this out, Megame50 in the reddit link does a decent job sorta explaining the deal.

https://gitlab.gnome.org/GNOME/gtk/-/issues/1741

Last edited by Zod (2022-03-28 20:18:38)

dogknowsnx · 2022-03-28 20:01:56

Does it happen as well running sway?

Trilby · 2022-03-28 20:28:20

You could just set WAYLAND_DISPLAY to some arbitrary value other than "wayland-0" prior to starting your wayland session. Although given that gnome is your wayland session, this would require that gnome use the user-defined WAYLAND_DISPLAY value (which it really really really should), that way gnome can run on "wayland-42" or "ewallers-wayland-socket" or whatever you want to call it. Then when a gtk-terminal is launched from i3, it will still try to connect to "wayland-0" despite no WAYLAND_DISPLAY value being set in it's environment (which is really really really dumb) and when it fails, it will then fall back to using the DISPLAY value for the X11 connection.

GTK people trying to put the blame on compositors here is silly. The compositor is creating a new wayland display, and it makes sense for the compositor to just go for the lowest numbered unoccupied socket name. It could certainly use any other socket name, but there's no reason: just use wayland-N with the lowest unoccupied N, then export that value in an environment variable WAYLAND_DISPLAY for child processes to pick up. That makes sense.

Clients on the other hand are not creating new connections, they need to connect to an existing connection - so assuming "wayland-0" is ridiculous. They need to use the environment variable that the running compositor has exported. For clients that are wayland-only, however, this assumption is mostly benign as it only causes them to fail when they also would likely have failed anyways without the assumption. But for clients that can run on X or wayland, this assumption is absurd.

For the question above on sway, if you mean would it happen with sway and i3 running side-by-side: yes, it would as any gtk client in the i3-session would connect to "wayland-0" which is what sway would be using. On the other hand if you run gnome-wayland and sway side-by-side, then the gtk client in sway would connect to the socket specified by WAYLAND_DISPLAY which would be the correct one of "wayland-0" or "wayland-1" for whichever session they were in.

In X11 this problem was never faced as no X11 clients tried to connect to arbitrary display numbers. The first X11 server running would typically be :0, and a second one :1, but this was never assumed by a client: X11 clients use the environment variable DISPLAY, and if DISPLAY is not set, they exit with an error and do not guess just to connect to a random display server.

Last edited by Trilby (2022-03-28 21:11:57)

seth · 2022-03-28 21:01:43

If we're running w/ "ewaller uses gnome-terminal", this could be an issue: https://unix.stackexchange.com/a/201915
Trying to run two parallel session that use the same session bus can be nasty beyond that (eg. there's gonna be only one notification server…)

@Trilby, does gtk also try wayland-0 if you "export GDK_BACKEND=x11"?? (And there create an xwayland session, despite DISPLAY :0 sitting right in front of it)

Trilby · 2022-03-28 21:09:23

seth wrote:

@Trilby, does gtk also try wayland-0 if you "export GDK_BACKEND=x11"?? (And there create an xwayland session, despite DISPLAY :0 sitting right in front of it)

From the links above, it seems clear that gtk was ignoring DISPLAY and tries to connect to "wayland-0" even without a WAYLAND_DISPLAY variable being set. At the time of those posts, GDK_BACKEND was proposed as a potential solution, so clearly was not (yet) influencing the outcome. But I have no first hand experience nor am I willing to test w/ GTK myself.

Last edited by Trilby (2022-03-28 21:10:04)

ewaller · 2022-03-28 23:22:23

Sorry -- Got busy at work. Let me look through these and I'll get back.

Edit:
This does *not* happen when I:
Start sway from a command line, change console, start i3, open console.
Start sway from gdm, change console, start i3 from startx, open console.
Start Gnome on Xorg from gdm, change consoles, start i3 from startx, open console

Edit: Trilby, you made my head explode. I can tell you have spent a lot more time in the weeds of display servers than have I.

Last edited by ewaller (2022-03-28 23:58:52)

seth · 2022-03-29 07:41:42

Trilby wrote:

From the links above

I didn't realize that you were referencing them. Now you made me click on them…

db1 wrote:

We never stop using the things that hurt us. Like environment variables

db1 wrote:

Great example of how environment variables hurt us: there's too many to choose from, and everybody picks a different one.

db2 wrote:

Why isn't anyone proposing a solution that does not involve environment variables at all?

db1 wrote:

Rays comment outlines what needs to happen here. Somebody just needs to do the work

ray wrote:

1. If GDK_BACKEND is set, use it. fullstop.
2. If XDG_SESSION_TYPE is set, use it to determine the session type.
3. If XDG_SESSION_TYPE is not set, ideally we'd use sd_session_get_type to determine session type
4. If session type is graphical (x11 or wayland), use the session type to determine backend.
5. If session type is not graphical (not x11 and not wayland), and DISPLAY is not set assume wayland
6. If session type is not graphical (not x11 and not wayland), and DISPLAY is set assume x11

1,2,3,4,5: And on which DISPLAY/WAYLAND_DISPLAY if that's not set?

Wayland sessions will need WAYLAND_DISPLAY and DISPLAY, X11 only needs DISPLAY - so use WAYLAND_DISPLAY, fallback to DISPLAY and then tell the user that if they want to access a display *SERVER* they gotta tell which one. If really must be, try wayland-0
The only problem with that seems that we don't like environment variables, because then we can't hardcode the user experience nor stash it in our registry knock-off.

Nice reminder why I'm under the impression about gnome that I'm under.
It also reminds me why "protocols/rfc's suck, our library always encodes the standard" is retarded.
/grrrrr

also that thread wrote:

So could we not just agree to require that from now on: if you write a Wayland compositor or middleware library for compositors in 2020 always set the WAYLAND_DISPLAY environment variable.

Oh, if only there was a way to impact what variables are set on a given process. Some bio-inspired concept like, maybe, i don't know, the could perhaps "inherit" them from the parenting process/shell?
Also that suggestion sounds suspiciously like someone trying to sneak an rfc in there …
/sigh i hate reading gnome (toolkit) bugs.

@ewaller
But what I gather from that shit show, and exporting the DISPLAY and "GDK_BACKEND=x11" should™ do for you.

Trilby · 2022-03-29 13:09:49

seth wrote:

It also reminds me why "protocols/rfc's suck, our library always encodes the standard" is retarded.

Yup. Though the gtk discussion people are right about one thing: apparently, and sadly, the standard libwayland implementation does apparently use 'wayalnd-0' in the absence of a properly-set environment variable in response to a client call to wl_display_connect. This should be considered a bug. But this is what I referenced above as being mostly benign in a pure wayland client: it's stupid, but almost always harmless. But in a hybrid client, it's horrible ... and it's really the responsibility of the client to handle things better. It's quite simple really:

if (getenv("WAYLAND_DISPLAY"))
   wl_display = wl_display_connect(NULL);
else if (getenf("DISPLAY"))
   dpy = XOpenDisplay(NULL);
else /* emit a gtk/gnome-quality error message */
   fprintf(stderr, "Oh no! Something has gone wrong.");

However as annoying as GTK's approach to this is, the symptoms reported in post #9 seem to rule this out as a cause of the current problem. I'm a bit surprised really - and it might be good to get a bit more detail on the description of those symptoms: ewaller: can you describe that series of tests while indicating which terminal emulators you attempted to open at which stage is it's not clear in post #9. In fact, I don't believe we've yet heard which terminal emulator is being used.

ewaller wrote:

Edit: Trilby, you made my head explode. I can tell you have spent a lot more time in the weeds of display servers than have I.

I've been tinkering quite a bit with wayland. I have my own compositor I use, and more recently I've written a wayland client library (because writing wayland clients from scratch without a toolkit really really sucks, and AFAIK there were no other lightweight non-toolkit client libraries yet). I've also put together several client programs I'm using (background setter, status bar, pdf viewer, etc); and the biggest steps in learning have come from seeing how my own tools work, and fail to work together: the iterative patching of compositor/client-lib/client has been most informative, largely because being responsible for every bit of running and interacting code allows for very precise tests and explorations of symptoms. Of course this also prevents any deflection of blame. I get to blame my compositor code, my lib code, or my client code - no way am I getting off the hook

The first hurdle of getting into wayland is a cultural one of moving from reading RFCs to reading XML protocol specifications. This was jarring at first, but once I got over the fact that I was reading XML, the protocol specs are quite useful. (edit: I supposed I don't know that the ICCM or EWMH protocols were ever out as RFCs).

Last edited by Trilby (2022-03-29 13:25:10)

ewaller · 2022-04-02 18:07:45

Be advised I have not abandoned this thread. With Gnome 42 on the horizon I am holding off to see if anything changes.

progandy · 2022-04-02 19:05:17

Habe your tried to set "WAYLAND_DISPLAY=none" in your i3 session so wayland capable applications will fail to find the wayland socket and fall back to xorg?

ewaller · 2022-04-02 21:17:03

progandy wrote:

Habe your tried to set "WAYLAND_DISPLAY=none" in your i3 session so wayland capable applications will fail to find the wayland socket and fall back to xorg?

I just did, to no avail.
It looks like the problem is with i3-sensible-terminal. I can start a start urxvt or xterm from rofi. I have i3-sensible-terminal bound to $mod+Return.
From inside urxvt if I invoke i3-sensible-terminal nothing happens in i3, it opens Gnome-terminal in the Gnome session.

Edit: And changing ~/.i3/conf to bind that combo to urxvt seems works as expected.

Last edited by ewaller (2022-04-02 21:26:31)

progandy · 2022-04-02 21:29:18

i3-sensible-terminal prefers gnome-terminal over urxvt.. gnome-terminal may run a terminal server that handles all terminals and calling gnome-terminal simply forwards its parameters through dbus. Since all logind sessions for the same user share a dbus instance, that can happen.
Edit: Two sessions for the same user sharing dbus can cause other fun things with e.g. xdg desktop portals.

Last edited by progandy (2022-04-02 21:31:33)

ewaller · 2022-04-02 21:31:23

progandy wrote:

i3-sensible-terminal prefers gnome-terminal over urxvt..

That only seems sensible in a Gnome environment. To each their own.

Arch Linux

#1 2022-03-28 16:46:27

Interactions between Desktop Environments.

#2 2022-03-28 16:59:09

Re: Interactions between Desktop Environments.

#3 2022-03-28 19:35:57

Re: Interactions between Desktop Environments.

#4 2022-03-28 19:54:16

Re: Interactions between Desktop Environments.

#5 2022-03-28 20:01:56

Re: Interactions between Desktop Environments.

#6 2022-03-28 20:28:20

Re: Interactions between Desktop Environments.

#7 2022-03-28 21:01:43

Re: Interactions between Desktop Environments.

#8 2022-03-28 21:09:23

Re: Interactions between Desktop Environments.

#9 2022-03-28 23:22:23

Re: Interactions between Desktop Environments.

#10 2022-03-29 07:41:42

Re: Interactions between Desktop Environments.

#11 2022-03-29 13:09:49

Re: Interactions between Desktop Environments.

#12 2022-04-02 18:07:45

Re: Interactions between Desktop Environments.

#13 2022-04-02 19:05:17

Re: Interactions between Desktop Environments.

#14 2022-04-02 21:17:03

Re: Interactions between Desktop Environments.

#15 2022-04-02 21:29:18

Re: Interactions between Desktop Environments.

#16 2022-04-02 21:31:23

Re: Interactions between Desktop Environments.

Board footer