Give movement priority to host rather than client + multiple connections mouse move priority issue #32

New issue

Open

opened 2026-02-20 22:20:43 -05:00 by deekerman · 18 comments

deekerman commented 2026-02-20 22:20:43 -05:00

Owner

Copy link

Originally created by @jonatino on GitHub (May 17, 2021).

Right now the client has priority over the host for controlling the mouse. Teamviewer/anydesk use the opposite. Any movement the host does with the mouse will always override any movement the client connected makes.

I think rustdesk should follow the same logic.

Originally created by @jonatino on GitHub (May 17, 2021). Right now the client has priority over the host for controlling the mouse. Teamviewer/anydesk use the opposite. Any movement the host does with the mouse will always override any movement the client connected makes. I think rustdesk should follow the same logic.

deekerman added the

enhancement

help wanted

labels 2026-02-20 22:20:43 -05:00

deekerman commented 2026-02-20 22:20:44 -05:00

Author

Owner

Copy link

@EkanshBhatnagar commented on GitHub (May 26, 2021):

I want to contribute to solve this issue, is there any contribution guide.

@EkanshBhatnagar commented on GitHub (May 26, 2021): I want to contribute to solve this issue, is there any contribution guide.

deekerman commented 2026-02-20 22:20:45 -05:00

Author

Owner

Copy link

@rustdesk commented on GitHub (May 26, 2021):

contribution guide

No yet. Please create pull request, then I will review. Thanks very much.

@rustdesk commented on GitHub (May 26, 2021): > contribution guide No yet. Please create pull request, then I will review. Thanks very much.

deekerman commented 2026-02-20 22:20:45 -05:00

Author

Owner

Copy link

@IdoPractical commented on GitHub (Apr 19, 2023):

I'm not sure why but it's still the same in my end, when I connect to remote PC, I will have a priority controlling the mouse which sometimes makes the guy on the other end go crazy.

@IdoPractical commented on GitHub (Apr 19, 2023): I'm not sure why but it's still the same in my end, when I connect to remote PC, I will have a priority controlling the mouse which sometimes makes the guy on the other end go crazy.

deekerman commented 2026-02-20 22:20:46 -05:00

Author

Owner

Copy link

@jonatino commented on GitHub (Apr 21, 2023):

@rustdesk @fufesou it would be nice if this was configurable on the client side. I think in 99% of cases you want the host to always have input priority, but I think there's still a case for the current (client-side priority) behavior. Eg when I'm remote controlling my grandma's computer, she can't help but move the mouse constantly while I'm trying to do things. It'd be nice to allow for Client input priority in this specific case.

@jonatino commented on GitHub (Apr 21, 2023): @rustdesk @fufesou it would be nice if this was configurable on the client side. I think in 99% of cases you want the host to always have input priority, but I think there's still a case for the current (client-side priority) behavior. Eg when I'm remote controlling my grandma's computer, she can't help but move the mouse constantly while I'm trying to do things. It'd be nice to allow for Client input priority in this specific case.

deekerman commented 2026-02-20 22:20:46 -05:00

Author

Owner

Copy link

@rustdesk commented on GitHub (Aug 16, 2023):

reverted, github.com/rustdesk/rustdesk@542d86b667, because it causes much more trouble than benefits. @fufesou we need another clever solution to detect host mouse movement.

win -> mac

https://github.com/rustdesk/rustdesk/assets/71636191/5922150c-c7a7-45be-977b-158314e67d9c

@rustdesk commented on GitHub (Aug 16, 2023): reverted, https://github.com/rustdesk/rustdesk/commit/542d86b667a2da19f89591a03a39edd9ab4d406e, because it causes much more trouble than benefits. @fufesou we need another clever solution to detect host mouse movement. win -> mac https://github.com/rustdesk/rustdesk/assets/71636191/5922150c-c7a7-45be-977b-158314e67d9c

deekerman commented 2026-02-20 22:20:46 -05:00

Author

Owner

Copy link

@rustdesk commented on GitHub (Aug 16, 2023):

pub fn try_start_record_cursor_pos() -> Option<thread::JoinHandle<()>> {
     ....
    let track_peer = vec![];
    let track_sys = vec![];
    let handle = thread::spawn(|| {
        let interval = time::Duration::from_millis(33);
        loop {
            if !RECORD_CURSOR_POS_RUNNING.load(Ordering::SeqCst) {
                break;
            }

            let now = time::Instant::now();

          // update track_sys here
           // update track_peer here via LATEST_PEER_INPUT_CURSOR

          // compare the track
           
            let elapsed = now.elapsed();
            if elapsed < interval {
                thread::sleep(interval - elapsed);
            }
        }
        update_last_cursor_pos(INVALID_CURSOR_POS, INVALID_CURSOR_POS);
    });
    Some(handle)
}

