Would you like to co-innovate with us? If so, we’d like to invite you to become product development partners with us. Read more about it in our announcement Launch of the TeamViewer User Focus Program3>
i connect from ubuntu to a remote ubuntu, and when I'm connected, when using the CTRL it just types it repeatedly. (team viewer 13.0.6634, and both Ubuntu 16.04)
CTRL+c will output in the terminal "ccccccccccccccccccccccccccccccccccccccccccccc"
it makes it really hard to work on a linux terminal as CTRL is oftenly used.
using enterprise version.
the same happeng to me.
really **UNPRODUCTIVE** **ANNOYING**
Me too. Ubuntu 16.04 and 18.04.
Client becomes unoperable, with any attempt to do anything resulting in "ccccccccccccccccccccccccccccccccc"
It also inteferes with mouse-clicks, e.g. if you click an application on the taskbar to get the context menu, suddly the interface receives "cccc" whihc aligns to "Close" and the app dissappears.
This is a serious problem which results in data loss.
Same problem here. I got it after updating to version 13, it was fine when I used version 12. I still have the problem even after updating to the most recent version (13.1.8286). My computers are both Linux Mint 18.2 and 18.
I apologize for the inconvenience. This thread came to my attention (again?) just a few days ago, which was too late to fix it for the current update: June update.
But we put it on the list for the next release.
It seems that it only happens on some machines (does not happen on this developers machine...) and we have to figure out why. It might also be a combination of the local and remote machine.
I tried it on many machines and the problem is always there. I tried it with Arch and Linux Mint, connecting to many Linux Mint and Windows machines. I don't know why you doesn't experience it...
I could only reproduce it if I release the Ctrl key before the other (which usually I never do, out of habit). Maybe you have a different habit for INSERT than for the "normal" keys?
So, until it is fixed, maybe it helps a few of you to make sure the Ctrl-key is released after the other key.
I am on a german keyboard - could this make a difference?
So am I. :robotwink:
No, no difference, but thanks for the input.
I'm using a Spanish keyboard and I am connecting to machines with US English keyboards.
This issue with Shift / Control Keys only started happening for me a few weeks ago. Prior to that I cannot recall this problem happening and I would connect with Teamviewer most days. So it could be related to an update. I have no idea when Teamviewer was last updated but I install Ubuntu updates every day or two.
This is really annoyng bug and it will be great to receive some info about the fixing progress or some feedback from the developer. To remain silent isn't a wise strategy in this case.
And stuff is apparently not taking this issue very seriously. They are saying things like release ctrl before pressing keys. What is this? Instead of educating us on how to use the keyboard, solve this stupid problem!
@kkog, @mozo: Actually we are actively working on this, but I have been reluctant to say it'll be fixed with the next update, as I'm trying to make sure it is actually fixed.
This bug is pretty nasty, as it does not always occur for everybody, so when we thought it's fixed (because it no longer seems to appear), we were not 100% sure.
Also, I did not try to educate anybody, I tried to figure out whether certain usage patterns trigger the bug.
Meanwhile, I sent a test build to affected people to get verification. First replies sound promising, no faulty behavior reported back. So I'm cautiously optimistic it's fixed.
Nobody urges you Daniel. The feedback and the lack of information are the missing parts. Thank you for your reply :)
Sorry for the delay - I was away and under stress - I made further tests (that also required a lot more effort):
Completely new machine, Latest Ubuntu 18.04 and Teamviewer 13 at local and remote: CTRL+C, CTRL+V and other combinations do work now.
Having other machine with older Ubuntu and TeamViewer 13 on both sides does not help - has the issue. Connecting from the new machine to the older (Ubuntu 14.04) with both TeamViewer 13 it works (although I did not expect that). From new machine with Ubuntu 18.04 to remote Windows machine with TeamViewer 13 on both sides works while from the Ubuntu 14.04 to the same remote Windows machine both TeamViewer 13 has the issue.
I tried also connecting from the Ubuntu 14.04 (local) to 18.04 (remote, both TeamViewer 13) and then I have the issue, which vice versa I do not have.
This is my locale on the Ubuntu 14.04 and also on the 18.04 - both are the same:
Keyboard layout are both the same (german).
I also tried the current TeamViewer 13 version on Ubuntu 16.04 versus 18.04 in both directions and works in both directions. I am on build 13.1.8286. I am pretty sure that at least with an older build of TeamViewer 13 it did not work on Ubuntu 16.04 either (although it was a different machine and not the one I used right now for testing). I hope all these inputs help nailing the problem. However, for my daily work I am currently migrating to Ubuntu 18.04 so for me the problem seems to be solved for the future.
We've just released our summer update. It contains some improvements for the keyboard handling. Some of you had already tested it and gave mixed feedback. It seems that the behavior is better, but not completely well.
Please leave your feedback on your experience, good or bad.
If you have clues when it happens or how to stop it (e.g. reconnecting), please also share.
The same on Linux Mint 19 MATE. However I managed to find a workaround:
Have a nice day.
I've just tried the "summer update" (13.2.13582), and I'm still facing the issue. To be precise, the issue I'm having is only with Shift (not Ctrl or Alt). From the moment that I press Shift, it stays "stuck". The standard keys are still sent normally (example a stays lowercase, and Shift+a is A), but special keys like arrow up/down/left/right, or delete, etc. are interpreted always with shift at the same. Also (and most annoying) is that mouse clicks are also considered with Shift down.
Both the controlled and controlling computers are running Ubuntu 16.04, with the same keyboard mapping (US international + AltGr). This doesn't happen if the controlling computer is on Windows.
When this happen, running xev, and clicking on the window shows this:
ButtonPress event, serial 37, synthetic NO, window 0x5c00001,
root 0x110, subw 0x0, time 1370688504, (49,134), root:(916,999),
state 0x1, button 1, same_screen YES
Note the "state = 0x1". Normally, it should be "state=0x0".
So far, I've found two ways to stop the Shift:
I've completely given up on Teamviewer. I would have rolled back to the previous release which worked but it refuses to connect with anyone using version 13.
So I have gone back to **Third Party Product** and it works fine with no problems. In fact, it also fixes another bug in Teamviewer (the clipboard bug).
I wish everyone luck with Teamviewer but it is unusable and no one really knows how to fix the bug.
I have following problem with teh trafered keys:
If I connect to my main computer from university or work and open from the accessed computer another rdp session to my homeserver - then the AltGr key compinations do not work. On the first hop to the main computer everything works fine. But not on the next hop.
I had issues with Shift key getting stuck when connecting from Kubuntu 18.04 to Windows 10. I was using "Both Shift together" as my main shortcut for switching keyboard layouts and when I disabled that, Teamviewer started working. So maybe you want to investigate in that direction.
Following solves this issue https://automatthias.wordpress.com/2008/06/03/ctrl-key-not-working-in-vnc/
dconf write /org/gnome/settings-daemon/peripherals/mouse/locate-pointer false
Shift+Tab doesn't work either in from Ubuntu 18.04 to Win 10. Started looking for an alternative...
I've had it with TeamViewer. With recent outages are a factor as well as this and such flakiness in achieving an unattended connection reliably.
Moving to **Third Party Product**. As I have several remote clients now running both teamviewer and **Third Party Product**. When TV fails (very often), **Third Party Product** can still make a connection. So it's not my config.
Edit. Oh look. The competitor's name has been automatically redacted. Well that just about says it all. It's **Third Party Product**