Wayland issues: Green lines on scaled screen + no input (SELinux, Fedora) #6116

manueldeprada · 2023-10-20T10:58:06Z

Bug Description

This was tested on both 1.2.3 and October 19th nightly, on Fedora 38 GNOME with Intel graphics.

Xorg version works flawlessly.

On Wayland:

If I have a 125% screen scaling in Settings -> Screen, the connection via Rustdesk is completely distorted with the green lines you can see in the screenshot. I have tried different codecs and forcing software rendering, with same result.
If I set back the scaling to 100%, the image is fine. However, I cannot control the mouse from the remote device. I have tried doing the "sudo rustdesk --service" as README indicates, but the terminal blinks indefinitely without launching the server.

Thanks for the great product! I hope wayland support improves soon :)

How to Reproduce

Just download rustdesk on Fedora GNOME wayland session and try to log in.

Expected Behavior

Clear image and working mouse control.

Operating system(s) on local side and remote side

Fedora 38

RustDesk Version(s) on local side and remote side

1.2.3 tested, 19-10 nightly also tested

Screenshots

Additional Context

No response

rustdesk · 2023-10-20T11:01:23Z

2. If I set back the scaling to 100%, the image is fine. However, I cannot control the mouse from the remote device. I have tried doing the "sudo rustdesk --service" as README indicates, but the terminal blinks indefinitely without launching the server.

Please run the rpm package.

rustdesk · 2023-10-20T11:04:00Z

I will remove "sudo rustdesk --service" in README

rustdesk · 2023-10-20T11:09:56Z

If I have a 125% screen scaling in Settings -> Screen, the connection via Rustdesk is completely distorted with the green lines you can see in the screenshot. I have tried different codecs and forcing software rendering, with same result.

@sahilyeole please confirm on Fedora GNOME Wayland

manueldeprada · 2023-10-20T11:25:12Z

If I set back the scaling to 100%, the image is fine. However, I cannot control the mouse from the remote device. I have tried doing the "sudo rustdesk --service" as README indicates, but the terminal blinks indefinitely without launching the server.

Please run the rpm package.

I have been playing around with this the last hour and these are my obervations:

