virtualbox.org

HOST OS:
Fedora 25 (4.10.14.200)

GUEST OS:
Ubuntu 17
Windows 10 (Creators)

VirtualBox:
Version 5.1.22
Extension Pack 5.1.22
Guest-Additions Installed: Yes on both guest OSes

Issue:
None of the guest OSes that I've used so far (Ubuntu, Windows 10, also WIN XP but very briefly) are able to make use of any of the keyboard hotkeys that my host OS has set. Using the super key does not bring up the start menu in any OS aside from the host OS (Fedora 25), alt+tab, alt+f4, super+d, super+e do not function in any OS but the host. Replacing these keys with the HOST key (right alt on my setup) does not yield different results.

Notes:
It is noteworthy that the other OSes do not respond in suppliment, either. They do not get a chance to catch the command.
My other machine, Windows 10 host OS with CentOS, MS Win Server 2012R2, and Fedora 25 works flawlessly. When in a guest OS, keyboard and mouse is properly captured and all shortcuts work in guest OS. Use HOST key to return keyboard and mouse capture to host OS.

Temporary Solution:
This is somewhat resolvable by using dconf-editor on the host OS (fedora) to change or remove the affected hotkeys (all of them). Doing this restores the full functionality for each modified keyboard shortcut. This 'solution', however, is entirely cumbersome and frustrating and would need to be repealed and restored before and after guest OS uses.

Reproduceability:
Due to a change in partition planning, I wound up reinstalling the HOST OS on this machine, as well as the extension pack, guest OSes and the vbox-additions. The issue is still present on this machine with a fresh image and latest updates.

This is due to Qt, the multi-platform, graphical front end library used for the GUI. It has some keys reserved. And it's hardcoded unfortunately. On my OSX host, I can't use several important shortcuts, like Cmd+Q (quit) and Cmd+H (hide). Or if I set Cmd+Opt+, for system preferences on host and guest, the host has priority. C'est la vie...

And if you think about it, you want the Quit shortcut (or some other special shortcuts) to be directed first to the host, in case the guest gets stuck and all your shortcuts are getting "lost". Then you lose both guest and host.

This sounds like this bug https://bugzilla.redhat.com/show_bug.cgi?id=1285770 in weyland.

I'm running Arch host with Gnome DM (like Fedora afaik) and Windows key will not work in any VM - it is routed to host.

If I use xorg not weyland virtualbox works fine.

This was the solution. After switching from Weyland back to X-Org the keyboard integration works wonderfully. Kudos, sir! I am grateful for this piece of advice!