why would there need to be a fresh reinstall for an immutable os? I can see why you want ~/ to be re
why would there need to be a fresh reinstall for an immutable os? I can see why you want ~/ to be refreshed but the core system is immutable
T@dnkmmr @Alex&Indie @BearFOX did you use the
ujust-deck
Dwhat is the default?
Tboot into game mode on startup
Knot seeing any gamescope crashes in any of the logs I've been sent
Kand I'm unable to reproduce this on my LCD or OLED decks
KMay be a steam crash rather than gamescope
Dare you on gnome or kde. I am on kde
Kboth
Dyou checked the ones in #Gamescope frequently crashes on boot ?
Kyup
Kbasically nothing in those
Kthere's separate logs for steam and for the params it's launched with, 4 in total
Kwould help to have all 4
BOkay so I found that if I delete the gamescope folder in home/deck/.config then on next boot gamescope WILL load normally
BBut on next boot when that folder has been regenerated, it boots gamescope to black screen
BThat's consistent as I've checked three times over for each scenario where the folder is there / isn't
BI also see the steam runtime environment gets setup again if I had deleted the gamescope folder
Kwhen did this start? Last gamescope build was 15 days ago and it's the same version we built over 2 months ago
K3.13.19
BFor me it started when I updated to 23rd Feb build. But I'd been on a December or January build before that as I don't update if I have a active game I'm playing through
BIt doesn't seem to matter which build I'm on since then, as I'm currently rebased to Feb 5th
DCould it be possible to have a systemd service that will attempt to reload gamescope if it crashes?
KWould that not just be an infinite loop? It's a session
Kreally don't want to implement hacks like that, rather we found out what's affecting both of you
Dor display some sort of error or even give the user an option to boot to desktop?
KIt should boot to desktop assuming the session crashes, that's the behavior I get
Kso I'm doubly curious what's going on w/ your installs
DIDK. I don't have any layered packages installed
Bhere are all my logs from HOME. it includes the log.old files too as my last two boots were a successful gamescope boot and an unsuccessful black screen boot https://we.tl/t-LjH9ZEqvaV
9 files sent via WeTransfer, the simplest way to send your files around the world
Blet me know if you prefer me to send them another way
BOf those files, .log is the successful gamescope session, .log.old is the black screen gamescope
The
The
drm: messages are where the boots differ in the two .gamescope-stdout files I provided
Mweird, looks like its not seeing your internal display connector for some reason in the failed log
DI reccomend using
cat logfile | fpaste instead
Koo, good catch
Kwasn't looking that early
Kfirst one says it's DVI??
BYeah but only when there are files in /home/deck/.config/gamescope
So I deleted the contents and set the folder perms to unwritable and now gamescope boots properly every time
So I deleted the contents and set the folder perms to unwritable and now gamescope boots properly every time
BThis is undocked LCD Deck btw
BI have sunshine rpm layered but dnkmmr doesn't, so it shouldn't be that
Dwill that break my system?
BI have been regularly clearing the contents of this folder to get a successful boot but this is the first time I removed the write permission for owner/owning group. It's booted twice fine since. Logs show that it failed to open edid.bin.tmp but then it moved on and boots anyway
BBut i'd say be prepared to have a way to revert that change (via a liveCD or something) should it cause you trouble
MI believe that folder is usually how Gamescope corrects your display orientation and presents it as a native landscape display to programs running in Gamescope
Mit writes a temporary EDID into that folder and reads from there the next time you boot
Mor session-switch I suppose
Mso perhaps it ends up writing the wrong display info and reads from that, leading to a crash
Mit’s strange because I haven’t noticed this at all on Nobara, and our packages are closely aligned enough to where I’d expect to see this on there too
Ksince it's not affecting either of my decks there's likely some extra factor here
Kwhat that is though remain to be seen
Mit doesn’t look like the crash I was running into in Gamescope either where it gives you the failed modeset line at the end
