VMware's View client (the proprietary version from Ubuntu's partner repository -- also a download link at https://my.vmware.com/web/vmware/info/slug/desktop_end_user_computing/vmware_view_clients/1_0?rct=j&q=&esrc=s&source=web&cd=1&ved=0CCIQFjAA&url=http://www.vmware.com/go/viewclients&ei=LrlgUJ74O4a68ATHgoGQCg&usg=AFQjCNHY-AdufYBzKgOXiezd-gJjcX0R2w) does not register keyboard or mouse input in the remote desktop session when using PCoIP under KDE. I can click on the application menu and send Ctrl+Alt+Delete to the remote machine, but clicks and keyboard input inside the screen don't do anything at all. I don't know if RDP acts any differently. It's disabled at my organization. The client works if I select Unity as my desktop environment instead (same computer, same user account). I'm not sure if this is directly Kwin's fault though, that was just an educated guess on my part. I'm using the version of KDE from Ubuntu 12.04's repositories, AMD64 architecture. Reproducible: Always Steps to Reproduce: 1. Launch VMware's View client. 2. Connect to a VDI server. 3. Select the virtual desktop and be sure to use the "PCoIP" protocol. 4. Try clicking in the remote desktop window or typing. Actual Results: When clicking or typing inside the remote desktop view, nothing happens. Expected Results: Clicking the "OK" button or pressing Enter should allow me to get past my organization's legal message. Instead, nothing happens.
please figure out whether it is related to KWin. Best do so by starting a different window manager - maybe openbox (probably not use Compiz just to be sure, that there are no Unity hacks).
Martin, I have determined that the cause is not KWin. To test this: 1. Immediately after logging in, installed the openbox package. 2. When installation finished, ran `openbox --replace`. Openbox took over as the window manager (title bars changed). 3. Logged into VPN. 4. Ran the VMware View client as before with the same results as before. Keyboard and mouse input is not recognized.
please post / attach the output of "xprop" (click the vmware window when the cursor turns into a cross)
Created attachment 74151 [details] Output from running xprop on the VMware View proprietary client. I removed a few personally identifying details from the output (window title and hostname) but it is otherwise unchanged.
doesn't matter - what i wanted to see is there and it's not the source of the bug. how does it behave under a "pure" openbox session (ie. no KDE but naked X11 and openbox)
Under a pure openbox session, the VMware View client behaves as expected. It accepts keyboard and mouse input without an issue.
I'd say "odd", but that doesn't cut it. Wild guess: what happens if you launch the vmware client with adjusted environment settings (hiding from it that this is a KDE session) KDE_SESSION_VERSION= KDE_FULL_SESSION= DESKTOP_SESSION= vmware-view
While logged in to KDE, ran the following in Konsole: $ unset $(env | grep KDE | awk -F= '{ print $1 }') $ unset DESKTOP_SESSION $ vmware-view Verified that the environment was okay by checking /proc/$PID/environ. Got the same result as before -- the client does not accept keyboard and mouse input.
Another wild guess - do you have mouse gestures enabled? ("kcmshell4 khotkeys", press settings) - in doubt try shutting down the input actions daemon ("kcmshell4 kded")
kcmshell4 was not running on my system. Killing kded did not solve the issue. I did try a few other things on my own. First, I noticed that KDE is setting a punch of X11 properties like one would do through .Xdefaults (run `xrdb -query` to see them). Openbox, I noticed, did not have these properties set. I thought maybe one of those could be doing weird stuff, namely: "ml*focusPolicy: pointer" (though I have no idea what that option actually does). I ran `xrdb -query | awk -F: '{ print $1 }' | xargs xrdb -remove` to clear that property set, which did not solve the issue. I also noticed something strange. Normally in any window, I can hold down alt and click / drag on any part of any other window to move it around. If I focus vmware-view, and try using the alt click / drag method, it doesn't work. So it's almost like my input is being trapped and it just isn't going anywhere. That made me wonder if maybe there was just some funniness with the client redrawing the screen. I tried to send some input to the remote machine (which, from a previous session, had vi open in a cygwin terminal) and then maximized VMware View. This forced the screen to redraw, but nothing in the vi session changed. So that eliminates a few more things from my potential list of suspects, though I admit that I don't have the best understanding of how all the pieces fit together.
(In reply to comment #10) > kcmshell4 was not running on my system. It's no daemon, but a tool to load config dialogs directly (instead of clicking your way through systemsettings) > I did try a few other things on my own. First, I noticed that KDE is > setting a punch of X11 properties interesting bug likely unrelated (i think i's mostly to configure colors for motif/athena/tk apps) > namely: "ml*focusPolicy: pointer" (though I have no idea what that option > actually does). me neither, but i doubt that "ml*" matches "vmware-client" ;-) Could be http://www.mltframework.org/ > I also noticed something strange. This is the by far more interesting part. - when you obtained the xprop, did you so by clicking the non working area in the vmware client or the working (GUI frame or titlebar) one? - i guess you can still alt+lmb on the interactive GUI frame? - when you click the "dead" area, does the click reach through to the window below (ie. right click causes the context menu of the desktop or you could left click a button below or scroll some viewport with the wheel) > I focus vmware-view, and try using the alt click / drag method, it doesn't > work. You don't even have to focus the window first. Does the cursor turn into the direction cross? If not, that means either - the window is not movable at all (also not using the titlebar) - there's an unmanaged client on top which intercepts the event - or the window is input shaped, ie. you actions simply pass through (and alt+lmb does oc. not work on the desktop)
I have the same problem and found a workaround today: Do not use the oxygen-gtk theme for GTK applications. For me it work fine using Qtcurve or Clearlooks.
passing on the bug then. @Hugo see comment #12 apparently the gtk style breaks vmware input handling
@Patrick, and John, could you try disable the window dragging feature from oxygen ? go to oxygen-settings, in Window's drag Mode, select: "Drag windows from titlebar only". Does that help ?
No, selecting "Drag windows from titlebar only" do not solve the problem.
@Patrick Thanks ! Next test, if you don't mind. Could you try again after setenv OXYGEN_DISABLE_INNER_SHADOWS_HACK (e.g. export OXYGEN_DISABLE_INNER_SHADOWS_HACK=1 or setenv OXYGEN_DISABLE_INNER_SHADOWS_HACK 1 depending on your shell ? ) Thanks in advance, (PS: I will do the test myself whenever I have some time for it, but you might get there faster than I) Hugo
This not work with OXYGEN_DISABLE_INNER_SHADOWS_HACK=1 too. I want to add a point to the problem description. When using a gtk theme the mouse cursor icon immediatly change to the icon defined in the VM as soon the mouse enter the View window. Keyboard input is send to the VM as soon the cursor change. Using oxygen-gtk the icon do not change when flying over or clicking in the View window. Unfortunately View as no "grab cursor" function as in other product.
@Patrick ok thanks for testing. I'm out of idea for the moment (for you to test). I'll try on my own ASAP to investigate further. Sorry for the trouble and thanks for the patience.
I can confirm the workaround changing from oxygen-gtk to QtCurve solves the problem. If you need any debug information I can provide also.
@reporters What if you set oxygen-gtk as current theme, but rename/remove /usr/lib/gtk-2.0/2.10.0/engines/liboxygen-gtk.so? Does the problem still reproduce (this checks whether bug is in C++ code or in gtkrc)?
I renamed /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so which also seemed to fix the problem. I am running Kubuntu 12.04 64-bit. Doing this seems to leave the oxygen-gtk theme working but fixes the problem with vmware view. Also vmware view is the only unthemed program that I see initially.
I can also confirm that vmware-view work with oxygen-gtk theme set and after renaming /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so
@reporters OK, it seems I've reproduced this with an open test server. Could you confirm that downloading latest master of oxygen-gtk2 and feeding cmake with "-DDISABLE_SIGNAL_HOOKS=1" option, compiling & installing works around the bug?
For the record: the offending hook is "style-set" signal hook. Disabling it alone makes it work.
@Ruslan style-set is used for two things: argbhelper, and window manager. Can you double check whether or not disabling window manager (window grab) fixes it ? (it really looks like this guy should be the issue, since it is grabbing mouse events for moving the window around). thanks ! Hugo
@Hugo Yeah, it's window manager who makes things bad, and I've almost found how to fix the bug. I think I'll blacklist GtkPlug from window manager support, due to the nature of such widget, user interaction with which is intended. I didn't check whether disabling drag by empty space helps, because the test server makes me wait 10-15 minutes between reconnects, but I guess we should later make sure that disabling this feature stops window manager from connecting any hooks. Now have to wait another 15 minutes to try next steps :)
Git commit 821e6d4709a892270d0501a6e59222e2ca873e73 by Ruslan Kabatsayev. Committed on 20/10/2012 at 23:28. Pushed by kabatsayev into branch '1.3'. Blacklist GtkPlug for window manager M +1 -0 src/oxygenwindowmanager.cpp http://commits.kde.org/oxygen-gtk/821e6d4709a892270d0501a6e59222e2ca873e73
Aaaand... this one-liner fixes the bug :)
Git commit 980bd38e5ddbf99e27736ab41cd50b430189d209 by Ruslan Kabatsayev. Committed on 20/10/2012 at 23:54. Pushed by kabatsayev into branch '1.3'. Don't set any hooks in window manager if window drag is disabled M +5 -2 src/oxygenwindowmanager.cpp http://commits.kde.org/oxygen-gtk/980bd38e5ddbf99e27736ab41cd50b430189d209
This bug also affects my computer: KDE: version 4.10.2 Kernel: version 3.5.0-29-generic #49~precise1-Ubuntu x86_64 x86_64 x86_64 GNU/Linux VMware Horizon View Client: version 2.0.0, build 1049726 GTK+ version 2.24.10 Glib version 2.32.4 Changing from GTK to QtCurve under: System Settings -> Application Appearance -> Style -> Widget Style Did not fix the problem. The mouse cursor doesn't change to the VMWare sessions mouse cursor when putting the mouse over the VM's window. Clicking on the window does nothing. Keyboard input does not work in the VMWare session window. It does work on the title bar and in the menu bar for the VMWare session window. Pressing the alt button on the keyboard plus the left mouse button does change the cursor to a cross and does allow me to drag the window arround any where on the VMWare window session including the title and menu bars. I'm not experienced enough to understand how to apply the fix you have posted. I can not locate any files on my system called oxygenwindowmanager.cpp. The fix as posted isn't quite clear enough to me. Do I still need to download the latest master of oxygen-gtk2 and feed cmake with the "-DDISABLE_SIGNAL_HOOKS=1" option, then compiling & install it? Or is there an upstream release? Or am I just supposed to add the line M +5 -2 src/oxygenwindowmanager.cpp ...to a source file someplace? Note: I need to get this working today so I can access the homeowrk files on my school account that are due tomorrow. The school is closed today so the only way I can get my files is through VMWare. If nothing else works, I can still use VirtualBox to load a Windows 7 instance and run VMWare through that machine, but I'd rather get this working in Kubuntu then to have to work that way. Thanks in advance for any help you can offer.
you need to change the gtk+ style, not the Qt one. either ubuntu provides a systemsettings plugin for this or you can use gtk-chtheme or similar. start vmvare after the change. i'd though expect ubuntu to ship the fixed version of oxygen-gtk
You should be able to have latest oxygen-gtk release work out of the box. But, Ubuntu Precise comes with outdated version of oxygen-gtk, 1.2.2, while this fix is first released in 1.3.2. So, you'll have to compile latest version from source. (see https://projects.kde.org/news/212)
Thomas: Changing that setting didn't seem to work. In Kubuntu I tried the following as you have instructed: Made sure I was disconnected from the VMWare session, and that the VMWare software was closed and shut down. Then: Kicker --> System Settings --> Application and Appearance --> Style --> Widget Style --> gtk+ style Applied the settings, Closed the System Settings Window, Reopened VMWare and connected to my school session, and the mouse and keyboard still behave as if they are dedicated to the host OS and no input from either the mouse or the keyboard is registerd in the VMWare session. Ruslan: For the two links you provided: oxygen-gtk2 - version 1.3.3 and oxygen-gtk3 - version 1.1.3 1.) Do I still need to feed cmake the "-DDISABLE_SIGNAL_HOOKS=1" option in order to get the mouse working in VMware or do I just compile using a straight cmake command? 2.) Should I compile and install both of them? Thanks.
(In reply to comment #33) > For the two links you provided: > oxygen-gtk2 - version 1.3.3 > and > oxygen-gtk3 - version 1.1.3 > > 1.) Do I still need to feed cmake the "-DDISABLE_SIGNAL_HOOKS=1" option in > order to get the mouse working in VMware or do I just compile using a > straight cmake command? > 2.) Should I compile and install both of them? > > Thanks. 1) No, it should work out of the box 2) You need only gtk2 version. But first I'd recommend removing gtk2-engines-oxygen so that any Ubuntu upgrades wouldn't overwrite the version you'll compile.
Thomas: Using the gtk+ style didn't work either. What I did: kicker --> System Settings --> Application Appearance --> Style --> Widget Style --> Gtk+ Style same problem as before, the mouse and keyboard behave as if they belongs to the host OS, and no input from either one is registered in the VMWare session. Ruslan: Thanks for the links. I tried compiling and installing both of them using the "-DDISABLE_SIGNAL_HOOKS=1" option but neither one fixed the problem. It is still persistent. Here is the order I tried things in: 1.) I downloaded the oxygen-gtk2 - version 1.3.3 release you gave me a link for in comment 32. I saved the file, read the INSTALL file, and did as it instructed: cd oxygen-gtk mkdir build cd build cmake -DDISABLE_SIGNAL_HOOKS=1 ../ make -j2 sudo make install No error messages received and everything looked good so I logged out and back in to the Kubuntu session to make sure the installation settings were applied, then started up the VMWare software and connected to my school session and the same problem persists. No mouse or keyboard input recognized by the VMWare session. (Note: Using PCoIP) I then tried the same steps again only this time using oxygen-gtk3 - version 1.1.3 and during the cmake step for this file, I got a warning saying that -DDISABLE_SIGNAL_HOOKS=1 was not going to be used because it didn't allow user hooks or something like that. I went ahead with the install anyway, and of course got the same problem in VMWare after logging out and back into my Kubuntu session. Questions: 1.) Did I do something incorrectly or out of order? 2.) Is there anything else I can do or try?
Update: Ruslan: Completely removing "gtk2-engines-oxygen" from synaptic package manager and reinstalling the oxygen-gtk2 - version 1.3.3 without the -DDISABLE_SIGNAL_HOOKS=1 from the link you provided in comment 32, did the trick. The mouse now behaves as it should under VMWare. Thank you for clarifying the fix. Getting my homework done now. :)