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 ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
