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:
Mweird, looks like its not seeing your internal display connector for some reason in the failed log
DI reccomend using
cat logfile | fpaste
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
BAre edid.bin files user readable? I can send a busted one? In gamescope .config folder modes.cfg was blank and bootstrap.cfg just contained
set_bootstrap=1
Rdoes anybody know how steamos advertises its hostname across your local network? What I mean by this is I can enable sshd on my deck. I can then change its hostname to anything, in this case 'oleddeck'. Then I can go to my workstation computer and type ssh deck@oleddeck and the hostname gets resolved. If I try with my new bazzite install, the hostname fails to resolve, but I can connect normally with the internal IP. (like ssh deck@192.168.1.20 or whatever). Not any issue I've just been curious how this works.
ASomething something multicasting
AAlmost never works properly
AWhen it does it's sweet
AIf you want something similar, setting a static IP for your deck and then using your ssh config to resolve it also works
SAvahi daemon is the one doing mDNS. Maybe that will help you look into it
