A page dedicated to sensors was added to the System Reports tool.<\/p>\n
This page lists all the sensors detected on the computer and refreshes their value automatically.<\/p>\n
This is typically used to keep an eye on fan speed and temperatures. It can be useful to troubleshoot power modes, battery lifetime, etc.<\/p>\n The list of sensors depends on the manufacturer. Some computers don’t show a lot of information, some do.<\/p>\n Cinnamon Screensaver and Wayland<\/strong><\/p>\n The new Cinnamon screensaver is ready, and there’s a lot of good news coming along with it!<\/p>\n Until now Cinnamon had a dedicated screensaver program called “cinnamon-screensaver”, which ran alongside it as a separate process within the session. This screensaver was written in Python and in C, it used the GTK toolkit, and it was designed for Xorg.<\/p>\n It looked nice and it worked pretty well but it had issues:<\/p>\n The new screensaver isn’t a separate process. It’s Cinnamon itself handling things directly, locking the screen natively with its own toolkit and widgets.<\/p>\n Here’s another screenshot of it, with some of the UI improvements Joseph is working on.<\/p>\n The first thing you’ll notice is the native look and the smooth animation.<\/p>\n The biggest gain of course is the full compatibility with Wayland. Whether or not we want to default to Wayland in the future is a different topic, but we certainly want to have the option on the table. With this new screensaver, the next Cinnamon release will be Wayland compatible.<\/p>\n Screensavers are very important. They need to look good, they need to work well, and they cannot under any circumstance fail to protect the user’s privacy. If the screensaver was to crash, the session still needs to be locked. There’s an extra process dedicated to hiding the screen when that happens. It worked well with cinnamon-screensaver but it took a lot of testing to make sure it did. It works well with the new screensaver also, but it will take time to make sure it’s tested properly both in Xorg and in Wayland.\u00a0For that reason, even though cinnamon-screensaver will eventually be discontinued, the next Cinnamon will be able to work with either the new or the old screensaver.<\/p>\n Now here’s a little anecdote from our development team. Although the native screensaver has a much smoother transition than the old one, we encountered the very same papercut bug we’ve had for decades on the old screensaver: What looked like a random race condition, which results in the session being briefly visible before the screensaver appears on resume or lid-open. We tried and failed to fix this issue for years, and as we worked on the new screensaver we just realized what was causing it. It’s fixed now, not only for the new screensaver, but after extensive testing also as an update to the old one….<\/p>\n .. so what changed? Why couldn’t we fix this before? The answer is complexity. When we’re dealing with something that happens all the time, even when we don’t understand why it happens, we can change things and see if it continues to happen. This makes it easy to find the cause, and once we’ve a solution, to make sure the solution works. When the bug is random and only happens “sometimes” we’ve no reliable way or finding the cause or testing the solution. This was a random bug in a scenario which involved:<\/p>\n It could happen on suspend or hibernation. It could also happen as the result of a timeout, which could lock the screen, or not, or a lid-close event. We handle about 6 different overlapping timers for maybe 4 different ways of turning off the screen, starting the screensaver, locking it, suspending… it’s a huge mess. I didn’t try to calculate how many different scenarios are at play here, but there are way more than just “dozens” \ud83d\ude42<\/p>\n While I was testing the new screensaver I came across the issue again. This time the window-manager and the screensaver were one and the same, so 3 components instead of 4. We weren’t asking Xorg to stack a new window also… and we managed to reproduce the issue with just locking the screen (i.e. with no logind intervention). This really helped pin-point the issue. In the end it had to do with power-saving and asking Xorg to turn off the screen. For some reason this makes Xorg fail to render events, so even though the screen is indeed locked, the frames don’t update on the screen just before it goes off, and it all happens later after the screen turns on again. It’s a rendering bug.<\/p>\n This is a good lesson for us because it shows us how supporting too many niche features and too many use cases can lead to critical bugs which affect everyone for a decade. I couldn’t explain in layman terms what each of the timers do in the Cinnamon screensaver and power preferences, and that’s a problem. We inherited these configuration options from a time when people had no laptops and their desktop monitors were subject to screen burn. Fast forward 10-15 years and we’re dealing with laptops used outside of homes, where “saving” the screen is irrelevant but “locking” it became paramount.<\/p>\n Back in the days, the main features were to animate the screen to prevent screen burn and allow that to happen before turning off the screen because that took time to wake up. Nowadays we’re in a completely different situation, it’s all about locking it and once it’s locked we want to see our battery level, our multimedia controls, we want to be able to access the on-screen keyboard, switch layout, use the fingerprint reader etc..\u00a0<\/p>\n We’ll go one step at a time here. The next Cinnamon release will keep the exact same configuration options, introduce the new screensaver and keep compatibility as a fallback with the older one. The release after that will abandon the old screensaver, review all use cases and simplify how and when the screen gets locked.<\/p>\n Sponsorships:<\/strong><\/p>\n Linux Mint is proudly sponsored by:<\/p>\n![\"\"](\"https:\/\/blog.linuxmint.com\/upload\/2026\/03\/shadow_sensors.png\")
<\/a><\/p>\n<\/a><\/p>\n\n
<\/a><\/p>\n\n