For me, if I don't run the service with sudo, it will not allow me to control the input from the remote.
It is not easy to correctly start the service with sudo. I think there may be multiple processes interfering with each other. The only way I have found to to reliably start the service is to do "sudo pkill rustdesk; sudo rustdesk --service; [open new tab] rustdesk"
Running the rpm package (without sudo service...) always leads to correct display rendering BUT no input capture, does not matter if I start the app from GNOME or from terminal.
Starting/restarting the service is very confusing. The app usually works, but interacts weirdly with the "sudo rustdesk --service". I think I got a few times both services running (the one started from the app + the one from "sudo rustdesk --service) leading to disconnects every few seconds when connecting from remote. I think something like a lock file adquired by the first service running would be desirable.
Also, systemctl does not seem to work to control the service. Again, confusing, it would be great if that was clear in the README.
Finally, the rustdesk icon does not consistenly show up as a tray icon. I think it showed up in <30% of all my tests, I could not say exactly what I was doing when it showed up.

I hope my experice helps figuring out this issues! Let me know if I can do any useful test for you.

rustdesk · 2023-10-20T11:28:27Z

I have been playing around with this the last hour and these are my obervations:

I forgot to mention input issue on fedora wayland is caused by SELinux. @fufesou is preparing a doc for this.

manueldeprada · 2023-10-20T11:42:42Z

I have been playing around with this the last hour and these are my obervations:

I forgot to mention input issue on fedora wayland is caused by SELinux. @fufesou is preparing a doc for this.

True! I extracted a SELinux module with audit2allow and now it works perfecly!

I guess the document is to guide users to create and install the SELinux module. Did you consider including this in the installation process so it is transparent for users?

rustdesk · 2023-10-20T11:51:16Z

Did you consider including this in the installation process so it is transparent for users?

If this requires modify anything on your system regarding security, we will not do it. We can not afford the risk.

rustdesk · 2023-10-20T11:53:18Z

True! I extracted a SELinux module with audit2allow and now it works perfecly!

What exactly have you done? can you paste full commands here? We will evaluate if we can add in rpm postinstall.

manueldeprada · 2023-10-20T12:21:20Z

Did you consider including this in the installation process so it is transparent for users?

If this requires modify anything on your system regarding security, we will not do it. We can not afford the risk.

You can include an open source SELinux module that only grants access to the input device. That is transparent enough, I think, and it is the way SELinux is meant to be used: granular, explicit and loggeable permissions.

True! I extracted a SELinux module with audit2allow and now it works perfecly!

What exactly have you done? can you paste full commands here? We will evaluate if we can add in rpm postinstall.

First, I looked into /var/log/audit logs and I saw these denials related to rustdesk:

type=AVC msg=audit(1697801611.416:6367): avc:  denied  { open } for  pid=367604 comm="rustdesk" path="/dev/uinput" dev="devtmpfs" ino=638 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0
type=AVC msg=audit(1697801611.495:6368): avc:  denied  { execute } for  pid=367919 comm="rustdesk" name="sudo" dev="nvme0n1p4" ino=7783378 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file permissive=0

As you can see, it gets denied a sudo command to access a file, and an open command to to /dev/uinput. Maybe with granting access to the later one is enough, since I dont care, I just used the audit2allow utility to turn denial logs into SELinux modules that allow those commands:

semodule -i my_rustdesk.pp

That is all I did. The pp file I think is the compiled module and source is in the .te file, that you should customize for the installer. For me, it created the following .te file:

module my_rustdesk 1.0;

require {
	type unreserved_port_t;
	type unconfined_dbusd_t;
	type user_tmp_t;
	type session_dbusd_tmp_t;
	type event_device_t;
	type sudo_exec_t;
	type init_t;
	class file { execute execute_no_trans open read };
	class chr_file open;
	class sock_file write;
	class unix_stream_socket connectto;
	class tcp_socket name_connect;
}

#============= init_t ==============
allow init_t event_device_t:chr_file open;
allow init_t session_dbusd_tmp_t:sock_file write;
allow init_t sudo_exec_t:file { execute execute_no_trans open read };
allow init_t unconfined_dbusd_t:unix_stream_socket connectto;

#!!!! This avc can be allowed using the boolean 'nis_enabled'
allow init_t unreserved_port_t:tcp_socket name_connect;
allow init_t user_tmp_t:file open;

For comparison, if we want to only allow the open command, this is what I get:

❯ echo "type=AVC msg=audit(1697801611.416:6367): avc:  denied  { open } for  pid=367604 comm="rustdesk" path="/dev/uinput" dev="devtmpfs" ino=638 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:event_device_t:s0 tclass=chr_file permissive=0" | audit2allow -M rustdesk2
******************** IMPORTANTE **********************
Para activar este paquete de políticas, ejecute:

semodule -i rustdesk2.pp

❯ cat rustdesk2.te

module rustdesk2 1.0;

require {
	type event_device_t;
	type init_t;
	class chr_file open;
}

#============= init_t ==============

#!!!! This avc is allowed in the current policy
allow init_t event_device_t:chr_file open;

Looking in the documentation for .te files you should be able to manually craft a tailor made selinux module for the app needs, I think.

fufesou · 2023-10-20T12:26:39Z

@manueldeprada Thanks for your kind feedback.

But maybe it's not a good way to allow init_t some rules.

allow init_t event_device_t:chr_file open;
allow init_t session_dbusd_tmp_t:sock_file write;
allow init_t sudo_exec_t:file { execute execute_no_trans open read };
allow init_t unconfined_dbusd_t:unix_stream_socket connectto;

By adding the rules, the other services (default int_t domain) are allowed of the specified permissions.

sahilyeole · 2023-10-20T13:57:27Z

If I have a 125% screen scaling in Settings -> Screen, the connection via Rustdesk is completely distorted with the green lines you can see in the screenshot. I have tried different codecs and forcing software rendering, with same result.

@sahilyeole please confirm on Fedora GNOME Wayland

Not an issue on default scaling options (100,200,300,400).

But after doing

gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"

It unlocked the experimental feature of fractional scaling, now all the scale options (125,150,175,200,etc) except for 100 is causing this issue.

Conclusion: This is not an issue with default scaling options but only an issue after enabling the fractional scaling feature (which is experimental in gnome mutter).

Fractional scaling in GNOME is considered an experimental feature – there’s a reason it’s not available by default! Unlike Ubuntu (and distros based on it), the configuration of GNOME in Fedora lacks some out-of-branch optimizations that allow fractional scaling to function well.

Source

rustdesk · 2023-10-20T13:59:19Z

@sahilyeole Good job.

manueldeprada · 2023-10-20T16:09:10Z

By adding the rules, the other services (default int_t domain) are allowed of the specified permissions.

True. I did some research and it is possible to create a selinux policy that specifically only allows the rustdesk process to access the /dev/uinput. That should be the way forward, but it requires crafting a full policy and it requires some time that I don't have this week.

As a temporal hack, I have checked and the "exec sudo" permission is not needed. This is my minimal non-custom working policy right now:

module rustdesk_file 1.0;

require {
	type event_device_t;
	type init_t;
	class chr_file open;
}


allow init_t event_device_t:chr_file open;

It can be run with

 6210  checkmodule -M -m -o rustdesk_file.mod rustdesk_file.te
 6211  semodule_package -o rustdesk_file.pp -m rustdesk_file.mod
 6212  sudo semodule -i rustdesk_file.pp

manueldeprada · 2023-10-20T16:18:54Z

Conclusion: This is not an issue with default scaling options but only an issue after enabling the fractional scaling feature (which is experimental in gnome mutter).

Fractional scaling in GNOME is considered an experimental feature – there’s a reason it’s not available by default! Unlike Ubuntu (and distros based on it), the configuration of GNOME in Fedora lacks some out-of-branch optimizations that allow fractional scaling to function well.

True too! I forgot I had to enable that. However, GNOME is planning to enable fractional scaling by default, and I bet everyone with a HighDPI laptop has done it.

I have not had any problem sharing my screen with firefox, that also uses pipewire, neither with TeamViewer, Zoom or other apps, so even if it is marked as an experimental feature, I would argue that it is widely used and quite stable.

I don't have the experience to tweak into the capturing code, but I do hope to see a fix for this! it seems like the framebuffer dimensions are messed up, please let me know if I can help with any tests!! This might be helpful

rustdesk · 2023-10-20T16:21:00Z

@manueldeprada Thanks
@sahilyeole please continue working on this display issue.

fufesou · 2023-10-21T05:42:18Z

@manueldeprada Hi, maybe your selinux policies is not enough for the rustdesk service.

Here's my rustdesk.te:

module rustdesk 1.0;

require {
        type event_device_t;
        type xserver_t;
        type xserver_port_t;
        type sudo_exec_t;
        type init_t;
        type ephemeral_port_t;
        type user_tmp_t;
        type user_fonts_cache_t;
        type pulseaudio_home_t;
        type session_dbusd_tmp_t;
        type unconfined_dbusd_t;
        class process execmem;
        class file { open read create write execute execute_no_trans map setattr lock link unlink };
        class unix_stream_socket connectto;
        class tcp_socket name_connect;
        class dir { add_name remove_name };
        class sock_file write;
        class chr_file { open read write } ;
}

#============= init_t ==============
allow init_t xserver_t:unix_stream_socket connectto;
allow init_t sudo_exec_t:file { open read execute execute_no_trans };
allow init_t user_tmp_t:file { open write setattr };
allow init_t self:process execmem;
allow init_t user_fonts_cache_t:dir { add_name remove_name };
allow init_t user_fonts_cache_t:file { read write create open link lock unlink };
allow init_t xserver_port_t:tcp_socket name_connect;
allow init_t pulseaudio_home_t:file { read write open lock };
allow init_t session_dbusd_tmp_t:sock_file write;
allow init_t unconfined_dbusd_t:unix_stream_socket connectto;

#!!!! This avc can be allowed using the boolean 'nis_enabled'
allow init_t ephemeral_port_t:tcp_socket name_connect;

#!!!! This avc can be allowed using the boolean 'domain_can_mmap_files'
allow init_t sudo_exec_t:file map;


#============= init_t wayland ==============
allow init_t event_device_t:chr_file { open read write };

#!!!! This avc can be allowed using the boolean 'domain_can_mmap_files'
allow init_t user_tmp_t:file map;

You can apply it by running

checkmodule -M -m -o rustdesk.mod rustdesk.te && semodule_package -o rustdesk.pp -m rustdesk.mod && sudo semodule -i rustdesk.pp

Why your rules work

You can test with the very few rules is because you've start a RustDesk client interface.

The manually started RustDesk client interface may have a inner server.
And the manually started process is of a lot of permissions.

So the /var/log/audit/audit.log will not record the denies.

To verify, you can try restart your PC, just login and do nothing more, and then try connect to the peer.

Warnings

And agian, the rules allow init_t to many permissions.

Try a new domain for RustDesk service if possible.

fufesou · 2023-10-21T15:43:17Z

https://rustdesk.com/docs/en/client/linux/selinux/

sahilyeole · 2023-11-12T00:36:23Z

please let me know if I can help with any tests!!

@manueldeprada can you please try to run this snippet with fractional scaling of 125% on?
https://gitlab.gnome.org/-/snippets/19

Based on this.

If any window doesn't open on running this script. Please modify this line (68) in the script:

- pipeline = Gst.parse_launch('pipewiresrc fd=%d path=%u ! videoconvert ! xvimagesink'%(fd, node_id))
+ pipeline = Gst.parse_launch('pipewiresrc fd=%d path=%u ! videoconvert ! autovideosink'%(fd, node_id))

The opened window will show you a video stream of your display, if it is not distorted like in rustdesk then let me know. This script uses gstreamer like rustdesk for screencasting, I will try to update our code likewise if this script works for you.
This script is working well for me but just confirming :)

