On Mon, Jun 8, 2015 at 8:47 AM, Duncan <1i5t5.dun...@cox.net> wrote: > 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.
Thanks Duncan. I'm going to try this path and see how it works out. Cheers, Mark ___________________________________________________ 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.
