Re: [kde-linux] Desktop switching when Virtualbox is full screen
- Date: Mon, 8 Jun 2015 15:47:03 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde-linux] Desktop switching when Virtualbox is full screen
Mark Knecht posted on Mon, 08 Jun 2015 06:31:33 -0700 as excerpted:
> Is there a way for KDE to _always_ grab specific keyboard shortcuts?
> My KDE-4 setup runs 3 monitors set horizontally with 6 desktops. I
> scroll between monitors and can switch between desktops using
> Ctrl-F1..F6. Currently I'm needing to use a number of Windows dual
> monitor VMs running full screen. Unfortunately when Windows is full
> screen in the VM monitors #1 & #2 are completely taken up and the
> desktop switching shortcut doesn't work. I have to scroll my mouse to
> monitor 3 which is still KDE to use it, or momentarily take the VMs out
> of full screen and position my mouse over desktop area.
> I understand that generically the shortcut is likely being passed
> Windows and dumped as it probably has no defined function in the
> programs I'm running there but I'm wondering if there's a way for KDE to
> always take specific shortcuts and not pass them down to running inside
> of KDE?
From what I know and have observed, xorg's global keyboard handling, as
you suggest, consists of a list of running apps that have told xorg they
want subscribed to that list. The problem is that each app in that list,
after seeing the key itself, can either pass it on to the others, or
"swallow" it, so it doesn't get seen by any others on the list, or by
whatever active application the keys get sent to after they've dropped
thru the list.
So what you need to do is control the order of the apps on that list.
I'm not /sure/ of this, but based on what I've observed at least, the
order is based on when the app was started. Apps get placed on the top
of the list when they request to be added to it, pushing others down, so
the last app started gets first dibs on keys.
If that is indeed correct, then what you will need to do is either start
the VMs earlier in the X startup process so they get on the list first
and pushed down when kde's listeners get there, which I think is going to
be a bit difficult to do and may have other consequences, OR restart the
kde listeners AFTER the VMs in question, so kde's listeners are at the
top of the stack and get first dibs on the keys. That might actually be
The other alternative would be to work around the problem using a third-
party hotkey app like sxhkd (simple X hotkey daemon), which I happen to
run here in ordered to listen for and trigger actions based on touchpad
gestures. The way that works is that the touchpad driver translates
those gestures into high-number (8-20, IIRC) "mouse button" push events.
sxhkd then listens for those high-number mouse button events, and
triggers other actions based on the event, what app is active, etc. This
works well because sxhkd is started with kde, but later than kde's own
stuff, so it's top of the notification stack and gets first dibs on keys,
including mouse buttons. One nice thing about sxhkd is that it can be
configured per-event to either swallow that event, or pass it on to
others further down the stack and ultimately to the active window.
You could configure sxhkd (or alternative app, xbindkeys is another
powerful alternative in the category) in one of two ways. You could
either have it respond to the key directly, or more likely given what
you've described, have it listen for one key, and emit a different one --
perhaps one of the many available "extra inet and media keyboard keys",
choosing one that your keyboard doesn't actually emit on its own, and
then configure kde's hotkeys to respond to that "fake" key, emitted by
sxhkd in response to the real event that triggered it.
The idea would be to find an available "fake" key that you're not using,
that the VM doesn't swallow, so that you could effectively bypass the VM
layer, by having sxhkd trap the real trigger and emit the fake one, which
the kde listener is actually configured to respond to in place of the
As I said, I do something rather similar here, with the touchpad driver
programmed to emit high-number mousebutton "clicks", which sxhkd then
intercepts and acts accordingly based on the "mouse button" aka touchpad
gesture I did and various things like active and running windows,
depending on how it is programmed for that specific "mouse button". Many
times, I actually have it simply emit other keys using another app,
For instance, the touchpad pinch gesture is set to trigger kde/kwin's
zoom feature by emitting the keys I have kwin zoom configured to use,
regardless of what's active, while what the rotate gesture does depends
on the active window -- if it's gwenview, it emits the keystrokes that
are configured in gwenview to rotate the displayed image, if it's some
other graphics app, it might issue other keys to get the same effect,
while if it's a non-graphics app, it might issue other keys that do
something specific in that app. Meanwhile, as I have things configured,
two-finger swipes are reserved for scrolling (both vertical and
horizontal are setup, that's pretty much default for two-finger swipes),
three-finger swipes for app-specific stuff like the back (3-finger-swipe-
left) and forward (right) and zoom-page (up/down) functions in firefox,
and four-finger-swipes for global functions, 4-finger-swipe-left
activates kwin's close-window function on the active window, for
instance, just as if I'd hit the X in the titlebar, while 4-finger-swipe-
down will either drag-lock or repeat whatever "mouse button" I trigger
next, and 4-finger-swipe-up cancels the repeat. That lets me trigger
pinch-to-zoom either once (just pinch in or out), or repeatedly for
continual zooming (4-finger-swipe down, pinch, 4-finger-swipe-up when I
want to stop).
And... I just realized I actually have 4-finger-swipe-right set to
trigger a desktop switch, almost exactly as I described for you, sxhkd
catches the "mouse button" and fakes the hotkey I have kde configured to
use for desktop switch. Now I can desktop-switch without having a bare
desktop to scroll over, faking the win-Fx key I have setup to do the same
thing, if I'm using the mouse and not the keyboard at that moment. =:^)
You'd set it up exactly the same way, except using a keyboard shortcut
instead of the touchpad/mouse-button event I use, with sxhkd listening
for one shortcut that the VMs swallow, and faking another one that they
The problem then is down to simply installing sxhkd and xdotool, setting
up sxhkd to listen for the hotkey you want to use and to run after the VMs
that are causing the problem, and finding a key that the VMs don't
swallow to fake, that you can setup in kde to do the actual switch, and
in sxhkd to be faked using xdotool when you hit the real hotkey.
As for finding such unused keys to fake, check /usr/share/X11/xkb/
keycodes/evdev for a list. Try KEY_PROG1, for instance, which you'll set
sxhkd to emit with a call to xdotool key XF86Prog1, or similar.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.