| Summary: | AltGr mapped to Ctrl as modifier prohibits invocation of tabbox (but performs single step tabbing) | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Radix <tobyslight> |
| Component: | tabbox | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Slackware | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Radix
2015-08-13 11:52:32 UTC
Just to be sure: you actually press AltGr + CapsLock, right? Is this also a problem with the unmapped ctrl keys, ie. if you press R_Ctrl+CapsLock resp. even R_Ctrl+Escape (all keys references meant "physical") Can you trigger other shortcuts with this combination (eg. show krunner or whatever)? If not, what happens instead? (In reply to Thomas Lübking from comment #1) > Just to be sure: you actually press AltGr + CapsLock, right? That's correct. > Is this also a problem with the unmapped ctrl keys, ie. if you press > R_Ctrl+CapsLock resp. even R_Ctrl+Escape (all keys references meant > "physical") Sorry, I'm not sure what you meant by unmapped ctrl keys. Do you mean the Physical Ctrl keys (which are now Super keys with my Xmodmap)? I actually have them mapped to go back and forth through Activities with Escape and shift-esc respectively, and that works as expected. I also have Alt-Esc and Alt-Shift-Esc mapped to task switch the windows of an application, and that also works as expected on both sides of the keyboard. It's just the remapped ctrl keys that are causing the issues. Also, worth noting, is that if I use a default map (ie: without my Xmodmap) then Ctrl+Esc works as expected both sides. There is something that breaks it by remapping right ctrl to Alt-Gr... But as I said before, I haven't had this issue with any other window manager (Xfwm, fvwm2, cwm, wmaker, fluxbox, openbox, spectrwm and whatever the Gnome one is!). > Can you trigger other shortcuts with this combination (eg. show krunner or > whatever)? > If not, what happens instead? Yes. I just tried mapping krunner to Ctrl+Esc and it worked as expected with both (virtual) Ctrl keys (physical Alt and AltGr). > Also, worth noting, is that if I use a default map (ie: without my Xmodmap) then Ctrl+Esc works as expected both sides. That's what I wanted to know, yes. > I just tried mapping krunner to Ctrl+Esc and it worked as expected with both (virtual) Ctrl keys (physical Alt and AltGr). Ok, means the shortcut (very likely) gets invoked, but kwin shuts down the tabbox. => areModKeysDepressed() will return false, thus trigger the single stepping. Probably because areKeySymXsDepressed() is out of sync with the Qt key event (one taking xmodmap into account, the other doesn't) Archiving the problematic xmodmap (please don't use pastebin for bug-related stuff): ----------------- keysym Alt_L = Control_L keysym ISO_Level3_Shift = Control_R keysym Super_L = Alt_L Meta_L keysym Print = Alt_R Meta_R keysym Control_L = Super_L Hyper_L keysym Control_R = Super_R Hyper_R keysym Caps_Lock = Escape keysym Escape = Caps_Lock keysym XF86WakeUp = Menu clear control clear lock clear mod1 clear mod4 clear mod5 add control = Control_L Control_R add lock = Caps_Lock add mod1 = Alt_L Meta_L Alt_R Meta_R add mod4 = Super_L Hyper_L Super_R Hyper_R I assume the issue is in Qt5, eg. try to use the 3rd level shift to enter a char in either a Qt4 or a Qt5 client. (Restarted) Qt4 works (eg. "phy_ctrl + +" => ~ on qwertz but Qt5 doesn't (no output at all) Same on your side? The relevant code in kwin to figure out whether a modifier is hold got ported from XLib to XCB during the switch to Qt5. This means that it is possible that the problem got fixed. As we no longer maintain 4.x I am setting this bug to unmaintained. |