[kde-linux] Desktop switching when Virtualbox is full screen

[Duncan]

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

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 
real one.

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, 
xdotool.

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 
don't. =:^)

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