Current plasma resets some system settings to its own defaults. One such instance is the settings for Speakers and Microphone. I usually keep these both muted, but if I do that and logoff/login again, they are reset to the non-muted defaults. I'm using the audio widget on the plasma desktop panel. The second instance involves the screenpad on my laptop, or ScreenXpert as plasma calls it. I disable this using the System Settings -> Display and Monitor tool. But plasma re-enables it after a time without even logging out and logging in again. Probably not a lot of people have Screenpads, but the first instance should be easy enough to reproduce.
Thank you for the report, Frank. I will try and test it when I get into my Cauldron system. Assigning it to the KDE/Plasma group anyway.
Assignee: bugsquad => kde
Tried this, specifically with Plasma System Settings Hardware/Audio. Set both Speaker & Microphone sliders off, completely to the left. Is this what you meant? I notice that, unlike most system settings, there is no 'Apply' button. You just have to quit the window. BTAIM I logged out via the menu, -> disaster. Re-logging back into Plasma (LightDM) stuck. It showed immediately the Plasma loading screen with the progress bar at middle for ages; then just a completely bare desktop. I did Ctrl/Alt/Bksp/Bksp, tried logging in again, same problem. Once it returned to the login screen. Only way back into Plasma was to re-boot, whose closedown got stuck on something for 1m. Re-logging in to Plasma now worked, but... the changed settings had survived. I will re-try this with the Systray Audio widget.
Ever confirmed: 1 => 0Status: NEW => UNCONFIRMEDAssignee: kde => bugsquadCC: (none) => lewyssmith
I have re-tried this all ways. To get the re-logging-in problem out of the way, I found that if it started in stuck mode, leaving the eventual bare desktop long enough did end up with a normal Plasma desktop. OTOH sometimes it launched normally. Re the Audio/Mike settings, I found that when they were set to nothing, either via System Settings[Hardware]Audio, or via the Audio systray widget, this survived across sessions. If specific levels are set, the Speakers level survived across sessions, but the Microphone level got adjusted. I also note that if the System Settings/Audio window lacks any 'done' button, the same window ex the systray widget *does* have 'OK' & 'Cancel' buttons. I could not try the ScreenXpert affair (which seems an easier illustration of the problem anyway), do not have it, it does not show. No choice but to pass this to the KDE people, although I cannot see what they can do other than update Plasma as & when.
Summary: Plasma keeps resetting system settings => Plasma keeps resetting some system settingsEver confirmed: 0 => 1Assignee: bugsquad => kdeStatus: UNCONFIRMED => NEW
I have been wasting my time - and that of readers. On what is supposed to be a Cauldron system, I have just discovered that it is far more mga8 than mga9, and all plasma pkgs are still mga8. So the previous two comments are null & void.
CC: lewyssmith => (none)
This is cauldron only, and relatively recent at that (1-2 months at most).
I have an up to date cauldron system and can't recreate the audio issues. Setting audio/mic sliders in systemsettings5 to a defined value survive a restart/logout of plasma. Setting audio/mic sliders in systemsettings5 to muted survive a restart/logout of plasma. The two above points also apply if the settings get applied via the widget in system tray instead of systemsettings5. Did you try to create a new user to rule out borked user settings in /home?
(In reply to sturmvogel from comment #6) > > Did you try to create a new user to rule out borked user settings in /home? No, I was hoping to avoid that, but I suspect that's the case. It always pisses me off how the plasma folks are cavalier about migrating system settings when the code changes. My system settings predate plasma into KDE4, so that's probably it.
(In reply to Frank Griffin from comment #7) > pisses me off how the plasma folks are cavalier about migrating system > settings when the code changes. My system settings predate plasma into KDE4 It was a major step from KDE4 to KDE Plasma 5. It is not possible to keep ancient code and relicts from the past if you do a major-major version step. Mageia provided KDE Plasma 5 in parallel with KDE4 first in Mageia 5. From Mageia 6 onwards KDE Plasma 5 was default. Mageia 5 was released 7 years ago... It is not possible for any developer to keep all settings the same as in the past 10 years ago. Thats the case for open source and also for proprietary stuff like Microsoft windows. If you would stick to the past developement status you would still have sticks and stones instead of advanced computer systems and operating systems.
Well, that's not really the point. If they've been able and willing to port forward my system settings from the KDE4 days successfully, there's no reason why they couldn't have done it for the latest iteration. KDE4 -> Plasma worked OK. I expected that there would be new additions that I might want to play with, but the ones I had were persisted. And with a very few annoying exceptions, Plasma -> Plasma upgrades have not broken existing settings. When they do, it's not about dropping a setting or changing how an existing setting is handled, it's more about breaking the UI as (it is here) about settings made through the tool not being persisted when they're supposed to be. Sorry, but that's not progress; it's a bug.
This discussion leads to nothing. As others where not able to recreate this problem it seems no general bug but more a borked setting. It doesn't matter if the setting was borked by a twisted bit, a dying platter or as you strongly believes that the Plasma guys "broke your settings". Did you try to create a new user?
Ever confirmed: 1 => 0Status: NEW => UNCONFIRMED
I agree. I accept that it's a borked setting, and I'll have to correct it by starting with a fresh user and porting all of my settings manually, which will be a slow process since there are quite a few of them and I can't find any documentation about what lives in which file. Closing as INVALID for the time being.
Resolution: (none) => INVALIDStatus: UNCONFIRMED => RESOLVED