HatWearingMann · 2023-11-15T05:37:32Z

Same "no input" issue here, on Fedora/Fedora.

manueldeprada · 2023-11-15T12:58:14Z

please let me know if I can help with any tests!!

@manueldeprada can you please try to run this snippet with fractional scaling of 125% on? https://gitlab.gnome.org/-/snippets/19

Based on this.

If any window doesn't open on running this script. Please modify this line (68) in the script:
- pipeline = Gst.parse_launch('pipewiresrc fd=%d path=%u ! videoconvert ! xvimagesink'%(fd, node_id))
+ pipeline = Gst.parse_launch('pipewiresrc fd=%d path=%u ! videoconvert ! autovideosink'%(fd, node_id))
The opened window will show you a video stream of your display, if it is not distorted like in rustdesk then let me know. This script uses gstreamer like rustdesk for screencasting, I will try to update our code likewise if this script works for you. This script is working well for me but just confirming :)

Sorry for the late reply, it has been a busy week. I tested both alternatives for line 68 and both work fine. I can see a clear picture in the window, no green lines, with either versions of the script.

Rustdesk continues to display green lines distortion.

Thanks for your work! Hope it helps!

manueldeprada · 2023-11-15T12:59:04Z

Same "no input" issue here, on Fedora/Fedora.

