mirror of
https://github.com/rustdesk/rustdesk.git
synced 2026-03-02 19:26:56 -05:00
Multi-Monitor problem - clicking on first window results in click on other windows #3160
Labels
No labels
bug
documentation
duplicate
enhancement
enhancement
enhancement
good first issue
help wanted
invalid
question
unreproducible
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/rustdesk-rustdesk#3160
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @realGnargh on GitHub (Dec 4, 2024).
Originally assigned to: @fufesou on GitHub.
Bug Description
Using Linux Mind Debian Edition LMDE 6, 4 Monitors (all different resolutions), connecting to a Windows-Client with 3 Monitors an different resolutions.
On Linux: #2-Main 2560x1440 in the middle, #1 3840x2160 scaled to 150% on the left, #3 3840x2160 scaled 150% on the right, #4 1920x1080 scaled 100% top right.
On Windows Main: one Screen 1920x1080 left, main screen 2560x1440 middle, and last screen 1920x1080 on the right.
Now controlling from the Linux side moving a windows on the main screen to the right at some point (~3/4 of the screen) the windows flicks wild too the second (windows) monitor. I tried screenshoting the behaviour, hope this helps.
Setup Linux:
Setup-Windows:
Moving Explorer-Window on Main on Windows:
I start moving or using the mouse works fine at first, until the mouse moves too far right:
it now jumps to the right monitor:
Mouse still on the middle monitor going up it jumps to the left monitor:
And as a bonus all my clicks with the mouse get magically sent to the right or left monitor.
How to Reproduce
Unsure, could also be a bug in Linux, but did not occur to me with any other application so far.
Expected Behavior
The mouse should not switch to the second/third monitor while still active on the main one, I guess?
Operating system(s) on local (controlling) side and remote (controlled) side
Linux -> Windows
RustDesk Version(s) on local (controlling) side and remote (controlled) side
1.3.3. -> 1.3.3 (also previous versions up from 1.2.6)
Screenshots
https://github.com/user-attachments/assets/551f2443-4316-473b-9bf4-a7a76e1da768
Additional Context
No response
@rustdesk commented on GitHub (Dec 4, 2024):
How about their scales?
@realGnargh commented on GitHub (Dec 4, 2024):
No scaling on windows, client side.
@fufesou commented on GitHub (Dec 4, 2024):
@realGnargh Thanks for your feedback.
How about the mouse operations? Clicks and drags without the window.
@realGnargh commented on GitHub (Dec 4, 2024):
Its the same for all mouse operations, clicking, draging results (most of the time) in the other 2 screens.
Sometimes I have to click multiple times in the main-screen and it works as expected.
@rustdesk commented on GitHub (Dec 4, 2024):
Wondering if you have the other Linux machines to test?
@fufesou commented on GitHub (Dec 13, 2024):
@realGnargh Hi, Could you please do more tests, on the local side(LMDE)?
I tried LMDE6, single display, scale 125%(vm virtualbox), but can't reproduce this issue. Remote dislays are the same.
I can't enable multiple displays in virtualbox for unknown reason.
@realGnargh commented on GitHub (Dec 21, 2024):
Without any scaling it seems to not happen at all. I tried too make a second video, and add a bit information of my setup.
without scaling:
Graphics: Device-1: AMD Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] driver: amdgpu v: kernel Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: X: loaded: amdgpu unloaded: fbdev,modesetting,radeon,vesa dri: radeonsi gpu: amdgpu resolution: 1: 1920x1080~60Hz 2: 3840x2160~60Hz 3: 2560x1440~60Hz 4: 3840x2160~60Hz API: OpenGL v: 4.6 Mesa 22.3.6 renderer: AMD Radeon RX 5700 (navi10 LLVM 15.0.6 DRM 3.49 6.1.0-28-amd64)scaling enabled:
Graphics: Device-1: AMD Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] driver: amdgpu v: kernel arch: RDNA-1 pcie: speed: 16 GT/s lanes: 16 ports: active: DP-1, DP-2, DP-3, HDMI-A-1 empty: none bus-ID: 08:00.0 chip-ID: 1002:731f Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: X: loaded: amdgpu unloaded: fbdev,modesetting,radeon,vesa dri: radeonsi gpu: amdgpu display-ID: :0 screens: 1 Screen-1: 0 s-res: 15360x5040 s-dpi: 120 Monitor-1: DP-1 mapped: DisplayPort-0 pos: 1-4 model: Acer GF246 res: 3840x2160 dpi: 184 diag: 609mm (24") Monitor-2: DP-2 mapped: DisplayPort-1 pos: 2-1 model: 49UHD_LCD_TV res: 5120x2880 dpi: 69 diag: 1254mm (49.4") Monitor-3: DP-3 mapped: DisplayPort-2 pos: primary,2-2 model: Acer KG271U res: 5120x2880 dpi: 218 diag: 685mm (27") Monitor-4: HDMI-A-1 mapped: HDMI-A-0 pos: 2-3 model: Lenovo L28u-35 res: 5120x2880 dpi: 210 diag: 712mm (28") API: OpenGL v: 4.6 Mesa 22.3.6 renderer: AMD Radeon RX 5700 (navi10 LLVM 15.0.6 DRM 3.49 6.1.0-28-amd64) direct-render: Yeshttps://github.com/user-attachments/assets/4db36fbe-5f22-4d7d-bb50-84a71bbabaff
(I wrote 1 in video, but itś 3 according to my setup)
@realGnargh commented on GitHub (Jan 16, 2025):
Today I thought I will work only on one monitor too avoid the problem, but got into the same problem:
https://github.com/user-attachments/assets/c9947cd3-7a4b-492d-bd6f-a85e6d1a7c29
@norbert79 commented on GitHub (Jun 14, 2025):
I would like to confirm this issue also. I have a two monitor layout both same size, same resolution, and while Wayland recognizes the one monitor as first, I am using the second as primary, This is causing it basically controlling the mouse on the display, which is normally recognized as primary and not following the settings defined. Weirdly, my chosen primary displayed desktop is shown, but the mouse movement is done on the by Wayland chosen primary display when connected.
P.S.: If you need logs and config files, please let me know, I happy to deliver.
@sansbyte commented on GitHub (Aug 3, 2025):
@norbert79 Your post lead me to try something that resolved my issue. My issue was the mouse would always be stuck to the left most side of the left screen in my dual monitor setup. The mouse would move up and down but was always stuck to the left side. I swapped monitors plugged into the docking station I use, reconfigured the display arrangement in Linux (i.e. swapped left/right positions), and my issue was resolved.
@rustdesk commented on GitHub (Aug 23, 2025):
This one is Arch Linux (EndeavorOS) KDE Wayland
https://github.com/rustdesk/rustdesk/issues/12715#issuecomment-3217508549
https://github.com/rustdesk/rustdesk/issues/12715#issuecomment-3217443690
@rustdesk commented on GitHub (Aug 23, 2025):
@fufesou
Buy test monitors and PC (if virtualbox not work), do not waste time on env.
@paul-hansen commented on GitHub (Aug 24, 2025):
Note that the workaround quoted above was taken from an issue for connecting to a linux client from Windows, this issue is the reverse, connecting to a Windows client from Linux. The window's client won't have Wayland's virtual display option when accepting the screenshare so that workaround doesn't work for this issue.
Just wanted to clear that up for anyone is trying to use that workaround without the context of the issue it was taken from.
@ThePelicano commented on GitHub (Aug 28, 2025):
I have the same problem when I choose to use only one screen, the cursor appears on the wrong screen, I need to transmit all the screens to be able to access correctly, but it takes up a lot of space. Both sides, the host and the machine I use to connect remotely, are running Linux
@fufesou commented on GitHub (Aug 31, 2025):
@realGnargh @norbert79 @sansbyte @paul-hansen @TheLumbee Hi, could you please try the latest nightly build on the controlling (local) side? This issue may be fixed. https://github.com/rustdesk/rustdesk/releases/tag/nightly
@paul-hansen commented on GitHub (Sep 4, 2025):
No change for me, here's a video of it happening using the latest nightly on both client and host:
https://github.com/user-attachments/assets/bddfc37b-19ea-4192-8431-1b0d06ea5756
Note: I'm using Linux -> Linux with Wayland on both but the OP was using Linux -> Windows.
@fufesou commented on GitHub (Sep 4, 2025):
@paul-hansen Thanks for your feedback.
RustDesk -> Linux (Wayland, multiple-monitors), the cursor position may be wrong.
https://github.com/rustdesk/rustdesk/discussions/10509#discussioncomment-13216014
https://github.com/rustdesk/rustdesk/discussions/10509#discussioncomment-13229920
There is no good workaround for now.
Maybe you can try to install
xrandron the controlled side if it is Fedora 41 or 42.@zihaooo commented on GitHub (Sep 18, 2025):
I encounter the same issue. Here is my configuration:
Is there anything I could do to help troubleshoot this bug?
@fufesou commented on GitHub (Sep 18, 2025):
@zihaooo Thanks for your feedback.
What is the RustDesk version on the local side?
How about only one display on the local side?
@zihaooo commented on GitHub (Sep 18, 2025):
@fufesou Thank you for your prompt response.
Both local and remote sides run with RustDesk 1.4.1
There is no issue if only open one display on the local side.
@fufesou commented on GitHub (Sep 18, 2025):
@zihaooo Please try
1.4.2or the nightly build on the controlling/local side.https://github.com/rustdesk/rustdesk/releases/tag/1.4.2
https://github.com/rustdesk/rustdesk/releases/tag/nightly
@rustdesk commented on GitHub (Nov 17, 2025):
Fixed in nightly build, please help test, https://x.com/rustdesk/status/1990469787487776820
@vincentkoevoets commented on GitHub (Dec 13, 2025):
I have the same problem on a single monitor local side, and a triple monitor setup on the remote side. Both on latest Ubuntu with Wayland, so not connecting to Windows but exactly the same problems as OP. Both sides on the latest Rustdesk nightly. My local side is scaled, but also without scaling the same problem appeared. The mouse is completely misaligned between local and remote. My screen setup on remote is 1-3-2, where 3 is marked in settings as my primary.