game mode is specifically the gamescope session, so desktop lacking that simply means it acts like a
game mode is specifically the gamescope session, so desktop lacking that simply means it acts like a normal desktop install of steam on KDE/GNOME
Ktotally fine for dev work too
Lokay, so the difference is that the deck image uses gamescope instead of another DE ?
Kin addition to, behaves exactly like the Steam Deck
Kwhere it boots to steam gamemode, and then you can boot to a kde/gnome desktop from it
Lokay
Lso what are you actually missing if you don't use gamescope (in the desktop image)
Ldoes HDR still work ?
KHDR only works in game mode ATM, but the next release of KDE will support it via a vulkan layer
Lokay, but then if I want to use another DE or have HDR right now in games, I can still install and run gamescope manually ?
Lwithout too much problems ?
KDEs are best part of the image, if you don't want GNOME or KDE my suggestion would be to fork
Sis the gnome gamescope still cant switch to window mode for ally
S?
Labout forking, would the easier way be to use startingpoint and bring bazzite stuff in or forking the bazzite repo
Klatter
Kand it won't be easy
LIt seems like they are using very different setups
Sdoes bazzite deck come with ssh enabled already or do I have to enable it? trying to transfer some files
Kdefault enabled upstream at fedora, make a key and it works
Lbasically editing the Containerfile and the system_files folder ?
Sdoes it not have username/password ssh? how do I go about making a key then?
Lif it's just stuff like installing and configuring another DE and thing like that I think it's manageable
Kit's configured by default to not allow that
Kyou can change it
Show?
Hi thought the VC was really cool @j0rge. i agree with pretty much everything you said. except i believe it could be even better then standard chromeOS. only a few years ago i was assisting my local high school and middle school and the process of managing the atomic chromeOS and all the bugs inside of it was insane. if anything happened if lets say the bluetooth or wifi broke or chrome decided to not work then the easiest solution was to literally reflash the entire operating system. i feel like ublue could solve that a lot if they could have a signed internal image with known working packages instead of praying google doesn't push out a broken update or it doesn't just break on it's own
K@antheas Next release has BMI323 and BMI150 blacklisted on ASUS images. I've also messaged Sentry about the kernel build options. That just leaves the patch in 6.7
K@CharlieBros ^
Aadding ayaneo air support right now
Auses the same driver
Kbeauty
Asame everything as ally
Ksame need to blacklist 150?
Ayep]
Kok, I'll just do that global then unless you know of something that *needs* 150
Kglobal meaning all *-deck images
Ai do not know of a device that uses bmi150 and would need hhd
Kand what's the product name of that Air device? I'll just add it now to be ready
Abut maybe theres an obscure one and it will break autorotation on it?
Aone sec
Athe bmi is "AIR Plus"
Admi*
CAnd what blacklisting those modules do for the Ally? Does it fix the sleep issues or that’s until 6.7 drops?
Ksleep is 6.7
Kfixes gyro
LI think I'm going to do the following :
- fork bazzite
- Add new variants for my version and a friend's version (I think sharing a repo would be easier)
- In the containerfile, at the end, include either his script or my script.
- Setup the repo so that customizations we add are separated into different scripts inside a new folder so wen can enable/disable/share them easily
- Maybe try to disable other unneeded variants in the github action's build.yml
LWould there be any downside to this setup ?
KThanks, that'll enable HHD now and also has a defined nested desktop resolution
Kand bmi150 is disabled on deck builds in favor of bmi323
Kjust the maintenance burden