You need to either follow the guide to add the SELinux policy or launch Rustdesk with sudo rustdesk --service

sahilyeole · 2023-11-15T13:20:39Z

Sorry for the late reply, it has been a busy week. I tested both alternatives for line 68 and both work fine. I can see a clear picture in the window, no green lines, with either versions of the script.

Thanks, I've debugged the issue.
The pipewire stream is resulting in wrong display resolution (size) when fractional scaling is on. It is required by scrap.
I'm trying to fix it by getting a correct resolution with a different method, but even xrandr is resulting in the same incorrect resolution when fractional scaling is on. I suspect it's an issue in gnome's backend.
I'll continue finding a solution.

Meanwhile, can you please confirm this part by executing xrandr? @manueldeprada

xrandr is resulting incorrect resolution when fractional scaling is on

manueldeprada · 2023-11-15T13:42:03Z

Sorry for the late reply, it has been a busy week. I tested both alternatives for line 68 and both work fine. I can see a clear picture in the window, no green lines, with either versions of the script.

Thanks, I've debugged the issue. The pipewire stream is resulting in wrong display resolution (size) when fractional scaling is on. It is required by scrap. I'm trying to fix it by getting a correct resolution with a different method, but even xrandr is resulting in the same incorrect resolution when fractional scaling is on. I suspect it's an issue in gnome's backend. I'll continue finding a solution.

