wayland --server start late

[21pages]

Issue

The --server process may be started late on Wayland after installation, taking approximately 25 seconds. If the main window is started before the server, the server's IPC, will be occupied by the main window, causing the server to restart repeatedly.

How to reproduce

1. Switch to Wayland on Ubuntu 22.04.
2. Install RustDesk and check if the --server process has started.

Clue

The issue is related to the code in the following links:

rustdesk/src/platform/linux.rs

Line 1091 in 82b730c

if self.is_login_wayland() {

rustdesk/src/platform/linux.rs

Line 648 in 82b730c

sleep_millis(300);

The desktop.refresh() function takes about 25 seconds to execute, with most of the time consumed by the sleep_millis(300) function, which is used to retrieve the environment variables DISPLAY and XAUTHORITY. These variables are unnecessary for Wayland. However, the is_login_wayland function is giving a false result.

Task

• Fix wayland --server start late
• Investigate if there is a more efficient approach for XFCE4_PANEL, SDDM_GREETER, and PLASMA_X11, which are always call sleep_millis(300)

[rustdesk]

@sahilyeole ask @21pages if you have any question.

[beelchester]

Hey @21pages, Thanks for the clue.

How about instead of if self.is_login_wayland() { we simply use if self.is_wayland() { ?

I tried it and now those unnecessary get_env_tries() calls are avoided.
The --server process starts immediately after installation and it also doesn't repeatedly restart as earlier.
Earlier, there were similar delays and restarting issues after starting the --service process separately too, and now it is also fixed.
Rest everything is working the same.

Implementation of is_wayland():

rustdesk/src/platform/linux.rs

Lines 907 to 909 in 32a32e4

	pub fn is_wayland(&self) -> bool {
	self.protocal == DISPLAY_SERVER_WAYLAND
	}

[21pages]

simply use if self.is_wayland()

After consulting with @fufesou, I learned that the purpose of is_login_wayland is to determine whether the current screen is the login screen(username=gdm) and if it is using wayland, and wayland login screen cannot be captured. Slow startup may only occur during installation.

[beelchester]

login screen(username=gdm)

Yes, I noticed that on running loginctl :)

---

Slow startup may only occur during installation.

Actually, I noticed that in this case also:

similar delays and restarting issues after starting the --service process separately too

---

So like you said:

environment variables DISPLAY and XAUTHORITY. These variables are unnecessary for Wayland.

by using is_wayland() we can avoid these calls on all wayland scenarios (including login screen).
As per my testing on ubuntu wayland everything is working as it is and --server is starting immediately.
X11 remains unaffected.
So should I proceed with this?

[fufesou]

If you use if self.is_wayland() instead of if self.is_login_wayland(). The following three lines will not be reached.

The following lines are used to set display, xauth and xorg subprocess.

These variables will not affect normal control. But it will break the headless control #3902.

            if self.is_login_wayland() {
                self.display = "".to_owned();
                self.xauth = "".to_owned();
                self.is_rustdesk_subprocess = false;
                return;
            }

            self.get_display();
            self.get_xauth();
            self.set_is_subprocess();

[beelchester]

Oh, got it.
We have:

rustdesk/src/platform/linux.rs

Lines 917 to 919 in 5837026

	pub fn is_headless(&self) -> bool {
	self.sid.is_empty() || self.is_rustdesk_subprocess
	}

So how about this?
if self.is_wayland() && !self.is_headless()

[fufesou]

That's not the same. If "not headless" or "login wayland", no need to run the following lines.

But is_rustdesk_subprocess is set in set_is_subprocess, you cannot use is_rustdesk_subprocess to check if should do set_is_subprocess.

I can't understand why get_env_tries("DISPLAY", &self.uid, diplay_env, 10); and get_env_tries("XAUTHORITY", &self.uid, diplay_env, 10); run 10 times.

Maybe it's better to find the reason and fix it.

[rustdesk]

@sahilyeole update？This super simple task should not take long.

[beelchester]

Yes, I got stuck at setting up headless wayland for testing.
But I checked a few x11 environments

I can't understand why get_env_tries("DISPLAY", &self.uid, diplay_env, 10); and get_env_tries("XAUTHORITY", &self.uid, diplay_env, 10); run 10 times.

@fufesou In my case in x11 env was always working in first try itself. But on wayland it takes full 10 runs (as these variables are not there). So I don't think reducing env tries to like 3 would cause any problem (not checked headless yet tho).

These env tries are not only slowing down on wayland but also on x11 login screen #5276 (comment)

---

For skipping these tries on wayland part:
@fufesou as per this, is self.sid.is_empty() always true for headless?

rustdesk/src/platform/linux.rs

Lines 917 to 919 in 5837026

	pub fn is_headless(&self) -> bool {
	self.sid.is_empty() || self.is_rustdesk_subprocess
	}

If so, How about this?

if self.is_wayland() && !self.sid.is_empty() {
    self.display = "".to_owned();
    self.xauth = "".to_owned();
    self.is_rustdesk_subprocess = false;
    return;
}

[rustdesk]

headless again, a no-people-use feature causes so much trouble.

[fufesou]

@sahilyeole You can use is_wayland() to replace is_login_wayland(). Sorry for my previous wrong answer.

is_wayland() also includes user wayland, which means at least one monitor is attached. No need to test variables for headless anymore.

[beelchester]

Alright, thanks 👍

[rustdesk]

The --server process may be started late on Wayland after installation, taking approximately 25 seconds. If the main window is started before the server, the server's IPC, will be occupied by the main window, causing the server to restart repeatedly.

Why do not we spawn a --server process to pre-occupy the ipc?