Arch Linux User Repository

I cannot make folder sharing work. The menu is completely grayed out and inaccessible. Logs have no clues too.. Have someone managed it to work?

I am running the znver2 kernel from the AUR, and every time I try to load into my client desktop, vmware-view opens and then immediately shuts down. Running vmware-view from cmdline does the same with no output. I am not sure where it logs events to start troubleshooting. As a side note, this version runs fine, albeit a bit slow, on the LTS kernel.

A couple notes on the behavior of the sticky keys bug in 2203.

Open a terminal window and run xev. If you hold down <kbd>Control_L</kbd>, it should send a single KeyPress event:

KeyPress event, serial 35, synthetic NO, window 0x8200001,
    root 0x7ab, subw 0x0, time 1764406, (246,442), root:(1210,497),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

and then when you release it, you'll get a KeyRelease event:

KeyRelease event, serial 35, synthetic NO, window 0x8200001,
    root 0x7ab, subw 0x0, time 1764965, (246,442), root:(1210,497),
    state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

However, once I connect to a virtual desktop through Horizon and interact with the desktop in any way, I get this neat behavior only on the virtual desktop. If I try repeating it on the parent OS, I get a series of alternating KeyPress and KeyRelease events at incrementing (Press, ~40 time units delay, Release, KeyPress, repeat) time values. It's not that <kbd>Control_L</kbd> is not registered - it's that Horizon somehow messses turns the pressed down state into a series of events.

I've replicated this bug with <kbd>Control_L</kbd>, <kbd>Control_R</kbd> and <kbd>Shift_R</kbd>. Other keys don't seem to be affected.

This persists after shutting down Horizon and until I log out of my X11 session.

I'd appreciate any tips, even on where to report this to :(

The "sticky keys" issue (once CTRL is pressed on the virtual machine, it ceases to function in the parent OS) is still present for me on 2203.

@eworm great news finally, thanks for sharing! and i can confirm it finally works!

VMware just released a fixed version, I already pushed the changes. Go and get it!

I have a non-public test release (2111.1 / 8.4.1 / build 53939787) from VMware that is said to fix the keyboard issue. To date I could not proof any different... So stay tuned for the next release!

@KorvinSilver. Can you try adding the argument --no-sandbox to the .desktop file for VMWare Client? I had a similar issue with another application and this may serve as a stop gab solution until a more permanent one is found.

I guess that's a new security feature from KDE/Plasma, where all launched applications are sandboxed in a systemd service. Looks like this breaks the horizon client. I do not have KDE/Plasma here, so no idea what breaks.

I updated my system and after reboot vmware-view won't run anymore unless I start it from the terminal. I'm using KDE/Plasma and if I click on its icon, KDE shows the cursor animation for the launch for a second then nothing happens. If I run it from terminal or set the shortcut settings to include run in terminal, it works. journalctl shows this only at the time:

Feb 18 08:46:31 atsuko plasmashell[1466]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:366: Unable to assign [undefined] to QString
Feb 18 08:46:31 atsuko systemd[1026]: Started VMware Horizon Client.
Feb 18 08:46:31 atsuko plasmashell[1466]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:366: Unable to assign [undefined] to QString
Feb 18 08:46:31 atsuko kwin_x11[1108]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 62967, resource id: 52429075, major code: 18 (ChangeProperty), minor code: 0
Feb 18 08:46:31 atsuko kwin_x11[1108]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 63187, resource id: 52429076, major code: 18 (ChangeProperty), minor code: 0

So basically systemd says it's started but somehow it closes or crashes without a trace I could find. The other lines show up with everything else I start like this so unsure if they mean anything here. The exact same thing happens with nbtexplorer-bin by the way also from the AUR. No idea what that means or even what could be responsible. I have other things installed from AUR but everything else works properly. Also if I start it from terminal, there's no systemd message for it in the log.