3

I want to solve a problem with Zoom's screen sharing (it conflicts with wayland and suggests using X). I can get Zoom to work, but the problem is that most but not all applications in the X session are opened on the wrong display.

Here's what I'm doing: I open a virtual console and start an X session with startx -- :1. The output of who is 

user    tty2         2020-04-15 06:44 (tty2)
user    tty3         2020-04-15 07:26
user    pts/4        2020-04-15 07:27 (:1)

$DISPLAY is :0 on tty2

I can now open certain applications (like xterm, Firefox, Zoom (screen sharing works!)) on :1 (either with DISPLAY=:1; firefox from :0 or directly from :1).

The problem is that most applications (like terminator, gedit) are opened automatically on tty2 with no error message. How can I fix this?

For the record:
I am using GNOME on Debian 10.
I ran DISPLAY=:1; xhost + but that didn't change anything.

I am using the ~/.xinitrc file from here (using gnome-session instead of x-window-manager did not make a difference)
Maybe relevant: There is a default /etc/X11/xinit/xinitrc which only calls /etc/X11/Xsession. Xsession itself doesn't seem to start a window manager. So without my ~/.xinitrc, startx jumps right back to the console.

EDIT:

Choosing "GNOME on Xorg" from gdm3's login screen remedies the situation. Thanks mosvy for the suggestion.

I also tried the suggestions from here. Running 

export $(dbus-launch)
gnome-terminal

did not change anything, but 

#! /bin/bash
ID=foo.bar$RANDOM
GDK_BACKEND=x11 /usr/libexec/gnome-terminal-server --app-id "$ID" &
sleep .4        # yuck
gnome-terminal --app-id "$ID"
wait

worked (gnome-terminal is opened on display :1), but I guess this solution cannot be applied to other apps.

ga325
  • 31
  • 3
  • Note: xhost + turns of security, nothing more. You should avoid its use. – ctrl-alt-delor Apr 15 '20 at 09:55
  • I think I see what you are saying, but the question lacks the clarity that it needs for me to make any suggestions. Please give some clear examples of what you did, and how it does not work. Don't describe them, show them. I typed .... and this happened. – ctrl-alt-delor Apr 15 '20 at 09:57
  • I think it's about the same thing as this. Try running export $(dbus-launch) in your xterm, then gedit and other gnome-stuff should work. –  Apr 15 '20 at 10:05
  • Notice that you can choose a "gnome on Xorg" session from gdm3's login screen. –  Apr 15 '20 at 10:06
  • @ctrl-alt-delor: thanks, I edited the question. Hope it is clearer now. – ga325 Apr 15 '20 at 21:47
  • @mosvy: thanks for the link. Unfortunately export $(dbus-launch) did not work; see my edit in the question. – ga325 Apr 15 '20 at 21:48
  • Try running the message bus as export DISPLAY=:1; export $(env - "LANG=$LANG" "DISPLAY=$DISPLAY" dbus-launch) before launching gedit or gnome-terminal. If that works, try with export DISPLAY=:1; export $(env -u XDG_RUNTIME_DIR dbus-launch) too. –  Apr 16 '20 at 01:27
  • But this is just out of technical interest; as I already said, you do NOT need to run a separate Xorg server; you can simply choose "GNOME on Xorg" from the menu opened by the gear icon in gdm3's login screen. Gdm3 will remember your choice. (and other display managers have similar options). –  Apr 16 '20 at 01:36
  • @mosvy: Logged in with GNOME on Xorg and everything works. Thank you so much. – ga325 Apr 16 '20 at 05:32
  • Related: Gnome applications over ssh open on the remote X session – Gilles 'SO- stop being evil' Mar 09 '21 at 23:09

0 Answers0