moving to kde as I don't find the right component - KWin is not responsible for shortcuts

kglobalaccel has no component.
the problem here will be the modifiers (numlock)
for a passive keygrab *every* desired combo has to be demanded, so you usually end up taking alt+f2 and numlock+alt+f2

this will somehow fail.

@georg
try to toggle numlock off and see what happens

@martin: thanks, someone pointed to kwin, so i tried. sorryy for the noise

@thomas: pressing numlock does not toggle numlock then, but results in <tab>. what orher method is there, to toggle numlock?

numlockx on|off - cli tool written by former kwin maintainer.

[code]
user@work ~ $ numlockx on
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  132 (XTEST)
  Minor opcode of failed request:  2 (X_XTestFakeInput)
  Value in failed request:  0x0
  Serial number of failed request:  17
  Current serial number in output stream:  20
[/code]
huh?

(In reply to comment #5)
> [code]
> user@work ~ $ numlockx on
> X Error of failed request:  BadValue (integer parameter out of range for
> operation)
>   Major opcode of failed request:  132 (XTEST)
It's compiled for XTest what fakes key clicks - if there's no numlock key there's no keypress.
If you compiled it yourself ensure to use the XKB path.

(In reply to comment #6)
> It's compiled for XTest what fakes key clicks - if there's no numlock key
> there's no keypress.
> If you compiled it yourself ensure to use the XKB path.
its the version from the repos which works for the fixed keymap. i missed to provide that information.
xtest resides in /usr/share/X11/xkb/compat/xtest (put there by repoish xkeyboard-config).
what should i do with that information? didnt get it, sry.

Created attachment 79521 [details]
numlockx xkb only

Ok, I attached you a binary that uses xkb only to set the numlock state.
Check whether that can toggle the numlock.
If so, turn it off and check whether shortcuts now work.

sorry, your bin seems to have an issue with libXtst.so.6, which it cant find (still its in /usr/lib).
LD_PRELOAD didnt help either.
i feel stupid

No, I am - i disabled the XTest usage, but forgot to update the linker statements.
I'll attach another variant later (first have to re-fetch the code ;-)

Created attachment 79575 [details]
numlockx w/o xtest deps

Ok, new version attached - doesn't link xtest, still works as expected here.

ok, there is no error, though no effect too. i measure the result in either the numlock led or the shortcuts working. both dont. (but it works in fixed keymap).
toggle or on/off does not make any difference as well. is there another method switcking numlock on/off in X? i searched throught the keymap, but didnt find anything. and if i enable the broken layout with previously enabled numlock, it gets disabled.

Maybe you just activate Neo, run xev, and then press Alt+Tab (or Alt+F2).  The output when you hit the Tab key should look like this:

    state 0x8, keycode 23 (keysym 0xff09, Tab), same_screen YES,

The important thing here is the state: 0x8 means that only the Alt modifier is set.  If this would be what you observed, then the hypothesis in comment 2 that the problem is to the modifier combinations that are not all grabbed could be ruled out.  Next interesting experiment would be to put a Tab on another key in the layout, other than the Num Lock key, and see if this breaks hot keys as well.  If it does, this would indicate that multiple occurrence of Tab in the layout on level one are somehow to blame.

(In reply to comment #13)

> The output when you hit the Tab key should look like this:
>     state 0x8, keycode 23 (keysym 0xff09, Tab), same_screen YES,
> The important thing here is the state
> then
> put a Tab on another key in the layout

alt throws
alt:   state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES
and tab (the real one) says
tab:       state 0x10, keycode 23 (keysym 0xff09, Tab), same_screen YES
while numlock (marked as tab) says
nmlk:   state 0x10, keycode 77 (keysym 0xff09, Tab), same_screen YES
if i put tab to q (small Q) on standart qwerty layout (with tab still on numlock), i get
q/tab:   state 0x10, keycode 24 (keysym 0xff09, Tab), same_screen YES
an with tab removed from numlock it says
q/tab:   state 0x10, keycode 24 (keysym 0xff09, Tab), same_screen YES
alt:         state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES
(i marked the pressed key in front of the output, to avoid irritations)

pressing combinations did just throw two blocks, so i just read out these i gave here.
honestly i do not understand too much where we are going. i still hope this helps.

> state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES

This shows that the modifier that usually stands for Num Lock is set, so comment 2 is the right idea. Do the shortcuts work when you turn off Num Lock before you switch to Neo?

(In reply to comment #15)
> Do the shortcuts work when you turn off Num
> Lock before you switch to Neo?

nope, i tried that all. deos not make a difference.

Just for completeness sake: did you check that numlock was still disabled after chaning the layout? (ie, you got 0x8 and not 0x18)

(In reply to comment #17)
> Just for completeness sake: did you check that numlock was still disabled
> after chaning the layout? (ie, you got 0x8 and not 0x18)

until now, i read numlock status from status led. i hope that does not lie to me. is there a more reliable method?

(In reply to comment #18)
> i hope that does not lie to me. is there a more reliable method?
xev, see comment #13 - it's far more important what X11 thinks about the numlock state than what the hardware (or even kernel) thinks.
I've no experiences with the "neo" layout, but the absence of a numlock yet a set state (as of comments #14 & #15) sounds weird enough.
Also that you can alt+tab and get the result on xev pretty much means that this key combination is not grabbed by kglobalaccel.

ok, i checked same steps on a friends notebook w/o numpad, but nearly same config situation. there, all works fine.
it looks to me like a specific issue with my config.
is it of public interest to investigate further and fix the error (other than i did)  after finding it whereever or is this leading to a faulty confic section on my machine?

> until now, i read numlock status from status led. i hope that does not lie to me. is there a more reliable method?

xkbvleds or xkbwatch. Or, in xkb/compat/lednum, you could replace 'modifiers= NumLock;' by '       modifiers= Mod2;', which should cause the LED to faithfully show the state.

Hi,

I've stumbled across your bug. My solution was to change the keyboard behaviour on startup (Settings - Input - Keyboard - Numlock on KDE Start = Don't change). Maybe this helps.

*In case* this is because the kbd layout changes uncaught with the session start (and a miss of the numlock modifier change) this is an experimental workaround, feel free to try https://git.reviewboard.kde.org/r/125786/

*** Bug 364002 has been marked as a duplicate of this bug. ***

I was able to partly work around this issue by switching off numlock *prior* to switching to de(neo). Changing the Numlock status *after* switching to de(neo) does not work, neither by using the key nor by using numlockx.

Works:
  setxkbmap -layout de 
  numlockx on
  numlockx off
  setxkbmap -layout de -variant neo
  <Alt-Tab>

Does not work:
  setxkbmap -layout de 
  numlockx on
  setxkbmap -layout de -variant neo
  numlockx off   # numlock LED is still switched on
  <Alt-Tab>      # xev still reports state 0x18

Side note (original state of numlock does not matter)
  $ setxkbmap -layout de -variant neo
  $ numlockx off    # no error
  $ numlockx on
  X Error of failed request:  BadValue (integer parameter out of range for operation)
    Major opcode of failed request:  132 (XTEST)
    Minor opcode of failed request:  2 (X_XTestFakeInput)
    Value in failed request:  0x0
    Serial number of failed request:  17
    Current serial number in output stream:  20

Since the status is still UNCONFIRMED: Please see my report in https://bugs.kde.org/show_bug.cgi?id=364002 for how to easily reproduce this issue.

I dug into the code and made the following observations: 

When the keymap is changed, xev reports an "MappingNotify event MappingKeyboard". kglobelaccell has a method KGlobalAccelImpl::x11MappingNotify() [1], which I assume is handling this event. x11MappingNotify seams to recalculate g_keyModMaskXOnOrOff by calling (in calculateGrabMasks) [2].

calculateGrabMasks() calls (among other) KKeyServer::modXNumLock(), which calls initializeMods() [4] and this does a bit of magic: 
initializeMods() searches the whole kxb keymapping for XK_Num_Lock, which is the "NumLock" symbol. Only if this symbol is found in the current keymap, NumLock is taken as a "valid" modifier for this keymap.

My theory was that mapping any key to "NumLock" could solve the issue. When I tried to proof this, I failed (see below).

Then I found that initializeMods() seems to be only called *once* at all. initializeMods() sets a global flag (g_bInitializedMods) which is never reset.

So another solution could be to reset g_bInitializedMods in KGlobalAccelImpl::x11MappingNotify(). But on the other hand: If my analyzis above is correct, then at start up (while de(nodeadkeys) was active) initializeMods() would have accepted NumLock as a modifier to be filtered. And this would not have been changed then switching to de(neo). 

Could please some developer point me to a how-to quickly compile an run a developement-version of kglobalaccel? Then I could try digging deeper into the issue and try Thomas' fix from Comment 23.

Failed proof:

setxkbmap -layout de -variant neo
# search an unused keycode (for me 254 worked)
xmodmap -pke | grep -E '=$'
# start ev to see the notify events
xev &
# assign NumLock to this keycode, this should send an MappingNotify event
xmodmap -e "keycode 120 = Num_Lock"
# verify
xmodmap -pke | grep 254

[1] https://github.com/KDE/kglobalaccel/blob/v5.22.0/src/runtime/plugins/xcb/kglobalaccel_x11.cpp#L216
[2] calculateGrabMasks: https://github.com/KDE/kglobalaccel/blob/v5.22.0/src/runtime/plugins/xcb/kglobalaccel_x11.cpp#L49
[3] initializeMods: https://github.com/KDE/kdelibs/blob/v4.14.3/kdeui/util/kkeyserver_x11.cpp#L647
[3] initializeMods: https://github.com/KDE/kdelibs/blob/v4.14.3/kdeui/util/kkeyserver_x11.cpp#L498

(In reply to h.goebel from comment #27)
> Could please some developer point me to a how-to quickly compile an run a
> developement-version of kglobalaccel? Then I could try digging deeper into
> the issue and try Thomas' fix from Comment 23.

Thanks for investigating and of course I'm happy to help with setting up a build. I'm only familiar with debian system so, I'll point out that, can probably be adapted to other distros.

sudo apt-get build-dep libkf5globalaccel5
git clone git://anongit.kde.org/kglobalaccel
mkdir build
cd build
cmake ../kglobalaccel
make
cd src/runtime
killall kglobalaccel5
./kglobalaccel5

Trying to compile this was much more complicated (I do not have Debian nor kde 5), but I succeeded at last.

Indeed, KGlobalAccelImpl::x11MappingNotify() and calculateGrabMasks() are both gets called when setting a keymap - as expected. This morning I missed that initializeMods() is called be x11MappingNotify() and thus the modifiers are really updated as I first assumed:

setxkbmap -layout de
g_keyModMaskXAccel =  77 g_keyModMaskXOnOrOff =  146
setxkbmap -layout de -variant neo
g_keyModMaskXAccel =  77 g_keyModMaskXOnOrOff =  2

So my analysis was correct: kglobalaccel does not filter NumLock since KKeyServer does not report it as a modifier lock.

Addendum: I was now able to build and run kglobalaccel 5.22.0, too. But here x11MappingNotify seams to be never called and nativeEventFilter seams to get not XCB_MAPPING_NOTIFY event at all.

I verified that adding some key with "NumLock" solves the problem:

The following created an additional X11 symbols file defining key 253 (which is unused on my system) as NumLock and a keymap using de(neo) plus this additional symbols. The xkbcomp call will activate this keymap.

....8<-------
mkdir -p /tmp/xkb/symbols /tmp/xkb/keymaps
cd /tmp/xkb

cat > symbols/fixkdeaccell << EOF
default partial keypad_keys
xkb_symbols "numlock" {
    key <I253> { [ Num_Lock                     ] };
};
EOF

setxkbmap -layout de -variant neo -print | \
  sed 's/de(neo)+/de(neo)+fixkdeaccell(numlock)+/' > keymaps/xkbtest
cat keymaps/xkbtest
xkbcomp -I. keymaps/xkbtest $DISPLAY
....8<-------

Now you have both de(neo) and Alt-Tab working.

When running
  QT_LOGGING_RULES="org.kde.kwindowsystem.keyserver.*.debug=true" $KF5/bin/kglobalaccel5
this shows NumLock is detected.

Interesting. What does that mean now for kglobalaccel. Do we have a bug at all?

Jein, probably not in kglobalaccel.
W/o a numlock key, we cannot determine all modifiers to grab.
We could "guess" the numlock state bit (if it cannot be queried), see https://bugs.kde.org/show_bug.cgi?id=345816#c5

But what likely should really happen is that who-or-whatever (setxkbmap? kkeybord?) switches to this funky layout should clear the numlock state from the server before removing the concept of a numlock key (which usually exists even if you've no key for it like on a notebook, the problem is that the key is remapped)

Also this is bug #345816

*** This bug has been marked as a duplicate of bug 345816 ***

Okay, I'll continue at bug #345816.