Want to PR it and I can test for you so you're accredited in the history? 🙂
Want to PR it and I can test for you so you're accredited in the history? 
JOh, I guess for brevity, it should be
INSTALL_LIST=$(< ${INSTALL_LIST_FILE})
Jlol, no, it's okay, I'm good with not being credited for small shell script fixes
Z
EHaha. Just want to be sure
ZApparently others have encountered what I've had but was fixed in early versions of gnome
JBesides, then you get all the 
if it breaks
if it breaks ELmao
SI've just tested this, on stock fedora it looks like fbdev gets appended by default as now that i've set it to 0 the tty resolution is back to being horrible
SBut Gnome Shell doesn't crash on screen lock anymore
Sjk it still crashes :/
SBut yeah, I can confirm that on Silverblue (not Bazzite specifically) fbdev is set to 1 by default
J@EyeCantCU I don't know if you use it, but I recommend installing
shellcheck when working on shell scripts to double-check all of your string quoting.
EWas considering adding it as a CI check
KI smell another safety check build step
ESince there's an action for it as well
KThat's okay we can share the brain cell today
ELmao
ESafety Checkception incoming
Zshellcheck has been a life saviour for me when creating a giant ass multi-step bash script
Hshellcheck is great
you can also disable individual checks for individual scripts where you need to "bend the rules" a bit
you can also disable individual checks for individual scripts where you need to "bend the rules" a bit
JI PRed a shellcheck action but it went over like a lead balloon heh
ZAlright so my only option to get a bit more proper colours on this display is to get a display calibrator
ZTo bazzite?
Jsome of the repos but it'd be nice to have them everywhere
ZIs the bazzite scripts not shellchecked?????
ZStop the presses, new CryoByte video
JI've looked at enough of the bazzite scripts to know that they're not all shellchecked, so if there's a way to make it happen automatically it would be a clear improvement.
ZI mean, shellchecking them using vscode is easy peazy
IHmm sorry to hear it is still crashing. Hideous tty is indeed a consequence of setting it to 0; on the bright side it shouldn’t be any worse than it was under 535? (At least that was the case for me) I believe you can set it back the way it was using kargs —delete=nvidia-drm.fbdev
IFor me I was completely unable to wake bluefin (GNOME) from sleep 100% of the time, and bazzite would refuse to let me past sddm like 60% of the time
PI can't seem to figure out how I'm supposed to edit my kernel cmdline? Do I just use grubby?
Erpm-ostree kargs can be used to add/remove kernel argumentsJI use
rpm-ostree kargs --editor.PShould've known it was handled by
rpm-ostreeIt is the same as 535, I'm on Fedora Silverblue but I've realised a very custom system
SGDM on my end sometimes fails to start Wayland, only Wayland
SAnd yeah lock crashes Gnome Shell for but only after the monitors fully shut off
SI wonder if it might be related to having a dual monitor system 
SI remember at some point not having this issue but I can't quite put my finger on it
SOther than these 2 things the main remaining issues I have with Gnome on Nvidia Wayland is stream freezing on direct scanout (fullscreen games) and the stream in general having a very high CPU impact also creating some sort of constant frequent stutter
SThe correct term might be jidder but I'm not sure
PIs anyone aware of whether or not it's possible to add multiple custom modes to the same output via kernel args? Something to the tune of
video=<output>:<resX>x<resY>@<refreshrate>,<sameoutput>:<resX>x<resY>@<refreshrate>PKernel documentation didn't help me here
IYes, I should have specified: this was all under Wayland for me too, so at least there has been the fallback of X11
Pthis seems to work, if it's worth anything to anyone. I'm not doing any overclocking just adding resolutions that my monitor EDID lacks, despite supporting
CSince you're on @KyleGospo - I just got a new monitor and am testing out various games with 535/545. I'm having pretty horrific performance issues with specifically Dyson Sphere Program on both, with or without VRR/Freesync enabled, and different proton versions don't seem to help much. Different resolutions and refresh rates don't help, and the game seems to not be using system resources right when this monitor is plugged in, with or without another monitor. Any ideas for parts of the tech stack I haven't tested, or things which just aren't there yet upstream which could be causing this?
CAlso: the system copy of Prompt is working now
KThat's very strange, I'm afraid I have no idea where to even start on that one
KThat I'm glad to hear, it's like we thanks to us building it against stable GNOME rather than the nightly flatpaks
CGotcha