Meanwhile, can you please confirm this part by executing xrandr? @manueldeprada

xrandr is resulting incorrect resolution when fractional scaling is on
You are right:

This is the output of xrandr whith fractional scaling OFF:

Screen 0: minimum 16 x 16, current 5120 x 1600, maximum 32767 x 32767
eDP-1 connected 2560x1600+2560+0 (normal left inverted right x axis y axis) 370mm x 230mm
   2560x1600     59.99*+

With fractional scaling at 125%:

Screen 0: minimum 16 x 16, current 4608 x 1440, maximum 32767 x 32767
eDP-1 connected 2048x1280+2560+0 (normal left inverted right x axis y axis) 370mm x 230mm
   2048x1280     59.96*+

If you come up with other method that I can test for getting the resolution, please say so. In GNOME settings, it is correct.

manueldeprada · 2023-11-15T13:45:56Z

@sahilyeole I did a quick check and reading directly on cat /sys/class/drm/card1-eDP-1/modes reports the correct resolution

sahilyeole · 2023-11-15T15:07:06Z

@sahilyeole I did a quick check and reading directly on cat /sys/class/drm/card1-eDP-1/modes reports the correct resolution

Thanks, but we need to ensure the correct resolution of the currently shared display. In the case of multi-monitors, it might not work.

I tested kde's fractional calling on wayland, they support it officially. Rustdesk stream is working & xrandr too.

I'm sorry but I don't think we should disturb our current working code as it is an issue on gnome's side that too on an experimental feature. Also, there's no good workaround to get the correct resolution.

I'd suggest reporting it on gnome's git, they may get it fixed in their official support for fractional scaling.

If you can't wait for gnome to fix it then let me know. I can provide a separate custom build that will include the hardcoded value of your display resolution (of the monitor you want to screencast), this build will fix the issue but only for your resolution.

manueldeprada · 2023-11-19T02:33:57Z

Thanks, but we need to ensure the correct resolution of the currently shared display. In the case of multi-monitors, it might not work.
I'm sorry but I don't think we should disturb our current working code as it is an issue on gnome's side that too on an experimental feature. Also, there's no good workaround to get the correct resolution.

I'd suggest reporting it on gnome's git, they may get it fixed in their official support for fractional scaling.

If you can't wait for gnome to fix it then let me know. I can provide a separate custom build that will include the hardcoded value of your display resolution (of the monitor you want to screencast), this build will fix the issue but only for your resolution.

