waycrate / swhkd

Sxhkd clone for Wayland (works on TTY and X11 too)
https://git.sr.ht/~shinyzenith/swhkd
BSD 2-Clause "Simplified" License
676 stars 47 forks source link

Configuration rules with a modifier + MEDIA_KEY not working #129

Open frieser opened 2 years ago

frieser commented 2 years ago

Version Information: Linux fedora 5.17.12-300.fc36.x86_64 #1 SMP PREEMPT Mon May 30 16:56:53 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

swhkd 1.2.0

Describe the bug: Rules with a combination of a modifier(ctrl,super,shift) with media keys are not working. Rules with only the media keys are working.

Expected behavior: Rules running as expected

Actual behavior: Nothing happens.

To Reproduce: Define this rules in your configuration file and restart swhkd:

# works
ctrl + return
  kgx

# works
xf86audiolowervolume
  sh -c 'ydotool key 29:1 12:1 12:0 29:0'

# not working
ctrl + xf86audiolowervolume
  sh -c 'ydotool key 29:1 12:1 12:0 29:0'

# works
XF86AudioPlay
  firefox

# not working
super + shift + XF86AudioPlay
  kgx

Additional information:

frieser commented 2 years ago

btw, thanks for made this tool

Shinyzenith commented 2 years ago

Hi thanks for the report. @angelofallars would you mind taking a look? This seems to be a parser issue.

Shinyzenith commented 2 years ago

@angelofallars @EdenQwQ

EdenQwQ commented 2 years ago

@frieser In my tests, super+mediakey works but Ctrl/shift+mediakey doesn't work. I assume it to be more like an evdev issue. I guess that's because ctrl/shift/alt would turn a media key into a Fn key on some keyboards and evdev would receive the modifier and the fn key the same time.

For example, on my keyboard the volumelower key is at the same time f5. If I write shift + volumelower or f5, pressing shift with that key won't work. But if I write shift + f5 it will work as expected. So please check your keyboard and write modifier + fnkey

frieser commented 2 years ago

Hi, thanks for reply.

My keyboard is a gamakay lk67, it has the media keys to control the volume with a knob, so is a separate key with no fallback to fnkey, I guess.

I was debugging with some tooling (wev), theorically this tool capure evdev events in wayland and the capture seems ok to me, but I not an expert of evdev or input. Maybe it helps:

# comment, volume up only
[14:     wl_keyboard] key: serial: 21761; time: 19854001; key: 123; state: 0 (released)
                      sym: XF86AudioRaiseVolume (269025043), utf8: ''
 # comment, volume down only
[14:     wl_keyboard] key: serial: 21762; time: 19857874; key: 122; state: 0 (released)
                      sym: XF86AudioLowerVolume (269025041), utf8: ''

 # comment, press left control         
[14:     wl_keyboard] key: serial: 21763; time: 19859376; key: 37; state: 1 (pressed)
                      sym: Control_L    (65507), utf8: ''
[14:     wl_keyboard] modifiers: serial: 0; group: 0
                      depressed: 00000004: Control 
                      latched: 00000000
                      locked: 00000000

 # comment, volume up whitout release control                  
[14:     wl_keyboard] key: serial: 21765; time: 19862294; key: 123; state: 0 (released)
                      sym: XF86AudioRaiseVolume (269025043), utf8: ''

 # comment, released volume up whitout release control                           
[14:     wl_keyboard] key: serial: 21766; time: 19864390; key: 37; state: 0 (released)
                      sym: Control_L    (65507), utf8: ''

 # comment, release control                           
[14:     wl_keyboard] modifiers: serial: 0; group: 0
                      depressed: 00000000
                      latched: 00000000
                      locked: 00000000

It seems that the modifier not affect the keycode of volumeup(123 in both cases), and with gnome keyboard shortcut utility seems to catch the key combination:

image

I know, its an edge case, the tool its fantastic, but it would be cool if I would control with the knob multiple things.

Shinyzenith commented 2 years ago

Hi, afaik wev reports xkbcommon events re-emitted by the compositor. In this case, sudo libinput debug-events would give the correct logs as it re-emits evdev events if I'm not mistaken.

frieser commented 2 years ago

great, maybe this helps:

[frieser@fedora ~]$ sudo libinput debug-events
-event3   DEVICE_ADDED            RONGYUAN 2.4G Wireless Device     seat0 default group6  cap:p left scroll-nat scroll-button
-event4   DEVICE_ADDED            RONGYUAN 2.4G Wireless Device System Control seat0 default group6  cap:k
-event5   DEVICE_ADDED            RONGYUAN 2.4G Wireless Device Consumer Control seat0 default group6  cap:kp scroll-nat
-event6   DEVICE_ADDED            RONGYUAN 2.4G Wireless Device Keyboard seat0 default group6  cap:k
-event7   DEVICE_ADDED            RONGYUAN 2.4G Wireless Device     seat0 default group6  cap:k
# ctrl + volumeup
-event7   KEYBOARD_KEY            +0.000s   *** (-1) pressed
-event5   KEYBOARD_KEY            +2.293s   KEY_VOLUMEUP (115) pressed
 event5   KEYBOARD_KEY            +2.309s   KEY_VOLUMEUP (115) released
-event7   KEYBOARD_KEY            +3.045s   *** (-1) released
# ctrl + volumedown
 event7   KEYBOARD_KEY            +3.955s   *** (-1) pressed
-event5   KEYBOARD_KEY            +5.593s   KEY_VOLUMEDOWN (114) pressed
 event5   KEYBOARD_KEY            +5.601s   KEY_VOLUMEDOWN (114) released
-event7   KEYBOARD_KEY            +6.046s   *** (-1) released
 event7   KEYBOARD_KEY            +6.895s   *** (-1) pressed
# ctrl + pause/play
-event5   KEYBOARD_KEY            +8.198s   KEY_PLAYPAUSE (164) pressed
 event5   KEYBOARD_KEY            +8.374s   KEY_PLAYPAUSE (164) released
-event7   KEYBOARD_KEY            +8.676s   *** (-1) released
# shift + volumeup
-event7   KEYBOARD_KEY            +0.000s   *** (-1) pressed
-event5   KEYBOARD_KEY            +3.316s   KEY_VOLUMEUP (115) pressed
 event5   KEYBOARD_KEY            +3.332s   KEY_VOLUMEUP (115) released
-event7   KEYBOARD_KEY            +5.698s   *** (-1) released

thanks for the support.

Shinyzenith commented 2 years ago

hmm I see, I will test a bit and get back to this.