or the other better way.

@rustdesk commented on GitHub (Aug 16, 2023): ``` pub fn try_start_record_cursor_pos() -> Option<thread::JoinHandle<()>> { .... let track_peer = vec![]; let track_sys = vec![]; let handle = thread::spawn(|| { let interval = time::Duration::from_millis(33); loop { if !RECORD_CURSOR_POS_RUNNING.load(Ordering::SeqCst) { break; } let now = time::Instant::now(); // update track_sys here // update track_peer here via LATEST_PEER_INPUT_CURSOR // compare the track let elapsed = now.elapsed(); if elapsed < interval { thread::sleep(interval - elapsed); } } update_last_cursor_pos(INVALID_CURSOR_POS, INVALID_CURSOR_POS); }); Some(handle) } ``` or the other better way.

deekerman commented 2026-02-20 22:20:46 -05:00

Author

Owner

Copy link

@rustdesk commented on GitHub (Oct 26, 2023):

https://github.com/rustdesk/rustdesk/discussions/6178#discussioncomment-7390701 a good suggestion, i had done similar logic in Sciter version.

github.com/rustdesk/rustdesk@cf8ef2533a/src/ui/remote.tis (L181)

But we need to go further, how about if controlled side only move mouse very slightly by mistake frequently? Please have a summary of how the other vendor do this.

@rustdesk commented on GitHub (Oct 26, 2023): https://github.com/rustdesk/rustdesk/discussions/6178#discussioncomment-7390701 a good suggestion, i had done similar logic in Sciter version. https://github.com/rustdesk/rustdesk/blob/cf8ef2533a8e9159d897436522d011dea70993ae/src/ui/remote.tis#L181 But we need to go further, how about if controlled side only move mouse very slightly by mistake frequently? Please have a summary of how the other vendor do this.

deekerman commented 2026-02-20 22:20:46 -05:00

Author

Owner

Copy link

@My1 commented on GitHub (Nov 1, 2023):

[@]rustdesk [@]fufesou it would be nice if this was configurable on the client side. I think in 99% of cases you want the host to always have input priority, but I think there's still a case for the current (client-side priority) behavior. Eg when I'm remote controlling my grandma's computer, she can't help but move the mouse constantly while I'm trying to do things. It'd be nice to allow for Client input priority in this specific case.

if anything this should be something that is only configurable from the client, otherwise you can just tell your grandma to take the hand off the mouse, that's what I usually do at work with customers when we use anydesk.

@rustdesk implementation question, can the application actually read what the physical mouse/keyboard devices are doing or is that cloaked via the OS? because if it isnt cloaked you might be able to check via that instead of trying cursor chaos.

@My1 commented on GitHub (Nov 1, 2023): > [@]rustdesk [@]fufesou it would be nice if this was configurable on the client side. I think in 99% of cases you want the host to always have input priority, but I think there's still a case for the current (client-side priority) behavior. Eg when I'm remote controlling my grandma's computer, she can't help but move the mouse constantly while I'm trying to do things. It'd be nice to allow for Client input priority in this specific case. if anything this should be something that is only configurable from the client, otherwise you can just tell your grandma to take the hand off the mouse, that's what I usually do at work with customers when we use anydesk. @rustdesk implementation question, can the application actually read what the physical mouse/keyboard devices are doing or is that cloaked via the OS? because if it isnt cloaked you might be able to check via that instead of trying cursor chaos.

deekerman commented 2026-02-20 22:20:46 -05:00

Author

Owner

Copy link

@rustdesk commented on GitHub (Nov 16, 2023):

another scenario needs to be taken care. https://github.com/rustdesk/rustdesk/discussions/6433

@rustdesk commented on GitHub (Nov 16, 2023): another scenario needs to be taken care. https://github.com/rustdesk/rustdesk/discussions/6433

deekerman commented 2026-02-20 22:20:46 -05:00

Author

Owner

Copy link

@pricerc commented on GitHub (Feb 18, 2024):

Some remote control software has discrete cursors for each connected client.

So each connected client can have a mouse cursor in a different place, and it is like only the "clicks" that are shared, not the movements themselves, but you can see everyone's individual cursors.

So even if Grandma is moving her mouse, it won't interfere with what you're doing, unless she starts clicking randomly.

e.g. with MS Teams, when someone moves their mouse, you see a cursor decorated with their initials (or avatar) moving around, so you can see what they're doing, but it doesn't interfere with your own mouse cursor. It is quite good for collaborative work.

@pricerc commented on GitHub (Feb 18, 2024): Some remote control software has discrete cursors for each connected client. So each connected client can have a mouse cursor in a different place, and it is like only the "clicks" that are shared, not the movements themselves, but you can see everyone's individual cursors. So even if Grandma is moving her mouse, it won't interfere with what you're doing, unless she starts clicking randomly. e.g. with MS Teams, when someone moves their mouse, you see a cursor decorated with their initials (or avatar) moving around, so you can see what they're doing, but it doesn't interfere with your own mouse cursor. It is quite good for collaborative work.

