Says its on 6.6.3-666.rog.fc39.x86_64
Says its on 6.6.3-666.rog.fc39.x86_64
Kwrong kernel, can you
rpm-ostree status
A
KI'll see what's up, ally should have the fsync kernel
AThe controls are laggy again as well
ALike when we had steam patch at first
Kthat will happen as long as the kernel patches are missing
Kyou could try rebasing to bazzite-deck:testing, or just wait for next update on bazzite-ally
AI’ll rebase it to deck and see where it goes
AGyro finally being added properly to the ally now
ABazzite deck works buttons work!!
ABazzite-deck
AATdp limit is at 15 though
Ksteam-patch should be fixing it, if it's not there's a decky loader plugin you can use
Kwhich I would recommend
ANo audio though and in desktop mode I can’t bring up the keyboard
EProbably an issue with the logic I wrote in ci
EFound the issue. Kmods get set to fsync but my case statement is flawed because Ally isn't an image flavor. Will fix this up
DI need help regarding vfio
rpm-ostree kargs --append-if-missing="vfio-pci.ids=xxxx:yyyy,xxxx:yyzz"'
How do i disable? After running it or change to my 2nd gpu
rpm-ostree kargs --append-if-missing="vfio-pci.ids=xxxx:yyyy,xxxx:yyzz"'
How do i disable? After running it or change to my 2nd gpu
DDo i rerun the command?
ZWelp, just updated Bazzite deck and now my keyboard and mouse won't work
ZOhh! Fixed it! My deck bios changed the USB mode back to DRD for some reason
Hyou just press E in the grub menu and remove the
vfio-pci.id=xxxx:yyyy partDThank you.
Hit will be a 1 time boot without the passthrough
Hto modify it you will need to to change it with i think
rpm-ostree kargs --replace=vfio-pci.id=OLDVALUES=NEWVALUESHyou can verify if they changed correctly with
rpm-ostree kargsDI see thank you for the help
Hthe replace command is exact though
Hso you need to use the exact order of the values for the OLDVALUES
DIm still trying to figure out hook where i can change my main gpu back and forth
Hyeah thats more complex to do properly, hence why we only make it easy to dedicate a gpu for passthrough
Mhttps://lkml.org/lkml/2023/11/26/264 there’s an updated sleep patch for the ROG Ally from Luke, just in case you weren’t aware of this for the fsync Ally version.
Hsince there is like a billion things that can go wrong with hotswapping the card to and from the host and VM
Hso if people want to chase that, we leave that up to the user
DBut can it actually hard my hardware? Or only software side?
Halso hi i am the person that wrote vfio stuff in bazzite 
if you do have any vfio questions just shoot them my way 
if you do have any vfio questions just shoot them my way Hwhat you mean hard your hardware?
DHarm*
Hnot the way we did it.
only way it can potentially harm it is if you passthrough a gpu that pulls with it other things from your system like lets say some important sensors because it shares IOMMU groups with it (without crashing the host)
only way it can potentially harm it is if you passthrough a gpu that pulls with it other things from your system like lets say some important sensors because it shares IOMMU groups with it (without crashing the host)
Hthis is why using something like ls-iommu to check the iommu groups is super important
DI will keep that in mind.
Hat best if you do it wrong the host freezes/crashes
Hat worst you pull in something essential for host stability into the VM and the host has no idea something is wrong if something does become wrong
Hi maintain this which is a bit better version of the bash version of ls-iommu
https://github.com/HikariKnight/ls-iommu
it has some switches to easily grab only what youre looking for
https://github.com/HikariKnight/ls-iommu
it has some switches to easily grab only what youre looking for
GitHub
A tool to list devices in iommu groups, useful for setting up VFIO - GitHub - HikariKnight/ls-iommu: A tool to list devices in iommu groups, useful for setting up VFIO
Hanyways i will be heading out now, should be back in about 1 hour or 1 hour 30 mins or so
D
Hthe chances of something getting damaged is low though, in most cases the host just freezes or crashes, but i will not rule out the possibility of a system where the user ignores that the gpu shares a group with something important and it "works" but pulls in said hardware without crashing the system then causing an issue further down the line 
in short, if something doesnt look right, ask and dont do it unless you are willing to experiment and find out (most of the stuff that could get pulled in with the gpu is motherboard only stuff anyway).
in short, if something doesnt look right, ask and dont do it unless you are willing to experiment and find out (most of the stuff that could get pulled in with the gpu is motherboard only stuff anyway).
Ihttps://github.com/ublue-os/bazzite/issues/593 Where is the right place to put a persistent warning about/solution for this & the XHCI USB issue? Like either on the website or somewhere in the UX.
GitHub![[[CRITICAL]] Bazzite Deck Goes to Black Screen on Boot · Issue #593...](https://images-ext-1.discordapp.net/external/PJBN0I3ENlvPkXVFPw9mvRXOD6CnQR0jLZYNLVIFaTU/https/opengraph.githubassets.com/ccdc62da6f81b4a97c026af2ec7f46cab4e1c0c2aebe36eff89c9b9cf91026af/ublue-os/bazzite/issues/593)
As per title, steam deck is booting to black screen. This is a continuation of a prior issue. The proposed solution was to run rpm-ostree upgrade I did so at the time however at this time it is aga...
ITBH it feels like it perhaps ought to have been a release blocker / build recall since we tell people to use a physical keyboard to install and send people to game mode on startup. Also the fix to the black screen issue seems to require keyboard access 
