ATell me your current bazzite version then run this:
rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-deck:39-20240220Ashould be able to see the current version in settings
Ahey the golden version came out on my bday
A
Ai need the version string not that unfortunately
Ai dont know where it is
A20240220 should look like this
AOh 
I thought I’d done well getting that info up 
I thought I’d done well getting that info up Afind it in steam settings, i think thats the easiest
TMaybe
rpm-ostree statusor that yeah run that
A
TAlso, with the screen flashing, are you using the frame limiter?
AThanks hopefully this is what I wanted to find
Acan you open a help thread with a tldr?
Awe'll ask some questions there
A
Awhile the command I sent you is running
AThanks will go to help
VSorry to bug you, had a quick question regarding the post I'm replying to here. None of what would disable or mess with anything related to the GPU since it doesn't actually know what you're going to be using, right? I know you basically said that, I'm just coincidentally having a strange flickering issue in Factorio that I'm 90% sure is just unfortunate timing. I haven't yet decoupled the GPU from the host and I'm assuming that command doesn't do anything related to that either.
Hit just enables the kernel modules, it does not bind the gpu to the modules (it gives you the command to set the kernel args to bind the gpu but you will have to find the IDs yourself)
Hso yes it does not touch the gpu
VRight, so just bad luck. That's totally cool, just making sure I hadn't broken anything
Hnp!
Hif you want to test you can undo what the command does.
there will be an undo function in the big just refactor i am doing.
let me dig it up
there will be an undo function in the big just refactor i am doing.
let me dig it up
VYeah that would actually be great!
VI realized just in the nick of time that I was following a guide for dual GPU passthrough and panicked lmao
Hyeah we only support dual gpu passthrough, you can do single gpu but you will be on your own 
VNot the end of the world by any means lol
Hmainly because singlegpu is a nightmare to even attempt to support
VYeah I was seeing that as I researched what I actually had to do
VNo harm done yet thankfully
Hi believe those are the commands you would run to undo
enable-vfioVI'll give it a shot!
Hif you rely on the kargs for anything else, remove the ones you want to keep from the command
VDon't think so, just need go through this, restart, and see if it fixed anything. Very good chance that this is all coincidence and Factorio is just... angry. Even still, it worked last night, this was the only thing I changed, so I'm trying anyway.
Hit is worth a shot
Hi have had a handful of systems in the past that just refused to reboot normally after enabling iommu but everything else worked fine
Hbut those systems were also ancient
Jcould not repro, but here it is:
I'm using the gnome deck version, downloaded yesterday on Bazzite's website.
I'm using the gnome deck version, downloaded yesterday on Bazzite's website.
VAlright reboot time
JAlso, suspend doesn't seem to work well, so going to rollback to previous release
FSingle GPU and dual GPU passthrough are very different beasts. I researched single GPU for a couple months before deciding to just save up for a used second GPU. So much easier.
Jrolling back did fix the suspend issue, so there's that, at least
TIs anyone else here running VRR-patched Gnome with an AMD GPU? I think I might be narrowing in on a bug but it would be nice if someone else could test and verify, too
Hi do both single and dual gpu, i also develop 2 tools to specifically help with gpu passthrough (mainly dual but one of the tools is useful for both)
testers are few and far between (especially since i dont use the main tool myself anymore since most my stuff is now ostree based)
testers are few and far between (especially since i dont use the main tool myself anymore since most my stuff is now ostree based)
TAnd to clarify a bit more, I think VRR does not function properly when running games with high GPU utilization unless you disable KMS modifiers by setting MUTTER_DEBUG_SEND_KMS_MODIFIERS=0
TI believe in both Xorg and Wayland but most noticably in Wayland.
VUnfortunately, removing the args was definitely not the fix, but I expected that anyway. Regardless, good to remove args I won't actually be using lol
TI've been trying to figure out what's going on with VRR on Wayland for a while now and the other day I finally put together this theory from several different issue tickets in different window managers. Many of these WMs and DEs just use VRRTest or something to test that VRR works, but the issue only pops up when you're running an actual game. If you start up VRRTest, then start a demanding game on another workspace and switch back to VRRTest, you should see that VRRTest starts to stutter and skip. When I disabled KMS Modifiers, VRRTest no longer stuttered and skipped--it's also noticable in game of course, but checking VRRTest with high GPU load is a more consistent and obvious way to see if VRR is still working.
