Bug 200776 - Switching from krdc via alt-tab sends "alt key" to the remote desktop
Summary: Switching from krdc via alt-tab sends "alt key" to the remote desktop
Status: CONFIRMED
Alias: None
Product: krdc
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Urs Wolfer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-19 17:37 UTC by Marius
Modified: 2021-03-25 09:42 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marius 2009-07-19 17:37:45 UTC
Version:            (using KDE 4.2.4)
Compiler:          i686-pc-linux-gnu-gcc 
OS:                Linux
Installed from:    Gentoo Packages

As the title says, when leaving krdc via alt-tab, it sends and alt-key-pressed event to the remote desktop, but no alt-key-released event. When resuming work in the remote desktop, the alt key has to be pressed once to make the remote desktop notice that alt is no longer pressed.

Expected behaviour:
krdc should not send an event, when it is left via alt-tab.
Comment 1 Urs Wolfer 2009-09-11 22:35:36 UTC
How can you reproduce this issue (i.e. how can you see this behavior on the remote desktop)?
Comment 2 Diederik van der Boor 2010-01-18 15:18:00 UTC
I'm getting the same issues with KDE 4.4-rc1. Window switching keys are not taken by krdc. i.e.:
- Alt+F4
- Alt+Tab

Instead of closing a window within the session, the whole session window is closed.
Comment 3 Marius 2010-05-17 22:47:55 UTC
Sorry for not replying for such a long time. The issue still exists, though.

@ #2: have you tried to enable the option "grab all possible keys"? For me, your issue does not exist with that option.

With the option disabled, however, I can leave the remote session via Alt-Tab (which is expected behaviour, imho), but as stated in my first comment, I have the problem with the alt-key.

