I wonder if you have the same issue I had. When gamescope was blank with a blinking prompt, I never tried Ctrl+C. My workaround was empty ~/.config/gamescope then set the directory to readonly
Yeah, it automatically sets the native/max res of the external monitor which can be good/bad depending what you want it for. Res can still be adjusted for desktop mode
i was playing P3R and suddenly I had mid-30s fps, so I just kept playing and now even Mk8 is not smooth, like it was always upper 50s. Frametime all over the place
i switched to desktop mode, then back to gamemode, steam defaulted back to the og one, and trying to set up bazzite startup video again results in a black screen
That is the way your device communicates urgent attention, like pain in your body you can continue disregarding it but you will get more problems at the long run at the end... It's better to take a break in those situations and let your device cool down a bit... OR....use lower graphics settings if you can.
Hey guys, another question from me I'm really enjoying Bazzite for its working TDP settings, and nice scaling options, I think I can never go back to windows. Most of the time I'm using Moonlight to stream from my (wired) desktop (AMD 7800x3d + 4090) to my Legion Go, but I'm experiencing stuttering (and overlay info from moonlight detecting slow connection) roughly for 10 seconds every 5 minutes. Before and after the stuttering the stream is smooth. I tested HEVC/H.264 and bandwith options, tried several settings on the win11 host without any change in this behavior. I then installed Moonlight under Windows on the Legion Go, and the problem is not existent there. To further debug, I let a iPerf3 stream (with 10MBit/s, UDP) running in parallel to the moonlight stream in Bazzite, and when moonlight complains about bandwith, the network errors in iperf3 are peaking as well. Long story short: is the network driver that is used in Fedora/Bazzite the problem? Always thought, that Linux is especially bullet-proof when it comes to networking
could be a number of things, if you are suspecting its the linux driver, may look into dmesg output logs anything regarding the wireless driver. I'm not too familiar with the legion go, do you know what kind of wireless device its using?
I also wouldn't call it bullet proof, its about as bullet proof as any other piece of software, bugs come up, and sometimes gotta wait for kernel patches to fix them.
my strategy for debugging any hardware issues is look for dmesg logs, and then google for lines i find in my dmesg logs, excluding any information that is unique to me (timestamps, hostname, etc.) and hit up all linux forums, arch forums are most useful since they tend to get hit by these kind of bugs first and they will link you to threads about ongoing bug investigations and PRs
lastly, reason i asked if you know what kind of wireless device, is because idk if it will show up under lspcilspci or lsusblsusb, try running both and see what comes up, sometimes knowing the vendor of the wireless device (and ideally model) helps in tracking down the state of support for it within linux kernel