Package Details: vmware-horizon-client 2312.1-1

Git Clone URL: https://aur.archlinux.org/vmware-horizon-client.git (read-only, click to copy)
Package Base: vmware-horizon-client
Description: VMware Horizon Client connect to VMware Horizon virtual desktop
Upstream URL: https://www.vmware.com/go/viewclients
Licenses: custom
Conflicts: vmware-horizon-pcoip, vmware-horizon-teams-optimization, vmware-view-client, vmware-view-open-client, vmware-view-open-client-beta
Replaces: vmware-horizon-pcoip, vmware-horizon-teams-optimization
Submitter: eworm
Maintainer: eworm
Last Packager: eworm
Votes: 53
Popularity: 0.62
First Submitted: 2015-01-08 15:17 (UTC)
Last Updated: 2024-04-09 12:41 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 17 Next › Last »

firemage78 commented on 2022-04-06 16:29 (UTC)

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.

Perfi commented on 2022-04-06 06:57 (UTC)

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 :(

Perfi commented on 2022-04-06 06:16 (UTC)

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.

jose1711 commented on 2022-03-15 21:48 (UTC)

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

eworm commented on 2022-03-15 15:10 (UTC)

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

eworm commented on 2022-03-08 13:53 (UTC)

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!

nihalani commented on 2022-02-18 20:48 (UTC)

@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.

eworm commented on 2022-02-18 09:06 (UTC)

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.

KorvinSilver commented on 2022-02-18 08:04 (UTC) (edited on 2022-02-18 08:07 (UTC) by KorvinSilver)

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.

kodur commented on 2022-01-26 20:29 (UTC)

Unable to get USB to initialize with VMware Horizon Client Version 2111 Build 8.4.0 (build-18957622).

2022-01-26 15:25:13.741-05:00: vmware-view 3233| CdkViewUsbCbFunc: callback called, reason=VIEWUSB_CB_ERROR, desktopHandle=0x5608cd452160, msgId=213, msgString="IDS_DROPDOWN_DEVICES_NOT_AVAILABLE" 2022-01-26 15:25:13.741-05:00: vmware-view 3233| CdkViewUsbCbFunc: Viewusblib callback called, open channel failed, desktopHandle=0x5608cd452160, usbAvailable=0.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 17 Next › Last »