I get this problem e.g. when working via vnc on another linux box (didn't try rdesktop and windows). In the remote session a window is active, say Matlab. When leaving krdc via alt-tab and returning via alt-tab, the Matlab-Menu is active, and everything I type is handled as if the alt key was pressed. When I press e.g. "f", the file menu is opened. To "release" the alt key in the remote session I have to press the alt key once on my keyboard.

The issue does not occur when leaving krdc with the mouse via the taskbar, and returning via alt-tab.
Comment 4 Raine 2010-06-09 22:47:24 UTC
This bugs still exists. Ubuntu 10.04 64-bit with Gnome+Kde installed and working from Gnome desktop.

KRDC using RDP plugin.

KRDC with grab-all-possible-keys enabled on windowed/tabbed mode works just fine but on fullscreeen mode, even with grab-all-possible-keys enabled does not get the ALT-TAB event. In fact Gnome get this event and the window (KRDC) context get lost. Solution: exit fullscreen mode and re-enter it and not even thinking about using ALT-TAB on fullscreeen mode...

Come-on guys, this bug makes KRDC unusable to work with :(

Raine
Comment 5 Urs Wolfer 2010-06-12 11:20:11 UTC
(In reply to comment #4)

What does happen if you are running rdesktop from Konsole? Does also the desktop (= window manager) get these key events?
Comment 6 Alexander Wilms 2010-07-27 13:40:28 UTC
I can confirm that bug, using opensuse 11.2/11.3 with krdc-4.4.4.

rdesktop in full-screen mode started from shell does't show that behavior.

Yes, it's really an annoying feature... :-(
Comment 7 Frode Hatlevik 2010-12-08 09:22:29 UTC
This bug also exists on Debian GNU/Linux Squeeze. Or at least I suppose so.

Experienced behaviour:

I use KRDC to connect to Mac Mini's running Apple's native VNC server, a.k.a. 'Screen sharing'. After switching away from KRDC with 'ALT + TAB', and then back again, the keyboard input in the VNC session is really messed up. I get two caracters per keypress, and other wierd behaviour. Pressing the ALT key again sometimes fixes things. Sometimes I get different behviour in the different programs in the Mac Mini session.

+1 for annoying bug
Comment 8 Bzzz 2011-10-04 01:51:09 UTC
*** This bug has been confirmed by popular vote. ***
Comment 9 Paweł Pałucha 2013-02-12 09:43:20 UTC
Hi, I believe this is the bug in rdesktop and not krdc. Rdesktop checks and clears state of meta-keys only when receiving FocusIn event. It works fine when rdesktop is run as standalone application, but not when embedded in krdc. I filled bug (with proposed patch) to rdesktop: http://sourceforge.net/p/rdesktop/bugs/363/
Comment 10 Philippe Cloutier 2014-09-28 17:30:52 UTC
Can you reproduce with KDE SC 4.14.1 and freerdp? This seems a duplicate (at least partially) or bug 178015.
Comment 11 Philippe Cloutier 2014-11-25 04:22:20 UTC
I can reproduce this every time with krdc 4.14.1 and freerdp, but if and only if I go back to krdc using the mouse. If I use the keyboard, the Alt is considered released.

In other words, there is no problems if I leave and enter symmetrically - both using the keyboard or both using the mouse. It only happens if using the keyboard to leave and the mouse to go back.
Comment 12 Philippe Cloutier 2014-11-25 05:09:35 UTC
This also happens with Ctrl.

For example, this will show due to a conflict between VMware vSphere's pseudo-Ctrl+Alt+Del, Ctrl+Alt+Ins, and KDE's Ctrl+Alt+Ins (which, as I discovered due to this conflict, allows switching session). If one uses a remote vSphere console and tries to send Ctrl+Alt+Del to a remote host, the local KDE with catch the Ctrl+Alt+Ins and offer switching sessions. If one cancels that using Escape, the focus goes back to krdc, but Ctrl and Alt stick, even if they were released. This will likely cause the session to disconnect, since the next press on Enter may be interpreted as Ctrl+Alt+Enter, which causes krdc to disconnect.

This is a major annoyance for vSphere usage. There are workarounds:
Send the shortcut graphically (VM->Host-> Send Ctrl+Alt+Del)
If you forget and trigger KDE's shortcut, type Ctrl and Alt
Unfortunately, if KDE's shortcut can be controlled, I did not find where.

It is interesting to note that it's not just the remote session where Ctrl+Alt stick - Ctrl+Alt+Enter is a krdc shortcut, meaning krdc itself has Ctrl+Alt stuck.
Comment 13 Sektor van Skijlen 2016-07-05 12:53:53 UTC
This is still a problem. I like krdc (over gvncviewer) exactly because it switches desktops and windows of the main system on Alt-Tab and Alt- other keys.

There's still a problem with locked Alt key when I switch the krdc window to another window. The problem is, in particular, when I switch back and the whole desktop inside behaves as if the Alt key were pressed, even if it's actually not pressed (which changes the behavior of any key combination).

So I propose a solution: please make krdc on the event of "lose focus" (which may be a result of Alt-Tab), send the Key Release (or whatever it's called) events for Alt - as I can see above, probably the same can be required for Control, Shift and Meta. To prevent unnecessary flooding, it can simply record Key Press and Key Release events to update the modifier key state, and on Lose Focus event send Release events only to the keys that were remembered as currently Pressed.

If this can make things bad for anyone, you can make it an option - but really it shouldn't be harmful, as it's hard to imagine a situation when the window is NOT focused and any key is pressed.
Comment 14 Arek Guzinski 2018-07-29 09:08:21 UTC
bump!

this is still a problem (IMO the most annoying bug in KRDC) in 2018 (using current Neon).

If I find the time, I'll try to fix this myself next week or so. But since I don't know the source (yet), any hints on where to start and what problems this might cause are welcome.

Also... is this a bug in krdc at all, or is it maybe an issue in xfreerdp?
Comment 15 Arek Guzinski 2018-07-31 11:11:17 UTC
I tried to fix it but pretty much hit a wall with plugin loading.

this might be slightly off topic for a bug report, but...

when i try to debug krdc (per gdb or qCDebug) this only works for parts of it.
The problem is that the plugins (libkrdc_rdpplugin.so in this case) or always loaded from the system-installed krdc.
Of course I could to something like link from there to my compiled plugins, but I'd prefer not to pollute my system...

So... @developers: how do you set everything up for KRDC development?
Comment 16 Christoph Feck 2018-07-31 12:44:49 UTC
If you want an application to work outside of the standard /usr prefix, you need to set environment variables to point to the installed files. These are documented at https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source#Set_up_the_runtime_environment

With recent extra-cmake-modules versions, it is also possible to automate this, see http://www.proli.net/2018/06/29/easily-building-and-testing-kde-applications-into-a-separate-prefix/
Comment 17 Arek Guzinski 2018-08-14 08:40:10 UTC
Ok... so i looked at the code, played around and realized 2 things:

The bad:
I don't think this problem can be fixed in krdc alone. 
The solution Sektor van Skijlen proposed is how I'd try to solve it - but this can't be done because embedding another X application blocks most focus events from krdc.
Possible workarounds: 
  a) having kwin (or a kwinscript) notify krdc if the window changes via dbus.
     Contra: would depend on using a window manager that can do that - AFAIK this means kwin or xmonad.
  b) Monitoring xfreerdp for messages that hint at a focus change.
     Contra: might need modifiyng freerdp.
  c) Fixing whatever causes the lost focus events (possibly Qt - more likely X. And there is no way I'm touching Xorg code!)

Has anyone tested this on wayland? if so: whats the situation there?

The good:
the above isn't really necessary, as freerdp has already (mostly) fixed this :)
In my tests with the current version from git (2.0.0-dev4) keys are almost always properly released. Beeing a development version, of course, it has some quirks (like sometimes randomly grabbing all keys until you press right ctrl). But I found using it more pleasant than having to deal with unreleased keys.

In short: workaround = upgrade to current freerdp from git.

If anyone really can't use the git version I might be persuaded to implement a). Otherwise I'll consider it "almost resolved upstream". (is this enough to change status to resolved ?)

also: @Christoph Feck thanks for the links :). However this wasn't enough, as krdc would still load both versions of the plugin - and always use the wrong one :/.
I worked around it by placing these 2 lines at the start of MainWindow::loadAllPlugins()
    const QString badpath = QString::fromUtf8("/usr/lib/x86_64-linux-gnu/qt5/plugins");
    QCoreApplication::removeLibraryPath(badpath);
Comment 18 Elias Chatzigeorgiou 2019-11-12 14:07:23 UTC
Hi @Alex,

I am using 2.0.0-dev5 and still experiencing that issue

elias@ecdl15:~$ xfreerdp --version
This is FreeRDP version 2.0.0-dev5 (2693389a+debian)

Any suggestions ?
Comment 19 Mauro Molinari 2021-03-25 09:42:09 UTC
I still have this (really annoying) problem with KRDC 19.12.3 and xfreerdp 2.2.0 on Kubuntu 20.04.

The best workaround I could find is to disable global shortcuts for KRDC application, so that Alt+Tab goes to the remote system rather than being captured by Plasma. This has other advantages, but still the "out-of-the-box" experience is much affected by this problem.