search

elementary / switchboard-plug-keyboard

Switchboard Keyboard Plug
GNU General Public License v2.0
28 stars 22 forks source link

Some media keys cannot be re-assigned because Gnome Settings Daemon maps them statically #376

Open stan-janssen opened 3 years ago

stan-janssen commented 3 years ago

What Happened

I'm on a desktop computer with one external monitor. I have a keyboard that has brightness up/down keys. I want to assign these keys to a script that I made that send DDC commands to my monitor to change the brightness. This script works fine if I assign, for example, ctrl + brightness up and ctrl + brightness down, but not the brightness up and brightness down keys on their own. The script simply does not run.

brightness

Expected Behavior

I'd like to be able to assign my brightness up and brightness down keys to a custom script.

Steps to Reproduce

To make it simple, let's assign a shortcut key to the command notify-send Hello "This is a test":

brightness-reproduce

Logs

I don't have any logs for this.

Platform Information

ElementaryOS 6 stable. This problem was also present in elementaryOS 5.1.7 that I was using previously.

sjlua commented 3 years ago

Can you assign any custom keyboard shortcuts? They don't seem to work for me at all.

stan-janssen commented 3 years ago

Can you assign any custom keyboard shortcuts? They don't seem to work for me at all.

Yes, all other custom shortcuts work fine for me; see the description in the issue where setting ctrl + Brightness Up works fine. It seems to be that the OS is capturing the Brightness Up and Brightness Down keys and not propagate them to whatever system is handling these custom shortcuts.

stan-janssen commented 3 years ago

I've found the cause of this problem. Apparently, in Gnome Settings Daemon, there were bindings for the brightness keys named screen-brightness-up-static and screen-brightness-down-static. Once I removed the Brightness keys from these assignments, my custom keyboard shortcuts now work:

gsettings set org.gnome.settings-daemon.plugins.media-keys screen-brightness-up-static "['']"
gsettings set org.gnome.settings-daemon.plugins.media-keys screen-brightness-down-static "['']"

After removing these static shortcuts, it is neccessary to log out and back in again

I've also verified that this solves the problem @sirsleon had in #378 where it was not possible to assign the Tools key; this binding key was already statically bound to control-center-static. To remove this static binding:

gsettings set org.gnome.settings-daemon.plugins.media-keys control-center-static "['']"

On could wonder why these static, non-rebindable things exist in the first place. I found this rather heated discussion that got shut down by the maintainers over at the Gnome Settings Daemon issue tracker where people were running into similar problems. Apparently rebinding these statically bound keys will not be supported officially, and apparently is a Bad Idea™; I could not follow why it would be a bad idea to rebind some of these media keys.

The full list of statically-bound keys is:

battery-status-static ['XF86Battery']
calculator-static ['XF86Calculator']
control-center-static ['XF86Tools']
eject-static ['XF86Eject']
email-static ['XF86Mail']
hibernate-static ['XF86Suspend', 'XF86Hibernate']
home-static ['XF86Explorer']
keyboard-brightness-down-static ['XF86KbdBrightnessDown']
keyboard-brightness-toggle-static ['XF86KbdLightOnOff']
keyboard-brightness-up-static ['XF86KbdBrightnessUp']
media-static ['XF86AudioMedia']
mic-mute-static ['XF86AudioMicMute']
next-static ['XF86AudioNext', '<Ctrl>XF86AudioNext']
pause-static ['XF86AudioPause']
playback-forward-static ['XF86AudioForward']
playback-random-static ['XF86AudioRandomPlay']
playback-repeat-static ['XF86AudioRepeat']
playback-rewind-static ['XF86AudioRewind']
play-static ['XF86AudioPlay', '<Ctrl>XF86AudioPlay']
power-static ['XF86PowerOff']
previous-static ['XF86AudioPrev', '<Ctrl>XF86AudioPrev']
rfkill-bluetooth-static ['XF86Bluetooth']
rfkill-static ['XF86WLAN', 'XF86UWB', 'XF86RFKill']
rotate-video-lock-static ['<Super>o']
screen-brightness-cycle-static ['XF86MonBrightnessCycle']
screen-brightness-down-static ['XF86MonBrightnessDown']
screen-brightness-up-static ['XF86MonBrightnessUp']
screensaver-static ['XF86ScreenSaver']
search-static ['XF86Search']
stop-static ['XF86AudioStop']
suspend-static ['XF86Sleep']
touchpad-off-static ['XF86TouchpadOff']
touchpad-on-static ['XF86TouchpadOn']
touchpad-toggle-static ['XF86TouchpadToggle', '<Ctrl><Super>XF86TouchpadToggle']
volume-down-precise-static ['<Shift>XF86AudioLowerVolume', '<Ctrl><Shift>XF86AudioLowerVolume']
volume-down-quiet-static ['<Alt>XF86AudioLowerVolume', '<Alt><Ctrl>XF86AudioLowerVolume']
volume-down-static ['XF86AudioLowerVolume', '<Ctrl>XF86AudioLowerVolume']
volume-mute-quiet-static ['<Alt>XF86AudioMute']
volume-mute-static ['XF86AudioMute']
volume-up-precise-static ['<Shift>XF86AudioRaiseVolume', '<Ctrl><Shift>XF86AudioRaiseVolume']
volume-up-quiet-static ['<Alt>XF86AudioRaiseVolume', '<Alt><Ctrl>XF86AudioRaiseVolume']
volume-up-static ['XF86AudioRaiseVolume', '<Ctrl>XF86AudioRaiseVolume']
www-static ['XF86WWW']

This means that the above keys or key-combinations will not be able to be remapped to something else. It is unclear to me what kind of problem this is trying to prevent, so I'm going to go ahead and propose a solution for this:

  1. We should add all these statically defined keys to the keyboard shortcuts panel, so that they are at least discoverable.
  2. Wherever possible, elemenatryOS should map these statically-bound keys to something logical; I think @sirsleon's suggestion of mapping the Tools key to System Settings is a reasonable example.
  3. Whenever a user wants to re-assign one of these keys that was statically bound, we should display a warning telling the user:
    1. Unexpected behavior may occur
    2. They need to log and and log back in to enable the change

People over at Gnome Settings Daemon and Gnome Control Center have filed several issues where solutions are being proposed but none are being accepted over there:

I will try to work up the above solution to see if this is something that elementaryOS would like to enable.