Package Details: vmware-horizon-client 2406-2

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://customerconnect.omnissa.com/downloads/info/slug/desktop_end_user_computing/vmware_horizon_clients/horizon_8
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: 55
Popularity: 0.124421
First Submitted: 2015-01-08 15:17 (UTC)
Last Updated: 2024-08-20 07:04 (UTC)

Dependencies (25)

Sources (5)

Latest Comments

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

eworm commented on 2022-10-21 12:45 (UTC)

I do not think this is something I can change... No source available. :-p Complain to VMware if this bothers you.

andutra commented on 2022-10-21 12:21 (UTC)

Hi, It's not a big problem, but when I am using Dark Mode on my system, if I enter on VmWare Horizon Blast Configuration for example, the fonts use the same color that the background so, it's impossible to read. Maybe you can update it in the future.

eworm commented on 2022-07-25 19:01 (UTC)

Updated... Please give it a try. This now has an optional dependency on ffmpeg4.4, which shrinks the package size and should fix VAAPI.

beauhilton commented on 2022-07-22 03:43 (UTC)

FYI: 2206 just came out (https://docs.vmware.com/en/VMware-Horizon-Client-for-Linux/2206/rn/vmware-horizon-client-for-linux-2206-release-notes/index.html#whats-new)

roketscyntist commented on 2022-07-18 10:17 (UTC) (edited on 2022-07-18 10:18 (UTC) by roketscyntist)

Putting this here in case it helps anyone. There's probably a better way to fix this, but this helped to get me up and running. If VAAPI is configured on my system, I cannot open my remote machine at all. Authentication is fine, but as soon as it tries to display my remote machine it just closes. I poked around in /lib/vmware/view/ and noticed that it has libraries libavcodec.so.58 and libavutil.so.56 in software/ vaapi/ and vaapi2/. I installed ffmpeg4.4, removed all copies of those two libraries in /lib/vmware/view/, and replaced them with symlinks to /lib/libavcodec.so.58 and /lib/libavutil.so.56 respectively.


cd /lib/vmware/view/
ls -l vaapi
lrwxrwxrwx 1 root root 21 Jul 18 11:35 libavcodec.so.58 -> /lib/libavcodec.so.58
lrwxrwxrwx 1 root root 20 Jul 18 11:35 libavutil.so.56 -> /lib/libavutil.so.56

ls -l vaapi2
lrwxrwxrwx 1 root root 21 Jul 18 11:44 libavcodec.so.58 -> /lib/libavcodec.so.58
lrwxrwxrwx 1 root root 20 Jul 18 11:44 libavutil.so.56 -> /lib/libavutil.so.56
ls -l software
lrwxrwxrwx 1 root root 21 Jul 18 11:45 libavcodec.so.58 -> /lib/libavcodec.so.58
lrwxrwxrwx 1 root root 20 Jul 18 11:45 libavutil.so.56 -> /lib/libavutil.so.56

user108 commented on 2022-07-04 15:16 (UTC)

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?

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!

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