deekerman commented 2026-02-20 22:20:46 -05:00

Author

Owner

Copy link

@My1 commented on GitHub (Feb 20, 2024):

havent tried Teams specifically yet, but click only could become problematic once you need to hover stuff

@My1 commented on GitHub (Feb 20, 2024): havent tried Teams specifically yet, but click only could become problematic once you need to hover stuff

deekerman commented 2026-02-20 22:20:46 -05:00

Author

Owner

Copy link

@pricerc commented on GitHub (Feb 20, 2024):

havent tried Teams specifically yet, but click only could become problematic once you need to hover stuff

I don't think Teams is click-only - Windows does support having multiple mouse cursors (apparently).

I can't remember how it behaves when hovering. I'll make a point of looking out for it and seeing how it behaves.

But having multiple identifiable cursors is very helpful when collaborating.

All I know is, that of the remote-control systems I use (varies by customer), it is only when using RustDesk that I seem to notice competition for the mouse cursor. Although, that could also just be the people whose machine's I'm operating...

@pricerc commented on GitHub (Feb 20, 2024): > havent tried Teams specifically yet, but click only could become problematic once you need to hover stuff I don't think Teams *is* click-only - Windows does support having multiple mouse cursors (apparently). I can't remember how it behaves when hovering. I'll make a point of looking out for it and seeing how it behaves. But having multiple identifiable cursors is very helpful when collaborating. All I know is, that of the remote-control systems I use (varies by customer), it is only when using RustDesk that I seem to notice competition for the mouse cursor. Although, that could also just be the people whose machine's I'm operating...

deekerman commented 2026-02-20 22:20:46 -05:00

Author

Owner

Copy link

@lwintermelon commented on GitHub (Aug 18, 2024):

But we need to go further, how about if controlled side only move mouse very slightly by mistake frequently?

@rustdesk
Making the host side have a higher priority seems very straightforward，because we can track the state of remote on the controlled side and simply discard the movement message of remote if we desired (like the reverted commit does ), the opposite way may be less straightforward because the movement of real hardware mouse will always conflict with the emulated mouse event of remote message but we want the remote control to suppress the host.
However if we take how about if controlled side only move mouse very slightly by mistake frequently into account, it will face the same problem. Suppose we need the ability to make remote control to suppress the host, we must have the ability to distinguish our emulated mouse event from system mouse event and manipulate them(via hook)，which is more platform-specific. Do we really need it? It seems we already have it on PrivacyMode and it's implemented on Windows.

