Tnp. you may need to apply that env var prior to installation if this is not an existing one
Bwow, that works...
I edited the "Battle.net" "program" by changing it's launch options to include that as a prefix and it worked right away
I edited the "Battle.net" "program" by changing it's launch options to include that as a prefix and it worked right away
Tsweet
Bthank you very much!
i'm feeling a bit frustrated I didn't find that on my own... but it looks like a new issue?
i'm feeling a bit frustrated I didn't find that on my own... but it looks like a new issue?
Tyeah fresh with today's update
Tand WOW release (i think?)
Bi picked a great day to try to get back into StarCraft LOL 
Bi don't feel so bad now
Tlike termdisc, i also have it on a seperate drive. it does disappear in GRUB for me too, but usually i can get to it by going into the BIOS boot menu and selecting the drive that has Windows... but if windows is in the same drive idk if that will be an option
EThat's so weird. I was playing wotlk classic today and got disconnected and couldn't relog because I was met with the error.
Was just super annoyed because it was working.... I'll try this and see if it fixes my install :0
Was just super annoyed because it was working.... I'll try this and see if it fixes my install :0
TThe update just got pushed today. If you were running the previous version 14494, you could continue.
H@KyleGospo single gpu passthrough is full of more pitfalls than dual gpu passthrough (2 gpus on system)
the vfio stuff we have in the justfile right now is stuff that is pretty easy to configure (yet people fail at it) and is pretty much set in stone.
if that for example in the future should be expanded to support passthrough with identical cards, it would require us building custom scripts into initramfs that is specially tailored to the users pci ids for their gpu that they want to passthrough.
- the problem with it is that it is very system specific, the script has to be tailored to each system depending on what the user is running (this is however kinda solved with ublue assuming the user does not have a container running using the gpu or a layered program that does not close entirely by stopping the display manager)
- there is even less systems that support single gpu passthrough than dual gpu passthrough
- 3D controllers cannot be passed to a VM, well it can but you will never get it to work as it relies on the main gpu to even function and VMs do not have access to that.
- if anything is still using the gpu when the display manager is stopped, you at best get a black screen and need to restore the system through tty or you get a frozen system with a black screen
- it doesnt really solve anything other than being a good party trick? unless youre a person that does a lot of OS testing (lets you rapidly test OSes without having to install them directly on the hardware but having access to your hardware)
- intel is the only supported igpu for using in VMs but not the way you would expect since it will keep the host display active so you will need a different way to view the VM screen (spice will not work, not sure if looking-glass works for this method)
- hooks for the single gpu passthrough has to be manually set up for every VM you want to do it on (unless you want to make it do it on every VM)
the vfio stuff we have in the justfile right now is stuff that is pretty easy to configure (yet people fail at it) and is pretty much set in stone.
if that for example in the future should be expanded to support passthrough with identical cards, it would require us building custom scripts into initramfs that is specially tailored to the users pci ids for their gpu that they want to passthrough.
Hits not part of the deck image as valve disables a lot of virtualization stuff for the deck as it can interfere with games
Hif you enable it, bazzite-hardware-setup would just disable any virtualization related kargs again unless you run a custom image
Hujust regenerate-grub
SIf that is the intention, then that doesn't work. I changed kargs and they persist
Hit will happen when hw_ver gets bumped in bazzite
if you enabled iommu for example it will get turned off again next time bazzite tells it to run a full check again
if you enabled iommu for example it will get turned off again next time bazzite tells it to run a full check again
SGotcha, so it is update related
Hyeah
Hit might have changed though let me check
Hshould in theory only happen on the deck, didnt back when i originally tried
IDid you click the dots next to the program in the "Details menu", then add it inside the "Command Arguments" field? I'm not having luck.
AAlright
AGonna try out the testing for ally
AAlright got it booted up and QAM works!! Both menu button and the QAM works, tdp limit is only at 15 but as Kyle said just to use decky loader. Now the audio needs to be fixed and the keyboard on desktop mode as well
AScratch that
AKeyboard is working in desktop mode!!
AThe audio still is the issue though
KThat's interesting, audio patches should be present
Kmaybe we're missing some firmware, I'll dig a bit
AI believe it’s bios dependent
AMight need a dsdt override patch
ACould be wrong though
AIf you want I can pull up a log or something
Fhi all
Fhow does bazzite work exactly?
FWhy did they decide to containerize fedore?
Kthat check is looking for amd_iommu specificly on purpose
Kinstead of deleting it, you can change it to enable it
Kand then the check will pass in the future without undoing what you did
Kwe didn't, fedora was already in that process. See OSTree, CoreOS, Silverblue, and Kinoite
KInstead, we're building off of that work by making them gaming-ready
Fwhats the additional features that bazzite introduces?
Kin the case of the deck, I believe ostree offers a much more compelling immutable experience than SteamOS can
FAre you a bazzite dev, btw?
Kyes
FNice, may I ask what your background is?
Kin our case, package layering. You can
rpm-ostree installsudo dnf installKand these are kept across updates
FI've always been incredibly amazed at the folks working on open source projects
