Bugzilla – Bug 1078487
Regression: Power button and some Fn keys (suspend, brightness) no longer respond
Last modified: 2018-03-07 13:44:40 UTC
Created attachment 758230 [details] Logs from "journalctl -b" as root After updating to TW 20180129, pressing the following keys has no effect: * Power * Fn + F1 (suspend) * Fn + F3/4 (keyboard backlight) * Fn + F5/6/7 (display brightness and screen off) All of these can still be controlled using the GUI, and all other Function keys work properly. Suspend and power button presses are logged by logind, however nothing other action occurs, even after waiting several minutes. This was a practically brand new installation with the 20180121 ISO and no updates done before this one.
To be clear, this used to work when the system was first installed, so this is a regression.
Hi, My Acer Aspire V 15 V5-591G-73UT laptop (OpenSUSE TW, x64, KDE) has lost ability to change brightness from FN + left , right arrow keys. Pressing the actual keys, I get these events (via acpi_listen): video/brightnessdown BRTDN 00000087 00000000 676AA15E-6A47-4D� 000000bc 00000000 video/brightnessup BRTUP 00000086 00000000 676AA15E-6A47-4D� 000000bc 00000000 It stopped working from 4.14.15 I think and up to current 4.15.0-1-default. Brightness can be changed from Plasma's Battery and Brightness in systray for example.
I have the same issue on a Samsung Series 7 (NP704U3E). xev shows: keycode 232 X86MonBrightnessDown keycode 233 X86MonBrightnessUp keycode 124 X86PowerOff Mark
I have the same issue on a Dell E7470. Power button does not work display brightness does not work Sleep button does not work Keyboard backlight button works Previously all was working. Checking with xev all keypresses are detected. Everything can be controlled from software (power applet in tray)
According to wolfi323 (https://forums.opensuse.org/showthread.php/529498-Power-button-doesn-t-do-anything?p=2854483#post2854483) this may be a kernel bug.
*** Bug 1079553 has been marked as a duplicate of this bug. ***
Thanks for pointing me here. I originally created bug report 1079553. The Microphone Mute/Unmute key on my Thinkpad T460 no longer works. All the other shortcuts work. I can toggle the microphone between mute and unmute by using: - System tray Audio Volume Settings (key led also toggles) - "amixer set Capture toggle" in terminal (key led also toggles) Xev output also indicates shows me the key is recognized. I think my issue and maybe this bug report is related to a new bug in KDE 5.12 as reported by these bugs too: - https://bugs.kde.org/show_bug.cgi?id=390094 - https://bugs.kde.org/show_bug.cgi?id=389991 (maybe) I tried the latest TW Gnome snapshot and all the keyboard shortcuts work as expected to. A temporary workaround for me is to assign the Microphone key to bash script executing "amixer set Capture toggle".
Erm, please stop adding "me too" entries if you have a different laptop. Instead, please open another bug report per laptop model. If we figure out that it were a same culprit, we can close as dup. Let's start from the original report. This looks like an ASUS laptop, but need more clarification. Karl, please give hwinfo output. And if you still have an old kernel where the Fn key worked, please boot with it again and confirm that the Fn key still works. Then we can narrow down the kernel regression range.
Created attachment 760119 [details] hwinfo output (In reply to Takashi Iwai from comment #10) > Erm, please stop adding "me too" entries if you have a different laptop. > Instead, please open another bug report per laptop model. If we figure out > that it were a same culprit, we can close as dup. > > Let's start from the original report. This looks like an ASUS laptop, but > need more clarification. Karl, please give hwinfo output. > > And if you still have an old kernel where the Fn key worked, please boot > with it again and confirm that the Fn key still works. Then we can narrow > down the kernel regression range. My apologies, it appears that this was indeed a KDE-specific issue rather than a kernel bug. As mentioned in comment 9, kde#389991 provides instructions to manually fix this, which resolved the issue in my case. However, I'm not sure whether this requires manual intervention or if it can be handled by a package update. Regardless, I have attached hwinfo output for my laptop, which is indeed an ASUS UX331UA.
Reassigning to KDE maintainers as this appears to not be a basesystem issue.
(In reply to Karl Cheng from comment #11) > As mentioned in comment 9, kde#389991 provides instructions to manually fix > this, which resolved the issue in my case. Should be fixed in Plasma 5.12.2 then, which was released yesterday (it's not in the repos yet though). > However, I'm not sure whether this requires manual intervention or if it can > be handled by a package update. The fix that will be in 5.12.2 should not require manual intervention AIUI. After the update, the shortcuts should get migrated again, and this time the migration should work fine.
*** Bug 1082104 has been marked as a duplicate of this bug. ***
Plasma 5.12.2 is in Tumbleweed meanwhile, so let's assume this is fixed.