Thanks for your hard work @sahilyeole !! In seemed strange to me that this is a bug, since GNOME is really pushing forward the Wayland initiative, and they have also been lately working hard on the gaming-on-Linux resolution problems. I have dug deep into this issue and these are my latest findings:

Turns out, this is not a mutter (GNOME) issue! They are doing the correct implementation.

First, some context for everyone reading. The stream size that Rustdesk gets is returned by the pipewire screen sharing, DBus interface. We can see it in the Python script that you provided earlier:

def on_start_response(response, results):
    print("streams:")
    for (node_id, stream_properties) in results['streams']:
        print("stream {}".format(node_id))
        print("  properties:")
        for (key, value) in stream_properties.items():
            print("    %s: %s"%(key, value))
        play_pipewire_stream(node_id)

This returns the following:

stream 91
  properties:
    id: 0
    source_type: 1
    position: dbus.Struct((dbus.Int32(0), dbus.Int32(0)), signature=None, variant_level=1)
    size: dbus.Struct((dbus.Int32(2048), dbus.Int32(1280)), signature=None, variant_level=1)

My true resolution is 2560x1600, so this is the wrong size. This is the same API call that the Rust implementation by @H-M-H does, and hence it is the source of all our problems.
Now the next question is, is this GNOME's fault?

The answer can be found on the xdg-desktop-portal documentation, where it states what should be that size property, irrespective of GNOME or KDE backends:

size (ii)
A tuple consisting of (width, height). The size represents the size of the stream as it is displayed in the compositor coordinate space. Note that this size may not be equivalent to a size in a pixel coordinate space. The size may differ from the size of the stream. Optional.

Hence, we see that the API specification explicitly states that this is not the display resolution. A similar issue with Firefox's WebRTC implementation also ends with a strong argument about how this works and how it is not GNOME's bug.

Finally, I think we should look for a solution for this. Postponing it will only mean a bigger problem in the future, since HiDPI screens are taking over and fractional scaling will not be experimental the next version of GNOME shell.

Solutions to the problem:

If you use the DBUS interface and get the data of the PhisicalMonitors, it will return the correct resolutions just fine. I think that what firefox does is taking the selected monitor id (did not figure out how) and checking the resolution from there.
Getting the resolution from the pipewire stream. I think this should be the easiest and natural way to solve it for all.

Maybe @H-M-H can help with this, since he is the author of that code.

sahilyeole · 2023-11-19T02:52:27Z

Thanks for the work @manueldeprada.
I concluded it was a gnome issue as fractional scaling on kde wayland returned the correct screen resolution, maybe I was wrong.

I will check out the dbus interface way.

Getting the resolution from the pipewire stream. I think this should be the easiest and natural way to solve it for all.

But the pipewire stream doesn't provide display resolution. It only returns size, position, etc :(

manueldeprada · 2023-11-19T03:01:05Z

Thanks for the work @manueldeprada. I concluded it was a gnome issue as fractional scaling on kde wayland returned the correct screen resolution, maybe I was wrong.

I will check out the dbus interface way.

Getting the resolution from the pipewire stream. I think this should be the easiest and natural way to solve it for all.

But the pipewire stream doesn't provide display resolution. It only returns size, position, etc :(

Thanks for answering!! That properties are from the freedesktop DBUS, not from the pipewire. I get lost in the Rust code, but I was able to do it in the python script! Check this: https://gist.github.com/manueldeprada/8dce4a0a02067190715e92a4d69ff75d. To me, it plots the correct resolution of the pipewire pipeline.

sahilyeole · 2023-11-19T03:09:40Z

https://gist.github.com/manueldeprada/8dce4a0a02067190715e92a4d69ff75d. To me, it plots the correct resolution of the pipewire pipeline.

Great! Even when fractional scaling is on?

manueldeprada · 2023-11-19T03:19:35Z

https://gist.github.com/manueldeprada/8dce4a0a02067190715e92a4d69ff75d. To me, it plots the correct resolution of the pipewire pipeline.

