Thank you for the detailed response. It will be good to have this information available if the need ever arises to necessitate updating the firmware for a more critical issue or feature. That said, I think I will accept the cautions and hold off on taking this action for now.

I don’t “need” to really…just noticed that there is a newer version with added functionality and was curious about the process since I had never done it before. I have been using basic keyboards like membrane and chichlet styles but I have been interested in getting a mechanical model for a long time. Finally decided to go for it after having to reset my 13 year old MS curve for the 3rd time this week in order to log into my computer.

So this also purges one more element of the despicable microslop ecosystem from my life and gives me what is shaping up to be a better typing experience as well. Based on the feedback, it looks like I should just hold off on making any changes until something more groundbreaking or critical needs to be done to my keeb.

The title of this post caught my attention since I was wondering if I was missing something…I have a learned distrust of sleep mode due to peripherals occasionally not wanting to “wake up”, resulting in me having to reboot the device anyways. Granted, I haven’t been using Linux for very long so most of my computing experience is with MicroSlop OS machines; but after using them for 30+ years I have never heard a good argument for not shutting down if it isn’t a critical system like a server. It should also be noted that I have lived in places were AC mains power being on 24/7 wasn’t always a sure thing, so that probably plays a role in my thinking as well. Is there anything other than anecdotal evidence that suggests full power cycles are truly harmful and/or reduce service life? Truly curious now since I have no desire to buy new parts anytime soon given the current price hikes and availability issues.

Just as an update to this, I noticed that there was a new version of gnome control center (49.4-2.fc43) in the latest update push for Fedora so I took a chance and did the upgrade hoping it would include a fix to this issue. Based on initial testing on my two machines at home which were affected and needed to be downgraded to 49.1-1.fc43, it looks like this new version resolves the line-out audio problem. Thanks again for your efforts to raise awareness of this and your suggested workaround.

I checked it last night and it looks like Lutris switched the game to Proton-GE in the runner options so I am guessing that requires a bit more time to spool up in the background. Switched it back to a version of Wine and it was back to loading immediately. I am all for updates that fix things or add features but it is a bit annoying when settings get changed like that and it sets off the need to troubleshoot to figure out what happened. That said, I am trying to get my wife’s Win11 machine working like it did under Win10 and I hate every minute of it and will take these kinds of things as the price of FOSS.

Of course I read your response in more detail as I am posting my own inquiry about this. I will take a look at the Lutris game-config settings and see what they are now. I wish I knew for sure what it was configured as prior to this update. Could you please elaborate on what you had to change from and what you changed it back to? Cheers.

I have only been running one of my GOG.com games via Lutris and it has been working like a charm till this weekend. I was initially concerned/confused when I clicked to launch that game from the link on my dock and it just didn’t do anything. Eventually, the game loaded and seemed OK with no data loss but I was still rather confused about what had changed (I regularly update my Fedora 43 Workstation system, daily or every other day). Can anyone elaborate on the recent changes to how Lutris handles games? I was running Disco Elysium via Wine (I think) and while I can accept the 10-15 second delay in the game startup now that I know something is going on in the background, I would like to have a better understanding of what, if anything, I could change to restore the former configuration.

Hey I tested the downgrade script and it fixed my issue just like you suggested. But of course now my OS wants to update the files back to the version I rolled back from. It doesn’t seem to be a forced update and I updated and upgraded everything before I tried this but I was wondering if the issue will immediately return once I allow the system to go back to version 49.4-1.fc43.

Doesn’t look like there is any way to skip those file updates so I suppose I just need to do the downgrade again if the sound problem returns? Hoping the next revision of gnome-control-center resolves it.

Thank you again for your efforts and information sharing. This is what I love about the Linux community and it is making the transition from commercial slop-ware so much easier.

Thank you for working through this and sharing your findings. I will try this out tonight.

I am seeing the exact same issue on a PC I just put together and loaded Fedora 43 Workstation on. If I hook the 3.5mm jack for the speakers (older Creative Pebbles) to the green port on the back panel it shows up just like OP’s when I try to test; however, if I plug the jack into the headphones port on the case (which is connected to the motherboard audio pins) it detects and works properly. I was also seeing some Dummy Output options with the line out connection in use, and not knowing what it meant, I selected one and this kicked me back to the login screen and gave me an unhelpful kernel alert.

In contrast, the speakers on my other PC, which is also running Fedora 43 Workstation, works fine off of the back panel. Both motherboards are using Realtek audio chips but it may not be the same version since one board is a B650 and one is a B550.

Curious to see what the solution ends up being but I also recently installed pavucontrol on the newer PC so I will try and set the speakers up using the line-out that way. If that doesn’t work I will migrate to bluetooth speakers or just leave things as is.

Good call. I think this post has definitely been worth the effort since you guys are giving me some ideas I wouldn’t have thought of otherwise. Thank you!

Thanks for the feedback. I haven’t tried pulling one stick but I did replace them both so I figured that eliminated them from suspicion. I also tried manually adjusting all of the primary timings and the speed to see if the XMP defaults were just being applied wrong. I think the voltage settings are my most likely culprit in this case so at least I have another thing I can try which doesn’t involve a complete tear down and waiting another week for yet another part to get to me.

Thanks Shadow. I had never considered something like this and all of the other suggested fixes I found via forum posts pointed to the physical hardware being the most likely causes. I will try and manually set the SOC voltage tonight to a fixed value (since I am 100% it is set to Auto) and do some more testing.

Just out of curiosity, what voltage ended up working for your setup? From what I am reading in the linked post and a post which is linked within it, I could go lower (0.9200-0.9600; leaning towards 0.925 VDC) or higher to something like 1.1VDC, but one comment mentioned higher voltage can actually increase instability…ugh. Anyways, thank you for the reply and suggestion!

This is really interesting. I started with Mint-Cinnamon since it sounded like it would be ideal for me as I had no desire to switch to Windows 11 and I needed a daily driver OS; I did not like Mint at all and spent too much time trying to make it work with newer hardware. Fedora Workstation has been a great experience for me and it checks all the boxes with minimal troubleshooting. What is about Arch that made you decide to switch? Genuinely curious as I am all-in on Linux now that I know I can do productivity stuff and gaming so easily and I don’t have to give another dime to MS.