swhkd icon indicating copy to clipboard operation
swhkd copied to clipboard

Configuration rules with a modifier + MEDIA_KEY not working

Open frieser opened this issue 3 years ago • 8 comments

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 avatar Jun 09 '22 10:06 frieser

btw, thanks for made this tool

frieser avatar Jun 09 '22 11:06 frieser

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

Shinyzenith avatar Jun 10 '22 02:06 Shinyzenith

@angelofallars @EdenQwQ

Shinyzenith avatar Jun 13 '22 04:06 Shinyzenith

@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

EdenQwQ avatar Jun 13 '22 21:06 EdenQwQ

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.

frieser avatar Jun 14 '22 14:06 frieser

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.

Shinyzenith avatar Jun 15 '22 00:06 Shinyzenith

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.

frieser avatar Jun 15 '22 09:06 frieser

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

Shinyzenith avatar Jun 15 '22 09:06 Shinyzenith