Great! Even when fractional scaling is on?

yep... Adapting that to the rust code to do the same would be the good-code way to solve it, I think.

On a separate note: I have been 2h to understand all this pipewire/DBUS/Screencast... What a complicated and overengineered thing Linux has become... The API to get a stream of the screen from the OS should be much simpler.

sahilyeole · 2023-11-19T03:34:07Z

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

Lines 184 to 190 in c223d6a

    
           let cap = sample 
        
               .get_caps() 
        
               .ok_or("Failed get caps")? 
        
               .get_structure(0) 
        
               .ok_or("Failed to get structure")?; 
        
           let w: i32 = cap.get_value("width")?.get_some()?; 
        
           let h: i32 = cap.get_value("height")?.get_some()?;

I checked the code, we already have it and it is resulting in the correct display resolution on fractional scaling. Thanks for pointing it out, I missed it last time.
It is causing a mismatch of screen resolutions since the stream size being returned is the wrong one, hence causing the distortion.
I will get it fixed very soon.

On a separate note: I have been 2h to understand all this pipewire/DBUS/Screencast... What a complicated and overengineered thing Linux has become... The API to get a stream of the screen from the OS should be much simpler.

Haha true. X11 is much simpler but wayland makes things for the devs very complicated because of its secured design.
Thankfully we have these desktop portal APIs. I'm also utilizing it to add support for the clipboard on wayland and support input on flatpak version of rustdesk. It will be done very soon.

manueldeprada · 2023-11-19T03:40:07Z

I checked the code, we already have it and it is resulting in the correct display resolution on fractional scaling. Thanks for pointing it out, I missed it last time. It is causing a mismatch of screen resolutions since the stream size being returned is the wrong one, hence causing the distortion. I will get it fixed very soon.

Haha true. X11 is much simpler but wayland makes things for the devs very complicated because of its secured design. Thankfully we have these desktop portal APIs. I'm also utilizing it to add support for the clipboard on wayland and support input on flatpak version of rustdesk. It will be done very soon.

Awesome!! Let me know when I can test something. Note that to get the python code to work, I had to add the state change listener. Caps are None until the state effectively changes to PLAYING :)

rustdesk · 2023-11-19T03:53:05Z

Thanks @sahilyeole @manueldeprada

manueldeprada added the bug Something isn't working label Oct 20, 2023

rustdesk changed the title ~~Wayland issues: Green lines on scaled screen + no input~~ Wayland issues: Green lines on scaled screen + no input (SELinux) Oct 20, 2023

rustdesk changed the title ~~Wayland issues: Green lines on scaled screen + no input (SELinux)~~ Wayland issues: Green lines on scaled screen + no input (SELinux, Fedora) Oct 20, 2023

rustdesk added SELinux and removed SELinux labels Oct 22, 2023

sahilyeole mentioned this issue Nov 21, 2023

Fix: wayland fractional scaling distortion #6487

Merged

rustdesk closed this as completed in #6487 Nov 21, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Wayland issues: Green lines on scaled screen + no input (SELinux, Fedora) #6116

Wayland issues: Green lines on scaled screen + no input (SELinux, Fedora) #6116

manueldeprada commented Oct 20, 2023 •

edited

rustdesk commented Oct 20, 2023

rustdesk commented Oct 20, 2023

rustdesk commented Oct 20, 2023 •

edited

manueldeprada commented Oct 20, 2023 •

edited

rustdesk commented Oct 20, 2023 •

edited

manueldeprada commented Oct 20, 2023

rustdesk commented Oct 20, 2023 •

edited

rustdesk commented Oct 20, 2023

manueldeprada commented Oct 20, 2023 •

edited

fufesou commented Oct 20, 2023 •

edited

sahilyeole commented Oct 20, 2023

rustdesk commented Oct 20, 2023

manueldeprada commented Oct 20, 2023

