SUMMARY If the extra mouse buttons are configured via kcm_mouse, on some occasions, the event is not carried out. It can also happen that actually a different key event is emitted, i.e. one that was configured for a different button. e.g. my kcminputrc right now is: [ButtonRebinds][Mouse] ExtraButton1=Key,Ctrl+PgUp ExtraButton2=Key,Ctrl+PgDown ExtraButton3=Key,Ctrl+W (btw, shouldn't these settings be in the device-specific part of the config file?) So kcm seems to generate the file correctly, the Button numbers and key combinations match what I set in the kcm. However, when I press one of the buttons, e.g. in a browser window (Falkon or Firefox), for Extra Button 1 and 3, it emits Ctrl+W, for Extra Button, nothing is emitted (it also doesn't do its default function "back"). This is persistent even after restarting the system. I'm not sure if kwin is at fault here or if it's the kcm, but something is not working as it should. bug 460345 looks similar, but is already fixed in the version I'm running. STEPS TO REPRODUCE 1. Use a mouse with configurable extra buttons (so at least 8 buttons?) 2. Assign key combinations to these buttons 3. Check whether the configured key combinations are emitted OBSERVED RESULT No or the wrong key combination is emitted in some cases. EXPECTED RESULT The configured key combinations should be emitted when a button is pressed. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.26.90 (I think it is also present on 5.26, but I'm not 100% sure.) KDE Plasma Version: 5.26.90 KDE Frameworks Version: 5.102.0 Qt Version: 5.18.8 ADDITIONAL INFORMATION I'm using a Logitech M705 mouse. This mouse has a total of 10 buttons, of which button 10 (the thumb button) is not used in a standard config. On X, I assign this button via imwheel to the key combination Ctrl+W to quickly close windows/tabs in certain programs like Falkon or Firefox. Additionally, I assign the left/right click of the scroll wheel to Ctrl+PgUp and Ctrl+PgDown to switch tabs in the browser. I never use the lef/right click of the scroll wheel to navigate left/right anywhere, so would be wasted functionality for me. Now obviously, imwheel does not work on Wayland anymore, so for Wayland I need a different solution. Fortunately, kwin seems to support configuring mouse buttons on Wayland, so I tried it. On Wayland, 3 extra mouse buttons are recognized. 1 and 2 are the buttons that are configured as forward and back in a standard config. Extra Button 3 is what is recognized as Button 10 on X11 and does not have a standard function assigned to it. I started with this button and assigned the key combination Ctrl+W to it. At first, this did not work at all, so at first I thought that this functionality is completely broken. I did later on investigate more and found that I also can set Extra Button 1 and 2 and so I tried that and came up with the configuration above. This is not exactly what I want, since I would have to give up the forward/back functionality, but it's better than nothing. However, I did then find out, that the behavior changed and now two buttons result in Ctrl+W, while Button 2 does nothing, as described above.
I just found out that Extra button 2 emits Ctrl+x, which is not something that I configured.
Ok, I think I just figured out why this is happening for me, but most likely not for others. First, I think there are actually two bugs here. The first is that I can configure Extra buttons 2 and 3 in the kcm separately, but kwin will always emit the same signal for both (that that was set for extra button 2). Should I open another bug report for this? The second bug is happening because I'm a user of the de layout in the variant 'neo'. As you can see here https://www.neo-layout.org/ this layout shuffles around a lot of keys and I think kwin is getting confused by that. I found the following Layout (Variant) German (Default): correct English (Default): correct English (Dvorak): correct German (Dvorak): correct German (Neo 2): Ctrl+PgUp -> Ctrl+x, Ctrl+PgDn -> Ctrl+w German (Bone): Ctrl+PgUp -> Ctrl+x, Ctrl+PgDn -> Ctrl+j German (Neo 2, QWERTZ): Ctrl+PgUp -> Ctrl+t, Ctrl+PgDn -> Ctrl+q German (Neo 2, QWERTY): Ctrl+PgUp -> Ctrl+t, Ctrl+PgDn -> Ctrl+q German (Aus der Neo Welt): Ctrl+PgUp -> Ctrl+adiaeresis, Ctrl+PgDn -> Ctrl+adiaeresis ??? So it's not just the keys that are moved around, but especially there seems to be some problem with Neo 2 and related layouts (Bone and "Aus der Neo Welt" are layouts that were done by people working previously on Neo 2). Note that in none of these layouts, the Ctrl, PgUp and PgDn keys are changed to something else. So the proper steps to reproduce would be: 1. Add German (Neo2, QWERTY) to layout switcher (suggest this one, as it leaves the normal key layout as is, in case you need to type 2. Set up an extra mouse button in kcm_mouse 3. Use wev to verify that the correct key combination is emitted 4. Switch to German (Neo 2, QWERTY) 5. Use wev again to check the key combination ??? This is what wev is telling me for "Aus der Neo Welt": [14: wl_keyboard] key: serial: 24630; time: 6488324; key: 37; state: 1 (pressed) sym: Control_L (65507), utf8: '' [14: wl_keyboard] modifiers: serial: 1; group: 0 depressed: 00000004: Control latched: 00000000 locked: 00000000 [14: wl_keyboard] key: serial: 24632; time: 6488324; key: 28; state: 1 (pressed) sym: adiaeresis (228), utf8: ''
Just wanted to add one more detail: If I remove all of the extra button bindings, button 1 and 2 are restored to their original functionality back and forward, button 3 does nothing, i.e. it doesn't imitate button 2.
Ok, so I've been able to do some tests with both Plasma 5.26 and 5.27 Beta (from the [kde-unstable] repository) on another system running another distribution (Arch Linux) with the exact same mouse (Logitech M705) as well as another model (Logitech Anywhere 2S). My observations: 1. I could not observe any difference between the two Plasma versions in this regard, so a regression seems unlikely. 2. I was not able to reproduce the keyboard layout problems. Independently of the layout, the same key events were emitted. So this could be a problem with my local system, I need to investigate. Right now I have no idea where this could be coming from. 3. The other part of the problem was reproducible with both mice. Some of the buttons, although recognized differently by the kcm, emit the exact same shortcut events as another button, even though they were set to something different. In some cases the shortcut events aren't triggered at all, although set in the kcm and present in kcminputrc. 4. Using solaar, I was able to switch the wheel left/right action from scrolling to extra buttons. I was able to assign those as well, but the same problem persists, I can assign them individually, but one of these two also emits the same shortcut as Extra Button 2 and the other one does not work at all (when setting a shortcut). btw, when assigning a mouse button, it fails to recognize the button press most of the time. I have to hit the button many times until it finally triggers. This is not a hardware problem, if I monitor the mouse using wev, every single button press is recorded.
Ok, I think I've got the layout thing figured out now as well. This happens only for some keys, like Page Up/Down. In my test on Arch I made the mistake to use a regular key (e.g. "e"). If I set the shortcut to Page Up, I get the same behavior described above on both systems. I also asked another person running kwin Wayland on Exherbo with a different mouse to test this and the result was the same.
FYI: I gave this merge request a spin: https://invent.kde.org/qt/qt/qtbase/-/merge_requests/239 The problem persists.
First, I opened bug 465463, since I think that I actually found two bugs at the same time and just wasn't sure whether they are connected or not. Now I'm pretty sure that they have nothing to do with each other. Here, I will only report on my findings with the key events when using non-standard keyboard layouts. I investigated this a bit further and I do think I understand now what is going on. I was especially surprised to find that kwin has problems with keys like the cursor keys or Page Up/Down, which are standard keys and are not modified by Neo 2 or any other of the mentioned layouts. These keys are defined by xkb in /usr/share/X11/xkb/symbols/pc, online link: https://github.com/freedesktop/xkeyboard-config/blob/master/symbols/pc#L61 key <INS> {[ Insert ]}; key <DELE> {[ Delete ]}; key <HOME> {[ Home ]}; key <END> {[ End ]}; key <PGUP> {[ Prior ]}; key <PGDN> {[ Next ]}; Now one special thing that Neo 2 invented and that was adapted by other layouts like adnw or l3 is that you have a second set of these keys (and others as well) when using the so-called "M4" modifier (which is Level5 in xkb), as shown here: https://dl.neo-layout.org/grafik/bilder-einzeln/flat/neo-4-tkl.path.svg This is a pretty handy thing for quickly moving in a text without needing to move your hands from the main keyboard keys, but it means there are now e.g. two keys with the entry Prior. These are defined in /usr/share/X11/xkb/symbols/de. Online link: https://github.com/freedesktop/xkeyboard-config/blob/master/symbols/de#L439 e.g. for Prior: key <AD01> { [ x, X, ellipsis, Greek_xi, Prior, Prior, Greek_XI, NoSymbol ] }; Now, I assume that kwin (or kwindowsystems, I'm not familiar with the code) will perform a lookup for these symbols and it will find the one in 'de' first. Thus, it will emit key <AD01> without any modifier, which for Neo 2 corresponds to the symbol 'x', which is exactly what I get when checking it with wev. Dvorak on the other hand does not introduce additional Prior/Next etc. keys, hence it's not affected, despite moving around a lot of keys. I assume the solution for this would be to always first check the symbols in 'pc105' as defined in the 'pc' file, since this is the basis for all layouts and then proceed with any additions on top of that.
Created attachment 156124 [details] Patch to only search the first two levels in a layout. In src/plugins/buttonrebinds/buttonrebindsfilter.cpp the symbol is converted to a keycode in line 291: // KKeyServer returns upper case syms, lower it to not confuse modifiers handling auto keyCode = KWin::input()->keyboard()->xkb()->keycodeFromKeysym(sym); This uses the function keycodeFromKeysym that is now in src/xkb.cpp. This function iterates over all keysyms and levels, in that order, returning the first match for the requested symbol. Restricting this lookup process to level 0 and 1 fixes the issue for me, since the doubled keys are on higher levels. I've attached that patch for reference. btw, I had to use both level 0 and 1, because I think the comment is actually false and there is no conversion to lower case. i.e. if 'A' is requested (and that is what is output by KKeyServer, even if 'a' was originally set), it will only find it if level 1 is searched as well. Unfortunately, this might not really be a desirable solution, since this makes symbols on upper levels unusable for shortcuts. The problem is that with the current design of the function, this won't work anyway, you will always only get symbols on level 0 as an output. Thus, even if an upper level symbol is set in kcm_mouse, it'll misbehave. For example, if you set # ('numbersign') in the standard US layout, you need to press Shift+3. kcm_mouse will correctly assign the character # to the mouse button and keycodeFromKeysym will correctly determine the key AE03 in this layout. However, the output will be '3', because the Shift to level 1 is omitted. Therefore, my proposal would be that keycodeFromKeysym returns both keycode and level, or, alternatively, a second search levelFromKeysymAndKeycode is performed to determine the correct level of the requested symbol on a specific Keycode. Unfortunately, my c++ skills are too limited to properly implement this. :(
I've changed the bug title to better match the actual problem.
I recently noticed that a change with commit id 1240ac1dfe4569f3bb5d5d182ae3c393dc2c5bd5 to buttonrebindsfilter was made due to bug 484367. This introduces processing of symbols from level1 and level2 of the layout. The problem described in this bug still persists however, since for the Neo layout (which I am using), keys on level4 (Page Up/Down) can match. FYI, the modifier definition is as such: include "shift(both_capslock)" include "level3(caps_switch)" include "level3(bksl_switch)" include "level5(lsgt_switch_lock)" include "level5(ralt_switch_lock)" (Note that I am not sure if the corresponding levels would then be level == 3 and level == 5. Might be 2 and 4 instead, but I'm unsure. :() I think, there are two options to deal with that: Option 1: in ButtonRebindsFilter::sendKeySequence, do not only check for level 1, but handle higher levels as well. Currently it only checks for level == 1 and ignores the rest: if (key & Qt::ShiftModifier || level == 1) { sendKey(KEY_LEFTSHIFT); } The problem with that is that, afaics, input-event-codes.h does not define a specific key associated with higher level modifiers. From a quick search, I also couldn't find definitions for those in Qt. So one would need to get them from xkb, if that is possible? Option 2: Basically the patch I posted above. It restricts the search to 2 levels. This works for me, but in some corner cases, where people try to set a button rebind accessing a symbol on level3, e.g. in the german layout AltGr + 7, which is {, would not be found. However, this would also be the case with the current code, as AltGr (=KEY_RIGHTALT) is not handled either. If that is an acceptable limitation, then the patch would be fine, I think.