Wayland cursor capture

[rustdesk]

rustdesk/src/platform/linux.rs

Line 113 in 309cb10

pub fn get_cursor() -> ResultType<Option<u64>> {

this works on X11 only, wayland implementation not done yet.

[rustdesk]

Any idea / proposal about this? @sahilyeole

[beelchester]

I'm working on it. I will update you soon.

[beelchester]

Has this crate been tried before?
wayland_cursor (along with wayland_client for Connection and WlShm)

If not, I think it might help us. However, I have not tested it yet (I'm still figuring out how to get WlShm for it).
But what do you think, should I go ahead and try to implement it?

[rustdesk]

I checked before, It more likely load a cursor image and show it, rather than capture current cursor.

[beelchester]

Ah, ok. I need to dig more.

[rustdesk]

Check if chrome / qt etc has some implementation.

[beelchester]

Here's my understanding till now (I may be wrong though):

• Wayland seems to be very restricting than x11. I could not find any global access to the cursor/pointer data for wayland yet.
• Wayland protocol provides pointer data and methods only if it's within the surface specified by the application, not outside of it. I saw multiple implementations on github using a similar concept.
• However, for our use case, we require global cursor data regardless of the pointer's position.

I'm still working on it, let's see if I can find anything meaningful soon.

[beelchester]

libsdl-org/SDL#7693
I'm not sure if something like this will help us or not.

Wayland doesn't support getting the true global cursor position, but it can be faked

this gives 'correct' coordinates when a window has focus, which is good enough for most applications.

[rustdesk]

Progress?

[rustdesk]

Another "stupid" way (not sure if it is feasible, or may be inefficient) is, we know we can get the cursor position, we know we can capture part of the screen with cursor and without cursor, so we can extract the cursor from the difference of the two picture.

[rustdesk]

Be clever! Young man, :).

[beelchester]

Ah, interesting. Can try thanks!

[rustdesk]

Let's try composor first.

[beelchester]

Ok

[beelchester]

Pipewire's metadata seems to be the answer.
https://docs.pipewire.org/structspa__meta__cursor.html

obs has its implementation. Figuring out how we can implement it as well.

[rustdesk]

@fufesou what is the problem of obs implementation? we tried out before, and then paused.

[fufesou]

obs can grab the cursor.
But the implementation is a little complicated.
It implements the cursor transfer of the stream pipewire. And it depends on some low lever OPENGL APIs.

[beelchester]

How does capture_cursor & cursor_mode implementation work here?

rustdesk/libs/scrap/src/wayland/pipewire.rs

Line 607 in f305c9d

pub fn get_capturables(capture_cursor: bool) -> Result<Vec<PipeWireCapturable>, Box<dyn Error>> {

[rustdesk]

cursor_mode has nothing to do with standalone cursor capture.

[rustdesk]

I mentioned cursor_mode last time.

we know we can capture part of the screen with cursor and without cursor, so we can extract the cursor from the difference of the two picture.

[beelchester]

Hi @fufesou,
If you recall, could you please give some insights on this and why it was disabled later (cursor embed)?
#2360
#3718

Also, did you previously attempt to set the cursor mode value to 4 and extract cursor metadata from the stream?
(According to https://flatpak.github.io/xdg-desktop-portal/#gdbus-property-org-freedesktop-portal-ScreenCast.AvailableCursorModes)
As you have commented this:

rustdesk/libs/scrap/src/wayland/pipewire.rs

Line 495 in d688e34

// cursor_mode = PORTAL_CURSOR_MODE_METADATA & available_cursor_modes;

[fufesou]

The embedded cursor will cause a large delay in the operation experience.

It is able to set the cursor mode value to 4. And the obs use this cursor mode.
But the gstreamer crate ( https://crates.io/crates/gstreamer ) does not support the cursor data transfer.
You have to implement the cursor data transfer by yourself if you want to use the cursor mode 4.

[beelchester]

Oh, ok. Thanks.

[beelchester]

@fufesou Sorry for interrupting you again, but do I need to completely rewrite our wayland screen capture into low-level pipewire code, something similar to obs?

With our current implementation, I could not find any way to directly access the pipewire stream or buffer, which would allow us to utilize pipewire api methods on it.
Also, I'm not sure if it's possible to specifically transfer only the cursor metadata, it might require complete rewriting.

Unfortunately, obs approach is the only good solution I could find for capturing the cursor :(

[fufesou]

Ok. You may want to refer to these source code

https://github.com/PipeWire/pipewire
https://github.com/GStreamer/gstreamer
https://gitlab.freedesktop.org/gstreamer/gstreamer-rs

[beelchester]

Ok, Thank you so much.

[beelchester]

@fufesou Are you aware of or have any clue about these wayland behaviours?

1. Sometimes the cursor image is shown on ubuntu wayland instead of a blue circle. It doesn't seem to be embedded because it's roughly only 70% of the time correct as the actual cursor image on wayland side.

2. Input works on the official release but on cargo run it doesn't work (keyboard, mouse both). It worked once or twice but not after that. The official release which was earlier working also stops taking input. Reinstalling rustdesk didn't work had to reinstall ubuntu and then again after cargo run same behaviour occurred :(

Also, when 2 happens the cursor image is always shown.

[fufesou]

For 1, it's a long time that I haven't changed the wayland cursor. I briefly looked at the code, but I couldn't find where to handle the wayland cursor.

For 2, you need to run --service as the root process and --server as the user process to make the input working.
Uinput can only be handled in the root priviledge. The wayland screen capturing should be in the user process.

[beelchester]

Alright, working. Thanks for the help :)

I'll look something up for 1 later. Maybe just improving its implementation can make wayland cursor capture work well and consistently.

[FurtadoPires]

Sorry I'm not a dev, but I think this might be interesting for you guys

https://github.com/flatpak/xdg-desktop-portal/releases/tag/1.18.0

Highlights

A new config-based portal matching mechanism that gives more precise control over which portal backends are picked for each portal.
New portals: Clipboard and Input Capture
The settings portal now documents an 'accent-color' key

[beelchester]

Hey, Thanks for sharing.
But it's about input capturing, we already have that in wayland.
We are interested in capturing the cursor metadata i.e. size and image of the cursor.

[beelchester]

Sometimes the cursor image is shown on ubuntu wayland instead of a blue circle.
Maybe just improving its implementation can make wayland cursor capture work well and consistently.

The cursor capture is already working because XFixesGetCursorImage is available in wayland due to Xwayland. Checked on ubuntu wayland.

rustdesk/src/platform/linux.rs

Line 119 in 230eb76

let img = XFixesGetCursorImage(*d);

But, the cursor capture fails sometimes (showing blue circle instead). So, I'm debugging that.

[beelchester]

Thanks, @fufesou.
That's exactly what I needed.
Earlier, I was trying the build before #5809. The --server was starting late that's why if I made the connection before --server the cursor was captured.
But now I tried the latest build, cursor capture is not working because --server is starting very quickly.
Thanks, for pointing that out :)

[rustdesk]

update?

[beelchester]

I was working on #5853, I will get back on this soon.

[beelchester]

inner server thread in the rustdesk ui

@fufesou can you please link me to the part of the code responsible for inner server thread?
Sorry to disturb but I'm not able to find it.

---

Till now I tried reinitializing DISPLAY variable, and restarting --server when DISPLAY is null, i.e. connection to XOpenDisplay is null

rustdesk/src/platform/linux.rs

Line 36 in 3e61b89

static DISPLAY: RefCell<*mut c_void> = RefCell::new(unsafe { XOpenDisplay(std::ptr::null())});

But it is giving null all the time. It is only working in the inner server thread scenario, when --server has yet to start.

[fufesou]

Server thread

The inner thread is started in this function

rustdesk/src/core_main.rs

Line 164 in 3e61b89

std::thread::spawn(move || crate::start_server(false));

---

Server process

For wayland, the "--server" subprocess is started here

rustdesk/src/platform/linux.rs

Line 387 in 3e61b89

start_server(

For X11, the "--server" subprocess is started here

rustdesk/src/platform/linux.rs

Line 370 in 3e61b89

start_server(None, &mut server);

[fufesou]

The wayland clipboard on the controlled side also do not work if --server is started inappropriately.

#5900

[beelchester]

Does wayland clipboard require root permission?

[fufesou]

No, the --server is always the user permission on Wayland.

[rustdesk]

Update:
working on the wayland cursor, today I spent many hours debugging the issue. The connection/pointer to xopendisplay is important in order to draw cursor.
I tried making this connection in multiple scenarios such as root --server, start with --service, etc but didn't work.. but one thing I'm clear now is that it's only not null in the inner UI server code and then it is overridden by --server in which connection is null irrespective of root or user.
It's taking time but I'm giving it my best and I think I'm getting closer to the solution.

Are you sure you are doing in the correct way? Since you mentioned it worked before #5809.

[rustdesk]

Even before #5809 if I wait and let --server start then the cursor capture fails.

Any clue about this?

[beelchester]

I think mainly --server is causing it.
So, this:

connection/pointer to xopendisplay
it's only not null in the inner UI server code and then it is overridden by --server in which connection is null irrespective of root or user.

---

I tried making some changes to --server which is causing it to crash and restart repeatedly and the cursor capture is working, when --server isn't working. So, most likely improving the --server configuration for wayland will fix it (trying to figure out this part).

wl_cursor.mp4

[rustdesk]

Let's see the code.

[beelchester]

Um, If you are asking about what changes I did here:

I tried making some changes to --server which is causing it to crash and restart repeatedly and the cursor capture is working, when --server isn't working.

I only changed

rustdesk/src/platform/linux.rs

Lines 377 to 391 in 3e61b89

	if should_start_server(
	false,
	&mut uid,
	&desktop,
	&mut cm0,
	&mut last_restart,
	&mut user_server,
	) {
	stop_subprocess();
	force_stop_server();
	start_server(
	Some((desktop.uid.clone(), desktop.username.clone())),
	&mut user_server,
	);
	}

to

          if should_start_server(
                false,
                &mut uid,
                &desktop,
                &mut cm0,
                &mut last_restart,
                &mut server,
            ) {
                stop_subprocess();
                force_stop_server();
                start_server(
                    None, 
                    &mut server,
                );
            }

Now, it is trying to start --server as root but it constantly crashes and restarts. Seems like --server can't be started as root in wayland.

---

But even on --server as root, I think the connection still can't be made.
I have added some custom logs in these places for testing:

rustdesk/src/server.rs

Line 359 in a723518

pub async fn start_server(is_server: bool) {

(dummy connection)

thread_local! { 
    static DISPLAY: RefCell<*mut c_void> = RefCell::new(unsafe { XOpenDisplay(std::ptr::null())});
    }
#[cfg(not(any(target_os = "android", target_os = "ios")))]
#[tokio::main]
pub async fn start_server(is_server: bool) {
    DISPLAY.with(|conn| {
        if let Ok(d) = conn.try_borrow_mut() {
            if !d.is_null() {
            write_log(format!("not null, is server: {}", is_server).as_str());
            }
            else {
                write_log(format!("null, is server: {}", is_server).as_str());
            }
        }
    });

rustdesk/src/core_main.rs

Line 249 in a723518

crate::start_server(true);

write_log(format!("start --server with user {}", crate::username()).as_str());
crate::start_server(true);

And

rustdesk/src/core_main.rs

Line 164 in a723518

std::thread::spawn(move || crate::start_server(false));

write_log("inner server done");
std::thread::spawn(move || crate::start_server(false));

Output:

So, according to this the connection is not null only in inner server code and null when --server starts (user or root both)

---

x11 output:

[beelchester]

Wayland's --server is using run_as_user() to start --server and the connection is failing. So I tried running x11's --server too using run_as_user() but it didn't fail, connection and cursor capture is still working.
At this point I'm doubting this:

most likely improving the --server configuration for wayland will fix it

[beelchester]

I'm not sure if this solution is acceptable, but I can compile and run a c code separately which will handle the XOpenDisplay connection and XFixesGetCursorImage and then give its output to get_cursor() and get_cursor_data() for cursor capturing.

Below is the working c code for printing the latest cursor serial on loop (tested on wayland), I can use its output for get_cursor() and I can also try to modify it for get_cursor_data():

#include <stdio.h>
#include <stdlib.h>
#include <X11/Xlib.h>
#include <X11/extensions/Xfixes.h>
#include <unistd.h>

int main() {
    Display *display = XOpenDisplay(NULL);
    if (!display) {
        fprintf(stderr, "Failed to open X display\n");
        return 1;
    }
    long previous_serial = -1;
    while (1) {
        XFixesCursorImage *img = XFixesGetCursorImage(display);
        if (img) {
            if (img->cursor_serial != previous_serial) {
                printf("Cursor serial: %ld\n", img->cursor_serial);
                previous_serial = img->cursor_serial;
            }
            XFree(img);
        } else {
            fprintf(stderr, "Failed to get cursor image\n");
        }
        sleep(0.5); 
    }
    XCloseDisplay(display);
    return 0;
}

Let me know if it's acceptable or not.

[fufesou]

I think you need to find out how to capture the cursor on Wayland, run as user, not run it directly.

[rustdesk]

@fufesou take over this issue, @sahilyeole is not capable of this issue. This is high priority since I plan to release this in 1.2.3.