manueldeprada commented Oct 20, 2023

rustdesk commented Oct 20, 2023 •

edited

fufesou commented Oct 21, 2023

fufesou commented Oct 21, 2023

sahilyeole commented Nov 12, 2023

HatWearingMann commented Nov 15, 2023

manueldeprada commented Nov 15, 2023

manueldeprada commented Nov 15, 2023 •

edited

sahilyeole commented Nov 15, 2023

manueldeprada commented Nov 15, 2023 •

edited

manueldeprada commented Nov 15, 2023

sahilyeole commented Nov 15, 2023

manueldeprada commented Nov 19, 2023 •

edited

sahilyeole commented Nov 19, 2023

manueldeprada commented Nov 19, 2023 •

edited

sahilyeole commented Nov 19, 2023

manueldeprada commented Nov 19, 2023 •

edited

sahilyeole commented Nov 19, 2023 •

edited

manueldeprada commented Nov 19, 2023 •

edited

rustdesk commented Nov 19, 2023

Wayland issues: Green lines on scaled screen + no input (SELinux, Fedora) #6116

Wayland issues: Green lines on scaled screen + no input (SELinux, Fedora) #6116

Comments

manueldeprada commented Oct 20, 2023 • edited

Bug Description

How to Reproduce

Expected Behavior

Operating system(s) on local side and remote side

RustDesk Version(s) on local side and remote side

Screenshots

Additional Context

rustdesk commented Oct 20, 2023

rustdesk commented Oct 20, 2023

rustdesk commented Oct 20, 2023 • edited

manueldeprada commented Oct 20, 2023 • edited

rustdesk commented Oct 20, 2023 • edited

manueldeprada commented Oct 20, 2023

rustdesk commented Oct 20, 2023 • edited

rustdesk commented Oct 20, 2023

manueldeprada commented Oct 20, 2023 • edited

fufesou commented Oct 20, 2023 • edited

sahilyeole commented Oct 20, 2023

rustdesk commented Oct 20, 2023

manueldeprada commented Oct 20, 2023

manueldeprada commented Oct 20, 2023

rustdesk commented Oct 20, 2023 • edited

fufesou commented Oct 21, 2023

Why your rules work

Warnings

fufesou commented Oct 21, 2023

sahilyeole commented Nov 12, 2023

HatWearingMann commented Nov 15, 2023

manueldeprada commented Nov 15, 2023

manueldeprada commented Nov 15, 2023 • edited

sahilyeole commented Nov 15, 2023

manueldeprada commented Nov 15, 2023 • edited

manueldeprada commented Nov 15, 2023

sahilyeole commented Nov 15, 2023

manueldeprada commented Nov 19, 2023 • edited

sahilyeole commented Nov 19, 2023

manueldeprada commented Nov 19, 2023 • edited

sahilyeole commented Nov 19, 2023

manueldeprada commented Nov 19, 2023 • edited

sahilyeole commented Nov 19, 2023 • edited

manueldeprada commented Nov 19, 2023 • edited

rustdesk commented Nov 19, 2023

manueldeprada commented Oct 20, 2023 •

edited

rustdesk commented Oct 20, 2023 •

edited

manueldeprada commented Oct 20, 2023 •

edited

rustdesk commented Oct 20, 2023 •

edited

rustdesk commented Oct 20, 2023 •

edited

manueldeprada commented Oct 20, 2023 •

edited

fufesou commented Oct 20, 2023 •

edited

rustdesk commented Oct 20, 2023 •

edited

manueldeprada commented Nov 15, 2023 •

edited

manueldeprada commented Nov 15, 2023 •

edited

manueldeprada commented Nov 19, 2023 •

edited

manueldeprada commented Nov 19, 2023 •

edited

manueldeprada commented Nov 19, 2023 •

edited

sahilyeole commented Nov 19, 2023 •

edited

manueldeprada commented Nov 19, 2023 •

edited