@lwintermelon commented on GitHub (Aug 18, 2024): > But we need to go further, how about if controlled side only move mouse very slightly by mistake frequently? @rustdesk Making the host side have a higher priority seems very straightforward，because we can track the state of remote on the controlled side and simply discard the movement message of remote if we desired (like the reverted [commit ](https://github.com/rustdesk/rustdesk/commit/542d86b667a2da19f89591a03a39edd9ab4d406e) does ), the opposite way may be less straightforward because the movement of real hardware mouse will always conflict with the emulated mouse event of remote message but we want the remote control to suppress the host. However if we take **how about if controlled side only move mouse very slightly by mistake frequently** into account, it will face the same problem. Suppose we need the ability to make remote control to suppress the host, we must have the ability to distinguish our emulated mouse event from system mouse event and manipulate them(via hook)，which is more platform-specific. Do we really need it? It seems we already have it on PrivacyMode and it's implemented on Windows.

deekerman commented 2026-02-20 22:20:46 -05:00

Author

Owner

Copy link

@rustdesk commented on GitHub (Aug 20, 2024):

@lwintermelon you can have a summarization of how the other tools do this.

@rustdesk commented on GitHub (Aug 20, 2024): @lwintermelon you can have a summarization of how the other tools do this.

deekerman commented 2026-02-20 22:20:46 -05:00

Author

Owner

Copy link

@lwintermelon commented on GitHub (Aug 24, 2024):

@pricerc @rustdesk

I don't think Teams is click-only - Windows does support having multiple mouse cursors (apparently).

As far as I know, Windows doesn't support multiple mouse cursors natively(the close thing is Windows MultiPoint Server, but it won't help our cases), we have to implement it ourselves, I do think fully support multiple mouse cursors(I mean collaborative multiple cursors like MouseMux does) is out of scope, but at least ,we should keep compatibility with such tools.

I suggest we do it step by step.

1. provide an option to lock remote keyborad/mouse (explicit way).
2. optimize the logic which user is activated and give movement priority to host rather than client (implicit way).
3. initial multiple cursors support: for example draw multiple cursors with different identification, every cursor remember its own position, and a cursor may have exclusive control (explicitly require or implicitly collaborative).
   I call this system-wide-multiple-cursor, because the multiple cursors event is sent to opearting system. In essence, it is still single cursor but with the ability to show other identifiable cursors at the same time. This is what @pricerc describes. And yes, it is quite good for collaborative work.
4. investigate more collaborative multiple cursors integrations. I call these cross-application-multiple-cursor(different user's events can be sent to different application window even seamlessly , by this means we can have real multiple cursors, including the hover tooltip for different application) and in-application-multiple-cursor(different user's events can be sent to single application without confliction, which I do think it needs the support of application, one example is vscode live share).

By now I suggest we don't touch 4 because it is orthogonal to rustdesk and there are seperate tools for it, we may add some features in the future and it may be a selling point, but let's implemented 1. 2. and 3. first and compare it with competitor and prioritize real needs of our users.

@lwintermelon commented on GitHub (Aug 24, 2024): @pricerc @rustdesk >I don't think Teams is click-only - Windows does support having multiple mouse cursors (apparently). As far as I know, Windows doesn't support multiple mouse cursors natively(the close thing is Windows MultiPoint Server, but it won't help our cases), we have to implement it ourselves, I do think fully support multiple mouse cursors(I mean collaborative multiple cursors like [MouseMux ](https://www.mousemux.com) does) is out of scope, but at least ,we should keep compatibility with such tools. I suggest we do it step by step. 1. provide an option to lock remote keyborad/mouse (explicit way). 2. optimize the logic which user is activated and give movement priority to host rather than client (implicit way). 3. initial multiple cursors support: for example draw multiple cursors with different identification, every cursor remember its own position, and a cursor may have exclusive control (explicitly require or implicitly collaborative). I call this system-wide-multiple-cursor, because the multiple cursors event is sent to opearting system. In essence, it is still single cursor but with the ability to show other identifiable cursors at the same time. This is what @pricerc describes. And yes, it is quite good for collaborative work. 4. investigate more collaborative multiple cursors integrations. I call these cross-application-multiple-cursor(different user's events can be sent to different application window even seamlessly , by this means we can have real multiple cursors, including the hover tooltip for different application) and in-application-multiple-cursor(different user's events can be sent to single application without confliction, which I do think it needs the support of application, one example is vscode live share). By now I suggest we don't touch 4 because it is orthogonal to rustdesk and there are seperate tools for it, we may add some features in the future and it may be a selling point, but let's implemented 1. 2. and 3. first and compare it with competitor and prioritize real needs of our users.

deekerman commented 2026-02-20 22:20:46 -05:00

Author

Owner

Copy link

@rustdesk commented on GitHub (Aug 24, 2024):

We do not do 4, it is out of our scope.

@rustdesk commented on GitHub (Aug 24, 2024): We do not do 4, it is out of our scope.

deekerman commented 2026-02-20 22:20:46 -05:00

Author

Owner

Copy link

@jonatino commented on GitHub (Aug 24, 2024):

4, seems like an extremely complex solution that will be a nightmare to maintain on different platforms.

What was the problem with the original solution of using a thread to calculate changes in the cursor position and then ignoring remote events until X amount of time has passed?

@jonatino commented on GitHub (Aug 24, 2024): 4, seems like an extremely complex solution that will be a nightmare to maintain on different platforms. What was the problem with the original solution of using a thread to calculate changes in the cursor position and then ignoring remote events until X amount of time has passed?

deekerman commented 2026-02-20 22:20:46 -05:00

Author

Owner

Copy link

@petre-c commented on GitHub (Feb 4, 2026):

Any updates on this?

@petre-c commented on GitHub (Feb 4, 2026): Any updates on this?

deekerman referenced this issue 2026-02-20 23:06:36 -05:00

App crash when connect AndroidTV 11 device (or the other non-phone devices) #619

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

avatar

copilot/fix-discussion-14282-issue

copilot/fix-h265-image-quality-issue

fix-mobile-mouse-hover-issue-8789

ios

sciterjs

nightly

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.9

1.3.8

1.3.7

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.7

1.2.6

1.2.5

1.2.4

fdroid-version

1.2.3-2

1.2.3-1

1.2.3

1.2.2

1.2.1

1.2.0

1.1.9

1.1.8

1.1.6

1.1.5

1.1.4

1.1.3

1.1.2

Labels

Clear labels   

bug

  

documentation

  

duplicate

  

enhancement

  

enhancement

  

enhancement

  

good first issue

  

help wanted

  

invalid

  

question

  

unreproducible

  

wontfix

No labels

bug

documentation

duplicate

enhancement

enhancement

enhancement

good first issue

help wanted

invalid

question

unreproducible

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/rustdesk-rustdesk#32

No description provided.