search

bbidulock / icewm

A window manager designed for speed, usability, and consistency
Other
585 stars 98 forks source link

icewm-keys executes command for 'Shift+XF86AudioPlay' instead of 'XF86AudioPause' (which should be used with Shift - declared in Xmodmap) #781

Closed T-3B closed 1 month ago

T-3B commented 1 month ago

In my file ~/.icewm/keys, I have defined the following keys:

key "XF86AudioPlay"
key "XF86AudioPause"

For some reason the command of the key XF86AudioPause was never triggered. So I dump my default Xmodmap configuration and I see the following line: keycode 172 = XF86AudioPlay XF86AudioPause

In order for me to input XF86AudioPause I need to hold the Shift key + the key I would use to input XF86AudioPlay.

That's surely why IceWM will execute the command of the key Shift+XF86AudioPlay instead of XF86AudioPause. But why is this choice? Is there a way to make IceWM run commands for XF86AudioPlay and XF86AudioPause?

gijsbers commented 1 month ago

  1. Can you now run either of those commands by pressing something?

  2. Can you press those keys and observe the events with xev?

  3. What is your output of xmodmap -pk | grep -e XF86AudioPlay -e XF86AudioPause?

T-3B commented 1 month ago
  1. Only commands related to these keys will be executed: XF86AudioPlay Shift+XF86AudioPlay. I want XF86AudioPause to also execute its command, but this won't.
  2. If my ~/.icewm/keys contains commands for XF86AudioPlay and XF86AudioPause This is the xev output for XF86AudioPlay: 
    
FocusOut event, serial 38, synthetic NO, window 0x2c00001,
mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 38, synthetic NO, window 0x2c00001, mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 38, synthetic NO, window 0x0, keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


This is the `xev` output for `Shift+XF86AudioPlay` (which is **by default** mapped to `XF86AudioPause` in my `.Xmodmap`):

KeyPress event, serial 38, synthetic NO, window 0x2c00001, root 0x5d9, subw 0x0, time 46995365, (-149,351), root:(428,380), state 0x10, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False

FocusOut event, serial 38, synthetic NO, window 0x2c00001, mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 38, synthetic NO, window 0x2c00001, mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 38, synthetic NO, window 0x0, keys: 0 0 0 0 0 0 4 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

KeyRelease event, serial 38, synthetic NO, window 0x2c00001, root 0x5d9, subw 0x0, time 46995737, (-149,351), root:(428,380), state 0x11, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False

***If my `~/.icewm/keys` does NOT contain commands for `XF86AudioPlay` and `XF86AudioPause`***
Key that *should* be `XF86AudioPlay`:

KeyPress event, serial 38, synthetic NO, window 0x2e00001, root 0x5d9, subw 0x0, time 47268667, (-803,278), root:(346,307), state 0x10, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False

KeyRelease event, serial 38, synthetic NO, window 0x2e00001, root 0x5d9, subw 0x0, time 47268707, (-803,278), root:(346,307), state 0x10, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False

Key that should be `XF86AudioPause` (which is in fact `Shift+XF86AudioPlay`)

KeyPress event, serial 38, synthetic NO, window 0x2e00001, root 0x5d9, subw 0x0, time 47274654, (-803,278), root:(346,307), state 0x10, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False

KeyPress event, serial 38, synthetic NO, window 0x2e00001, root 0x5d9, subw 0x0, time 47274841, (-803,278), root:(346,307), state 0x11, keycode 172 (keysym 0x1008ff31, XF86AudioPause), same_screen YES, XKeysymToKeycode returns keycode: 209 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False

KeyRelease event, serial 38, synthetic NO, window 0x2e00001, root 0x5d9, subw 0x0, time 47274961, (-803,278), root:(346,307), state 0x11, keycode 172 (keysym 0x1008ff31, XF86AudioPause), same_screen YES, XKeysymToKeycode returns keycode: 209 XLookupString gives 0 bytes: XFilterEvent returns: False

KeyRelease event, serial 38, synthetic NO, window 0x2e00001, root 0x5d9, subw 0x0, time 47275011, (-803,278), root:(346,307), state 0x11, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False

So it seems like declaring a command to run for `XF86AudioPlay` in `icewm-keys` will hide `XF86AudioPause`.

3. I don't really understand why it is needed, since it is the same as already written in 1st post.

$ xmodmap -pk | grep -e XF86AudioPlay -e XF86AudioPause 172 0x1008ff14 (XF86AudioPlay) 0x1008ff31 (XF86AudioPause) 0x1008ff14 (XF86AudioPlay) 0x1008ff31 (XF86AudioPause) 208 0x1008ff14 (XF86AudioPlay) 0x0000 (NoSymbol) 0x1008ff14 (XF86AudioPlay)
209 0x1008ff31 (XF86AudioPause) 0x0000 (NoSymbol) 0x1008ff31 (XF86AudioPause) 215 0x1008ff14 (XF86AudioPlay) 0x0000 (NoSymbol) 0x1008ff14 (XF86AudioPlay)


But on my keyboard I only found the key on keycode `172`, so it is the only one i have access to, in order to trigger `XF86AudioPlay` and `XF86AudioPause`
gijsbers commented 1 month ago

Thanks for all this information. It is very helpful since I can't generate XF86Audio keys myself and it shows me the precise details that I need.

The last output shows that your keytable has multiple keycodes for XF86AudioPause. The last one doesn't require Shift. One problem is that icewm only supports one keycode per keybinding and in this it depends on the output of the Xlib call XKeysymToKeycode which prefers to return non-shifted keycodes.

Another problem for icewm is it doesn't know which keycodes are superfluous. I would like to know how icewm could detect that, but I can't find that information. Given such information exists, it would be possible to ignore the unused keycodes, which would leave only one keycode for XF86AudioPause.

The question is sort of whether it is worthwile to redesign the whole keybinding layer to accommodate this special case for only a few users like you. It may be a lot of work for a small feature.

T-3B commented 1 month ago

I don't know why I didn't do it the first time, but in fact I already made some changes to my Xmodmap configuration (irrelevant for this issue - other keys that don't have anything to do with XF86AudioPlay and XF86AudioPause).

But, it is easy for me to delete those superfluous keycodes. Now I get the following:

$ xmodmap -pk | grep -e XF86AudioPlay -e XF86AudioPause
    172     0x1008ff14 (XF86AudioPlay)  0x1008ff31 (XF86AudioPause) 0x1008ff14 (XF86AudioPlay)  0x1008ff31 (XF86AudioPause)

TL;DR So the issue is all about if icewm-keys supports keybinding on XF86AudioPlay and XF86AudioPause if they are defined on the same keycode. Sorry if my first post was unclear.

Reading your last message, it appears icewm-keys does not support that. Is it in the features "nice to have in the future", or is it just impossible for IceWM to do that?

Thanks for you time and help ;)

gijsbers commented 1 month ago

This commit adds support for shifted XF86Audio keys, if they are the only such instance. This benefits from your removal of superfluous keycodes.

T-3B commented 1 month ago

Thank you very much!

Had to remove my previous post, somehow this did not worked at first.

This indeed does the trick, thank you for your time and help :) (Now catching XF86AudioPause works in ~/.icewm/keys!)