| Summary: | Volume increases/decreases all the way to maximum/minimum value if button is held | ||
|---|---|---|---|
| Product: | [Unmaintained] plasma-pa | Reporter: | BOF <bugs_kde_org.5.kuru> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | minor | CC: | cwo.kde, isma.af, kdedev, me, nate |
| Priority: | NOR | ||
| Version First Reported In: | git-stable-Plasma/6.1 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
sound level min-max movement.webm
volume change holding button volume change tapping button |
||
I confirm the described behavior on Plasma master, on a laptop, just using F2/F3 (so the function key being pressed isn't affecting it) This seems by design. It is likely easy enough to add a toggle in Volume Controls to enable / disable rapid volume changes with a key being held down. The toggle to disable this: System Settings -> Keyboard -> When key is held: [X] Do nothing (In reply to Ismael Asensio from comment #2) > The toggle to disable this: > System Settings -> Keyboard -> When key is held: [X] Do nothing I don't think that this is a really good solution for this. Some people may want to increase their volume by holding the key down - that is *not* the problem. The Problem is that the volume increase/decrease does not stop when you let go of the button(s) and goes straight to the maximum/minimum value. So when you control your volume with Function key + button and release both, the volume keeps increasing/decreasing to the maximum/minimum value. When you hold down the key until the change in volume starts to move without user input, you can theoretically stop it by pressing one of the volume buttons again. Another (or a different?) problem is that multiple key presses are interpreted as held down key (but not always). So if you may end up wanting to increase the volume just three steps and end up with a pair of headphones blasting into your ear at max volume. > The Problem is that the volume increase/decrease does not stop when you let go of the button(s) and goes straight to the maximum/minimum value
This should not be the case, and I cannot reproduce this on several systems. (Neither the interpreting single keypresses as being held down; is your key stuck?)
Holding it for ~1.5 seconds at the default repeat settings is enough to go from 0 to 100 in volume though, so that is not unexpected (25 repetitions per second, plus the starting delay of 600ms)
Try setting the repeat rate to the slowest value you can (should be 0.2 repeats per second; 1 repeat is probably slow enough in case you don't want to wait that long). Apply, then hold the volume key. It should move up/down (depending on the key), but really slowly. Let go of the key. Does it still move all the way, does it stop when you let go, or does it continue for a while, then stop?
Testing more specifically: I'm also not able to reproduce the problem of the volume continuing to change after releasing the keyboard shortcut. I attempted on git-master (Lenovo Flex) and Plasma 6.1.3 (Dell XPS) Both systems are laptops using F2/F3 to control volume. I tested with Fn lock on and with it off I can't reproduce the original issue with current git master. When I let go of my Volume Up or Volume Down keys (also on the F2 and F3 buttons for me), the volume stops changing immediately. Works for me in both Fn lock mode and also normal mode where I don't have to hold down the Fn key. This seems like it might be a hardware or firmware issue on your machine, BOF. Can you check to see if it reproduces in a new clean user account on the same machine with no customizations? (In reply to Nate Graham from comment #6) > This seems like it might be a hardware or firmware issue on your machine, > BOF. > > Can you check to see if it reproduces in a new clean user account on the > same machine with no customizations? I have no idea how I would test this issue with the same device, but different firmware. Further tests: - I tested the bug on an ASUS ROG Strix G15 laptop (Not the bug report laptop). This laptop has dedicated single-use buttons to increase/decrease the volume. With this laptop I can not reproduce this bug. It's like TraceyC described it: When held down the volume changes, when released the change stops. - I tested the bug on the Lenovo ThinkBook 16 G6 ABP (The bug report laptop), but with with a live USB using _neon-user-20240725-0828.iso_ (latest user build as of today). I get the exact same problem. It doesn't matter if I use FnLock or not. The strange thing: With the 'clean' install of KDE 6.1 I have the system sounds back again and I hear that the volume increase is still ongoing after I release the button. The change only stops when I press a button. Rapid pressing of the button has the exact same effect as holding it down. General comments: - No, my buttons are not stuck as there would certainly *have* to be an effect on the rest of the system. If a button in mixed use is stuck, it's not only stuck for one application. As I'm using Krunner with Alt+F2 and rename files in Dolphin with F2 I can hardly imagine that any button would be stuck. Furthermore the F2 as well as the F3 button would have to be stuck as they show the exact same behaviour. - I don't think that it's the firmware or hardware of my system as this problem started to occur after an update (Though I have no idea which update it was). I'm almost certain that this bug did not occur under 6.0, but I have no idea where I would get an old version of KDEneon to test it. (-> I will test it with other distros (KDE + others) as well and see if there is a problem with them as well as they should suffer from the same problem if it was my hardware or my firmware) Created attachment 172036 [details]
volume change holding button
FnLock is off
I change the volume holding the button down. As you can hear as well, the volume wants to increase even past 100% and only stops changing when another button is pressed.
The same happens when you decrease the volume, but of course you can not hear 0% volume.
Created attachment 172040 [details]
volume change tapping button
FnLock is off
I change the volume by rapidly tapping the button. Again it sounds like the volume wants to increase past 100%. Same happens again for decrease the volume.
You do not have to rapidly tap the button that often. There seems to be somewhat of a chance that it happens (with multiple fast button presses) so pressing the button in a rapid way increases it's chance. So when I want to decrease the volume by 15% (3 stops) and press the button fast-ish three times it often happens that the volume goes all the way down to 0% (or up to 100% if you increase the volume).
I also had it multiple times that when I start at 0% and tap the button fast a few times the volume level shot up to 100% even I was no longer pressing any buttons at all.
This and the last video were recorded under a live session with _neon-user-20240725-0828.iso_
Excellent videos, thanks. That's pretty crazy. Definitely not what I see, not can I reproduce it at all. Are there any other keys on your keyboard that behave like this? Like, the brightness keys, Bluetooth or wifi on/off keys, or any alphanumeric key that you hold down for a bit? (In reply to Nate Graham from comment #10) > Are there any other keys on your keyboard that behave like this? Like, the > brightness keys, Bluetooth or wifi on/off keys, or any alphanumeric key that > you hold down for a bit? There are no other keys that behave like that. As update for _rapidly tapping the button_: I discovered that if you tap the key only once, but very fast, you can reproduce the bug with a single key press. Good news (for you) and bad news (for me): I tested all the distros listed below. I was able to reproduce the bug on KDE systems as well as non-KDE distros with different base distros. My guess is that this is not KDE related then. Is there anything to test before the bug is closed? (Even I got this laptop with Windows, I never used it under it. So I can't even tell you how this behaves under Windows) (Would may be an interesting feature to prevent quick keystrokes from resulting in something that is like pressing a button) Tested KDE distros: manjaro-kde-24.0.3-240702-linux69.iso - Operating System: Manjaro Linux - KDE Plasma Version: 6.0.5 - KDE Frameworks Version: 6.3.0 - Qt Version: 6.7.1 - Kernel Version: 6.9.5-1-MANJARO (64-bit) - Graphics Platform: X11 kubuntu-24.04-desktop-amd64.iso - Operating System: Kubuntu 24.04 - KDE Plasma Version: 5.27.11 - KDE Frameworks Version: 5.115.0 - Qt Version: 5.15.13 - Kernel Version: 6.8.0-31-generic (64-bit) - Graphics Platform: X11 MX-23.3_KDE_x64.iso - Operating System: MX Linux 23 - KDE Plasma Version: 5.27.5 - KDE Frameworks Version: 5.103.0 - Qt Version: 5.15.8 - Kernel Version: 6.1.0-21-amd64 (64-bit) - Graphics Platform: X11 Fedora-KDE-Live-x86_64-40-1.14.iso - Operating System: Fedora Linux 40 - KDE Plasma Version: 6.0.3 - KDE Frameworks Version: 6.0.0 - Qt Version: 6.6.2 - Kernel Version: 6.8.5-301.fc40.x86_64 (64-bit) - Graphics Platform: Wayland Tested non-KDE distros: ubuntu-24.04-desktop-amd64.iso - Operating System: Ubuntu 24.04 LTS - GNOME Version: 46 - Kernel Version: 6.8.0-31-generic (64-bit) - Graphics Platform: X11 Fedora-Workstation-Live-x86_64-40-1.14.iso - Operating System: Fedora Linux 40 (Workstation Edition) - GNOME Version: 46 - Kernel Version: 6.8.5-301.fc40.x86_64 - Graphics Platform: Wayland linuxmint-22-cinnamon-64bit.iso - Operating System: Linux Mint 22 Wilma - Cinnamon: 6.2.7 - GTK: 3.24.41 - Kernel Version: 6.8.0-38-generic (64-bit) - Graphics Platform: X11 MX-23.3_July_x64.iso - Operating System: MX Linux 23 - DE: Xfce I really appreciate the exhaustive testing. At this point I think there's either a hardware or driver issue at play. Not knowing which one it is, I'd recommend going deeper in the stack one layer at a time and submitting an Issue report with the Libinput input driver library. Maybe there's a bug there, or maybe they can de-duplicate the events at that level. At the minimum, the maintainer there can probably direct you to a better place than I can. https://gitlab.freedesktop.org/libinput/libinput/-/issues/ Thanks for the bug report and patience here! |
Created attachment 171545 [details] sound level min-max movement.webm SUMMARY When you single tap the volume buttons the volume increases/decreases by one step (default 5%) When you hold down the key for about a second (and let go of it), the volume moves all the way to the minimum or maximum even if you do not press the volume key any longer. STEPS TO REPRODUCE 1. Press buttons to increase/decrease the volume on your PC 2. Let go of the button after about a second 3. The volume bar moves to the minimum/maximum position all by itself OBSERVED RESULT The audio increases all the way to 100% or decreases all the way to 0% EXPECTED RESULT Not do 'that'. To Not-Microsoft this: I can not see this as a feature under any circumstance. To me it's nothing but annoying and feels like having sand in a working machine. If some dev thought this to be a good feature to change the volume quickly, let me turn it off in the volume settings. SOFTWARE/OS VERSIONS Operating System: KDE neon 6.0 KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.0 Kernel Version: 6.5.0-41-generic (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 7530U with Radeon Graphics Memory: 29.2 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: LENOVO Product Name: 21KK System Version: ThinkBook 16 G6 ABP ADDITIONAL INFORMATION I'm using a laptop and control my volume with a function key (Fn) and a second key (F2, F3). Maybe the system thinks that the function key (Fn) is part of the volume key and keeps on moving as long as it is held down. On the other hand the volume still moves to the min/max position even when I let go of the Fn key shortly after the volume starts increasing/decreasing constantly.