-
Notifications
You must be signed in to change notification settings - Fork 572
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CTRL Modifier is sent later than subsequent Keypresses to the target system #6491
Comments
Have u tried using the 'use remote keyboard map' option under settings? Sometimes, this is needed, and sometimes, it isn't For example when i control my mac, i need to untick it, but when I load up utm on my remote mac and then try typing inside the vm window, it won't type, so I have to tick the 'use remote keyboard map' then I can type inside the vm window |
Thank you for your reply. I just fired up the test environment again and this option does not help. I do not have problems with typing in general. I touch type decently fast and when I do that in a remote session, it all seems to work fine. Even Upercase / Lowercase, where SHIFT is used as a modifier. The issue seems to be specific about the CTRL Key. I suspect this is handled. Even the ALT key seems to work fine... but with CTRL I have to wait .5 - 1 second until it does its thing. I would not even open the issue if the Router had more options (like bi-directional Clipboard support like we have in the browser) and would just stick to the Router ;-) |
The meshcentralrouter has clipboard built in if I'm correct, u don't need to enable/disable any options? Also have u tried going browser fullscreen? Edit. The is also other issues already open about the ctrl issue but they explain its sticky and doesn't undo the keypress |
Yes, you are right. The meshcentralrouter has clipboard built in. I made the mistake and activated the "Automatically send clipboard" feature in the router, which automates the clipboard but only in one direction. When I turn that off, I see the 2 clipboard Icons for manual transfer. Thank you! I just tried browser fullscreen with SHIFT + Click on the fullscreen icon. This did not change the CTRL behavior. I did not find the other CTRL issue, I am sorry. But I can confirm that it is not sticky. It just takes the 0,5 to 1 second to "activate". Update! It only seems to affect the LEFT CTRL Key. When I use the right one, it works instantly like I would expect. I never tried, because left CTRL+V / C need only 1 hand to activate. ctrl_vs_shift.mp4 |
erm thats not right if i remember it should be both ways??? as for the CTRL key issue, |
Thank you for your comment. I just tried with webrtc: false and a restart, still the same issue. Left CTRL is delayed, right CTRL is fine. Is there some kind of "communication log" that logs all the keypresses that are sent back and forth that might help here? I will double check the clipboard issue in router and then go to the other Repo ;-) |
you can use |
Describe the bug
When remove accessing another System and for example using CTRL+C or CTRL+V for Copy & Paste, most of the time a c or v is written. The Key combination only works for me, when I wait half a second or a second after depressing the CTRL Key until I press C or V. When using Copy & Paste over a Remote session often, this makes it very cumbersome to use. I feel this is more an issue in the Webbrowser than when using the Router Windows executable. But the latter one seems to miss the feature to transfer the Clipboard from the Remote to the local System, so it is less preferred.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I would expect that keys that are pressed in a specific order are sent to the destination in that order. But this does not seem to be the case when CTRL is involved.
Server Software (please complete the following information):
Client Device (please complete the following information):
Remote Device (please complete the following information):
Additional context
Add any other context about the problem here.
Your config.json file
The text was updated successfully, but these errors were encountered: