Kyeah, we base on Fedora Silverblue and Fedora Kinoite
Kit's all ostree based
DI see
DBazzite is very similar to vanilla os and blend os
Tmore often than not, game mode will merely scale the desktop window size without maximizing it unless the window already is or is instructed to do so. this is how game mode's compositor works. it does not on its own force a change of aspect ratio. one big example of this is the Battle.net launcher's default size put the Play button just off screen, and the window looked ultra wide. resizing the window or maximizing it in desktop mode and returning to game mode made the button visible
Dsimillar but using different tech
Fedora use ostree which is git for operating system
Fedora use ostree which is git for operating system
BDidn't know if it had been said that this issue affects the LCD deck without a display overclock.
New artifacting with overclocked Steam Deck display
New artifacting with overclocked Steam Deck display
EIs this an issue on testing?
EOh, okay. I see. Nvm. Will look into getting builds out. Should be addressed
K@Bazzite Maintainer @j0rge
EDidn't think we'd get there so fast lol
ENew builds on latest in 15
Jnice!!!!!
BUpdating now thank you!
ENo problem!
BCan confirm no <60HZ wibbly issues on LCD deck now. Thanks for the quick fix all
RAnother weird question from me - does /usr/share/pipewire/pipewire-pulse.conf.d/wine.conf ship by default with pipewire-pulse package or it was added manually by Bazzite devs?
RBecause it's the root cause of all of my issues with audio stutters/lags/distortions
RIt has override for wine anything with pulse.min.req and pulse.min.quantum as 1024/48000
RYeah it's working even with the OC now
RChanging both to 128/48000 fixed every audio issues I had 
RUnless there are any downsides to it (other than nebulous 'higher CPU usage'), I'd suggest to ship ootb with both of those values set to 128/48000
RAt the very least, that's what I noticed stock SteamOS on OLED ships with (based on output of
pw-top and how much quantum is assigned to run WINE apps/games).
FIs this an issue with wine only? I saw some people use this to reduce audio latency overall.
Hhmm not there for me on deck :latest image, but also has not updated today so idk if it came would have come with the newest build
R:testing(running on OLED)
Hahh that makes sense then so its new
KInteresting, I'll see about adjusting this
KIt's needed on OLED to fix audio
KWithout it it's a mess
Hhopefully 128/48000 wont make audio a mess on other devices then 
Pwould be fine
Ppipewire's default of 32/48000 as min quant is extraordinairily low
P0.66ms of buffer
P2.66ms at 128/48000 is still quite small and basically imperceptible delay to non-musicians
Hi wouldnt notice for sure 
Pfor reference most windows audio drivers can't even get below 10ms and no one's complaining there (and the audio professionals are all using ASIO specifying the crazy low buffer setups manually)
Hthis is how much of an audiophile i am
sound: yesFhow to set that as default though?
FI just read PIPEWIRE_QUANTUM & PIPEWIRE_LATENCY is just for jack applications & Fedora doesn't have pipewire-jack
Ppipewire supports breaking up the config into as fine of chunks as you need in XDG config spec location
Phaven't personally had to touch it since it was at version 0.3.3 or something so a couple years back
Pbut it is quite intuitive, don't think the devs would have any issue modifying it globally (or just adding it to the setup for deck images)
FI would test this in my image for sure
Pfor clarification PIPEWIRE_LATENCY works with alsa, jack, and pipewire
Pit requests specific values, i think the issue here is more with the minimum allowed
FIt doesn't work for Firefox flatpak for me
it shows 2048 quantum
it shows 2048 quantum
Psome applications will request "the lowest i can get!" and that can cause issues 
Pfirefox is using pulseaudio
