Happy new year! Over the past months, we have been refining Bazzite: a new bootc based updater with a progress bar, WinControls integration for GPD, fan curves for OneXPlayer, GPD, Ayaneo, hibernation support for Ayaneo/devices that wakeup, modern standby patches for quicker sleep, a bug reporting tool, less layering needed, Nvidia-deck (!) and much more.
New Beta image: nvidia-deck
Nvidia has not been a great experience in Linux yet. However, slowly but surely, they are getting there. Last week, we merged this gamescope PR, which was the final fix required for getting deck working on Nvidia.
Current status: at a resolution of 2k or less and without HDR, you’ll have a pretty damn good time. 4k, ultrawide, et al. will be stable at a later date, but you are welcome to try those and report bugs. Read the dedicated announcement here.
GPD WinControls Integration
Recently, we rolled out a GPD overhaul in Handheld Daemon, adding support for most WinControls features in Windows: remapping the back buttons, RGB, vibration strength, deadzone adjustment, and mouse mode of GPD devices. You no longer need Windows for any of these things, and they are a double tap away.
We chose to simplify things a bit, so if you want to do a completely custom mouse mode profile, you will still need Windows. For any of the mouse mode settings, if you set them to “Do not change”, whatever you set in Windows will remain. But we did not skimp on the RGB:
So you can finally rock your RGB on with GPD as well.
In addition, the back button remapping functionality makes the back buttons be 20Hz instead of the previous 3Hz, which makes R4/L4 usable in most games, and new features such as SteamOS chords with the Select button and turning the Menu button into a combo key (single press QAM, double press HHD, hold Steam Menu) mean that you can use both L4/R4 without skimping on shortcuts.
We’d like to shoutout the pyWinControls project here for doing the legwork for what each remapping code does. That was a lot of buttons.
Custom Fan curves
Thanks to developer Derek from ChimeraOS we got the ability to control the fan speed on a bunch of Ayaneo and OneXPlayer devices in mainline linux with kernel 6.12 in the module oxpsensors. Moreover, developer Cryolitia released a dkms kernel module that also made it possible to control fan speeds on GPD devices, also on lkml for review.
So over the past few months, I had started working on a new algorithm for controlling fans, which we released in December, initially for oxpsensors, and two weeks ago for GPD devices.
This algorithm is completely custom to be optimized for noise. Based on the temperature and using hysteresis, it first defines a target speed for the fan that changes only on large temperature changes (e.g., 10C). Then, it creates a polynomial curve that accelerates towards that fan speed and tapers in the end, ensuring that transitions are not noticeable.
It also allows using the Edge temperature sensor of the APU for measurements. This sensor is on the outer end of the sensor, and corresponds to how much the processor has accumulated heat. This makes the fan remain silent during bursts such as opening a browser, lowers the risk of the device thermal soaking, and results in a more even fan speed that is applicable across a wider TDP range.
However, it might result in mild thermal throttling, which is why most manufacturers do fan control based on the Junction temperature (Tctl). When that temperature reaches 80C for most devices (or whatever you set using the advanced configurator accessible through the eye button), the APU will stop increasing its power. As going to 80C can happen in seconds, your device will be a lot more noisy (the stock fan curve is based on Tctl). And because your device will hover around 80C most TDPs between 10-30W, you will need a custom fan curve based on TDP or you risk thermal soaking your device (i.e., it becoming too hot while gaming).
You also get a wIndow with current speed in %, RPM, target speed, and temperature readings to keep you in the know.
Bootc & Bootc Updater
All of us at Universal Blue have been excited for bootc, which is rpm-ostree’s successor and fully container native (rpm-ostree had containers bolted on as a feature). bootc leaves a lot of the legacy cruft of rpm-ostree behind, which makes it a bit faster in updates.
As bootc does not support layering yet, and it is a practice that we want to get away from (requires manual intervention every Fedora update), Kyle and Hikari worked to bundle sunshine and virtualization in all Bazzite images. Sunshine is also packaged officially in COPR now, so we dropped our third party package. Therefore, you do not need to layer anymore to use virt manager or sunshine and can benefit from bootc. For virt manager, you can use the flatpak instead of the system package. If you’ve layered any of those packages, we made sure you can still update. And you are a sudo rpm-ostree reset away from using bootc as well! rpm-ostree will remain in Bazzite for the foreseeable future.
Last month, we merged progress status reporting in the upstream bootc package. This came along with our new bootc Handheld Daemon updater for gamemode. So now, while Handheld Daemon is running, updates from Steam feature a proper progress bar, and you can use Handheld Daemon to see the current version, update, rebase, and rollback all without heading to desktop.
For rolling back, we also load the previous 7 versions. So you can select and pin with a few taps, before creating a bug report.
Bug reporting tool
Speaking of bug reports, we have a new bug reporting tool! With just one tap, you can now create a bug report and grab a QR code with the logs from your current session and device IDs. Then just post this log in your bug report and we handle the rest.
Currently, the logs are stored in Fedora’s fpaste service and expire after three days automatically. Unless you share the QR code, we do not have access to them. They should not contain any personal information. If you find some, just open an issue and we ill make sure to blank that in a future version.
You can also switch to the Handheld Daemon beta with just a tap, which is perfect for testing new devices and features.
Hibernation Support in Deck images
One of the pet pieves we have had over the last few months are the workarounds manufacturers do to get sleep to be passable in Windows. Ayaneo disables Modern Standby to force WIndows to hibernate, GPD and OneXPlayer make their devices wake-up after 5% battery loss and pretend to overheat, and the Ally becomes really upset when it reaches 1% battery, triggering a protection feature called Prochot that limits TDP to 5W until it powers off.
Therefore, we took the massive undertaking of adding hibernation support to deck images, right below a “Reboot into Windows” button that will transport you right to Windows if you dual boot, and disappear if you do not.
From now on, if you have an Ayaneo device without an updated BIOS that supports sleep (they started rolling them out for some devices), your device will hibernate. If your GPD Win 4, GPD Max 2, OneXPlayer X1 and X1 Mini wake-up and ask to hibernate, they automatically will, and, failing that, they will shutdown, protecting them from overheating in your bag. Finally, all devices will automatically hibernate at 5% battery, saving your game progress and, in the case of the Ally, resetting the protection feature, so once you reach for that charger, you can keep gaming without losing your save progress. If your device is sleeping when it reaches 5%, it will wake up and hibernate automatically.
Edit: Automatic hibernation is only in deck images, so if you use any of the devices that wake up in desktop images they will not hibernate. GPD Win Max 2 needs the kernel that will be in an upcoming stable build, 6.12.8-208 or later.
Getting hibernation to be functional was no small task. It required 5-6 kernel patches, which dealt with fixing the Mediatek bluetooth driver crashing, the AMD driver bailing evacuating memory, and getting the hibernation triggers of devices to show up. That was after finding all of the hibernation triggers themselves which took the better part of a month, and creating reliable checks for them, so that the devices can hibernate reliably. Finally, we also need to dynamically create a swap based on memory consumption, and deal with issues such as deactivating ZRAM and dropping caches prior to beginning hibernation, to maximize the chance it succeeds. Then, we have have to remove said cache and deal with inconsistent state from drivers that just restarted, such as making sure the OneXPlayer turbo button still works and my favorite: the Ally’s battery preservation feature being disabled because the asus-wmi driver resets it (I still need to fix this).
EDIT: if you rebase between deck images to desktop images or to an older deck image without the greenboot style feature, you will notice that the fallback boot is selected after a failed boot. Use sudo grub2-editenv - unset boot_counter to remove the change.
Begone Grub
During booting and after hibernation, we hide grub if the previous boot was successful (either lasted more than 3min or you shutdown cleanly), so you get a really nice splash screen until the device boots/resumes and not that ugly cursor. The timeout is still there, now 3 seconds instead of 5, so you can still use that to boot into something else and with ujust configure-grub you can control whether grub is hidden.
On deck images, Grub also has a cool new feature: if you uncleanly shutdown your device twice (by holding the power button within three minutes of it starting), it will automatically select the previous version. So you no longer need a keyboard to rollback. This feature is inspired by Fedora’s Greenboot IoT project, which does automatic rollbacks and health checks for IoT devices.
EDIT: On desktop images, Grub is not hidden if you dual boot. Use the ujust to configure it.
Modern Standby Support
Our modern standby patchset that fixed Extreme Standby on the Ally also got an upgrade, allowing us to enter the Modern Standby states Windows has before beginning the suspend sequence. This means we can now shutdown the built-in controller and pulse the suspend light of devices (Ally, Legion Go, GPD, and OneXPlayer) before beginning the suspend sequence or hibernation. Then, we upgraded gamescope to be able to turn off the screen on command (DPMS support). An ability it does not have currently funnily. Steam can only set the display to minimum brightness.
What does this mean? Whereas before during suspending/hibernation the GPU driver would show an ugly stale frozen image and the RGB of the device would stay on (in the case of hibernation also turn on and off twice), they now beautifully turn off and stay off while the device is transitioning to hibernation and to/from sleep.
Here is a video showing going in and out of sleep on an Ally, OneXPlayer X1, and then hibernating on a GPD Win 4:
Bazzite’s Future
We also got a mention from Valve’s own Pierre-Loup Griffais and Lawrence Yang, as part of their announcement that SteamOS is right around the corner, coming out with Legion Go S in May. They also promised a beta in late April. This prompted around 30-40 of you to ask us where is Bazzite’s future if “mah SteamOS releases”.
I do understand some of you only value official drip, so we will be sad to see you go
But the short answer is nowhere.
Let’s expand on that a bit.
First, you might have missed this, but Bazzite has a set of desktop images that do not include what you would consider as SteamOS. These images account for around half of our users and Valve is not replacing those.
Second, Bazzite is not SteamOS. Every single package we ship we modify to meet our standards, especially when it comes to hardware enablement. Having started from a solid base in collaboration with ChimeraOS. As time progresses, we diverge even more. The only thing we share with SteamOS is, well, Steam. We have our own custom kernel, custom gamescope with over 10 additional features, and as needed we build custom versions of e.g., Mesa, mutter, or all sorts of Fedora packages if something breaks or there is an important upcoming feature. All packages, other than Steam, have open licenses.
Our focus has always been to give you a secure and stable computing platform you can use in your everyday life.
What that means depends on the person but for us, we want you to be able to browse the web, develop software, watch videos, play games with great performance, and everything you’d like to do with your computer as an average user.
At the same time, without worrying about the cruft that comes with a normal computer: updating drivers, weird adverts, pop-ups for Co-pilot or whatever is in season, selling your data, et al.
To put it simply: open your computer, play a great game, watch some videos, scroll tik tok, and leave choosing stuff like the best driver to us.
Steam will play a center role in that for the foreseeable future as they are the only marketplace that validates and warranties games for Linux. So we are almost obligated to bundle Steam. But that’s about it.
Looking forward into 2025
As for what the future looks like. For me, MSI and Intel announced some pretty cool stuff recently and you know we have to get some support for them going. We have a decent relationship with AMD maintainers, time to start bugging Intel too 
Then I also want to look at eGPU support in linux, since its quite poor currently. I’d like to get us to a place where suspending and hot plugging (when a game is not running) work correctly. Both OneXPlayer and GPD make great eGPUs, and its a shame we don’t have great support for them. We do offer best-in-class support currently, but best-in-class ain’t much.
As for the team in general, we want to start reducing our bloat and cleaning up our build chain to be simpler and more robust.
And now that nvidia-deck is a thing, we can finally gut and rework the gamemode session so you can finally use your handheld for proper desktop work and switch to gaming on the go. We could not do that before, as we had to account for nvidia desktops.
Who knows, if it goes well its very likely the deck and desktop images will merge. So that you can have a proper lockscreen, do your work securely and reliably, then hit a button and boom gamepad ui.
This has been something we have discussed for some time, but prior to Nvidia supporting gamescope it would be very hard to do.
And I think that’s all. But let me give you some links to keep you busy.
Recent news
We recently added TDP support for Strix Point devices, and GPD’s/OneXPlayers new early 2025 devices: GPD Win Max 2 2025, OneXPlayer F1 Pro + variants. For the F1 Pro EVA-1, we did a new exclusive theme, and one of you sent us this picture. I think it looks fire 
Sean from the Verge treated us with this really nice article over the holidays. Half of the issues he mentioned are now fixed, we move fast 
And craft computing made this nice review:
