Despite openSUSE not being one of the distros that was officially tested by the Framework team, it works surprisingly well on the Framework. There were just a couple of things that I needed to do to make openSUSE work as it should.
This is not a full out guide explaining how to set up openSUSE. It is only a mini-guide designed to explain the few things I needed to do to get full functionality on the Framework.
Pastebin containing all the sources I mentioned in my guide:
Enabling the fingerprint sensor:
Out of the box, openSUSE does not include the required packages for fingerprint
functionality, and they need to be installed. You can install them by running:
sudo zypper in libfprint-2-2 fprintd fprintd-lang fprintd-pam
in the terminal.
Then you just need to run this command to complete the setup:
pam-config --add --fprintd
Without even needing to log out or reboot, fingerprint authentication should be available right away within KDE System Settings, within the user section.
(Credit to Framework Community Member “Fabian_Herschel” for providing some initial instructions on how to do this. I just modified their instructions a bit, to make it a bit easier to understand what the exact commands are that you need to run, in order to get fingerprint functionality working.)
Note: If in the future you end up running into issues adding fingerprints, the fingerprints stored on the fingerprint sensor itself have most likely become corrupted is some way. I have noticed that not only does the “fprintd-delete” command not actually delete the fingerprints stored in your fingerprint sensor, but that corrupted fingerprint data persists across reinstalls of openSUSE, or even two different Linux distros too. Fortunately I was able to find a little python script that is designed to actually delete the fingerprints from the sensor itself, and after I ran that, the sensor worked fine again.
Here’s how you run it:
I: First go to the libfprint link in my sources pastebin
II: Then copy the code found in the part of the issue that the link takes you to
III: You then need to open a text editor and paste that code into there, and save it as anything.py
IV: Right click on the program in your file manager, and go to properties
V: check the “allow executing file as program” box
VI: Then right click within any blank space within file manager, making sure you are currently in the same directory as the anything.py file you created, and click the menu item that says something like “open terminal here”
VIII: The program will now go about actually wiping the stored finger prints off of your fingerprint sensor. If all goes well, hopefully the next time you try to enroll your fingers, it will work!
Credit to Framework Community member @Bob_U, for showing this solution in a comment in another post a while back, as well as Benjemin Berg on Gitlab for writing the python script.
Auto brightness functionality:
I am pretty sure auto brightness works out of the box on openSUSE, but
honestly I couldn’t really tell.
Just make sure that the
package is installed.
I recommend just running
sudo zypper in iio-sensor-proxy
just to be safe.
If it does end up being installed already, zypper will say so.
If the package did end up needing to be installed, I would recommend rebooting after the package is done installing.
If it was already installed, or you have rebooted after installing it, then it is time to check if it is working.
This can be done by running:
udevadm info --export-db | grep iio
in the terminal.
If you see an output like this you should be good to go (it might not be exactly like this example, mine wasn’t):
(Credit to Telegram user “Arief” in the KDE telegram group for helping me with
this, as well as Framework Community member “dossman”.)
- Check the “sources” pastebin to see where I was able to confirm that auto brightness was working.
Since writing that first section, I have learned some things. Even if you have iio-proxy is installed, KDE won’t use it, because I don’t think KDE officially supports auto brightness, unlike Gnome which I think does support auto brightness out of the box. Fortunately a Framework Community user made a very nice script that gets auto brightness working quite well in KDE. Thats what I will be going over now.
- (Part 2) Enabling Automatic Brightness Control in KDE:
First go to the GitHub link for the Auto Brightness script found in my “sources” pastebin, and click on the code button, and click download zip.
Then extract the zip, and copy the “AutomaticBrightness.sh” file to a safe location on your computer.
Next you need to open Settings, and go to Startup and Shutdown/Autostart/ and then add a login script. Choose the script you in the previous step.
You then are going to open up the terminal, as there is a package we need to install.
Once the terminal is open run
sudo zypper in brightnessctl
We need brightnessctl because the script relies on it to adjust your screen’s beightness.
After the package is installed, you need to log out and back in. If all goes well, you should have auto brightness functionality within KDE!
Thanks GitHub user “steel99xl” for creating the script that allows for this.
Enabling Brightness Hotkey Functionality:
Note: It is currently not possible to have working auto brightness, and working brightness keys at the same time. From what I understand, Framework would have to release a driver to allow both to work at the same time, which does not currently exist for Linux at the moment unfortunately. The Framework has a compound device that handles auto brightness, and the functionality of the brightness keys. Linux doesn’t know how to handle this type of situation as of yet.
Open a terminal and enter:
sudo nano /etc/modprobe.d/framework-als-blacklist.conf
Then add this line to the file:
Restart your machine. Brightness hotkeys should now work!
(Credit to Framework Community member “dossman” for helping me out with this, and pointing me in the right direction, and thanks to Framework Community Member “Kieran_Levin” for actually providing the information needed to fix the issue with brightness hotkeys.)
Improving sound quality of Framework Laptop:
Out of the box the Framework sounds pretty alright, but it can sound so much better with the help of an audio preset. Of course, the Framework community being as awesome as it is, has made a few that work really well. I will tell you how to set them up.
First you need to install a program called EasyEffects which will allow you to take advantage of these audio presets. It can be found in my “sources” pastebin. The like I provided will take you to the project’s GitHub, just scroll down and click on the flatpak link, and go about installing the flatpak of EasyEffects. Unfortunately, libadwaita is very baked into it, meaning it looks very out of place in KDE, but until I figure out a KDE alternative, it is the best there is.
After EasyEffects is installed, head back to my “sources” pastebin, and click on the link for the Framework audio presets. This will take you to the GitHub of the Framework audio presets project. Once there, you then need to click the green “code” button and choose the “download zip” option.
Once the zip is downloaded, you need to extract it.
Once it is extracted, you need to open the “EasyEffects” program. If it isn’t visible, then you need to either log out and back in, or if that doesn’t make it appear, then you might need to restart. Flatpaks don’t show up without you re-logging in a lot of the time. Alternatively, if you don’t want to log out, you can run this terminal command to launch the program:
flatpak run com.github.wwmm.easyeffects
Once the program opens, you then need to load in the audio preset of your choosing. While I think they all sound better than the stock speaker output, I personally think the two best ones are
philonmetal.json. Out of those two I personally prefer the former. Lappy was designed for when you were using your laptop on your lap (as the name might suggest), but I think it is the best overall.
To load the preset in, you just need to go to the “Presets” drop-down menu within EasyEffects, and choose your preset of choice. Once opened, just press the “load” button within the “Presets” drop-down to start using it.
Next play some audio to test it out! Hopefully it sounds much better to you than the stock sound output did. I know I said what my preferred presets were, but you should honestly test them all out, and see what one(s) suit you best. In my opinion they all sound better than the stock output.
- (Part 2) Keeping the effect running in the background:
Now that the effect is set up, you probably would like to keep it running in the background most likely permanently, so you don’t have to worry about it anymore.
Click on the “3 dot menu” on the right side of the title bar, and click preferences.
First enable “Launch Service at System Startup”, to allow the effect to take place on boot.
Then disable “Shutdown on Window Closing”, so you can keep it running with EasyEffects closed.
Then close preferences, and head over to the “PipeWire” tab.
First thing to do is to disable the option to use the “Default Input”, and to set the built in speakers to to be the device that the program applies the effect to. If you don’t do this, then the effect will be applied to the current audio device in use, and I can imagine that wouldn’t be all too desirable when you are using headphones/earbuds instead.
You should be good to go! I hope you enjoy improved sound quality on your framework! The difference obviously ain’t gonna blow you away, but it is improved quite a bit, I think anyway. Out of the box I thought the Framework sounded alright to smash music out of when working or something, but now it sounds even better and clearer for that use case, which is nice.
(Credit to GitHub user “ceiphr” for creating the presets, and to GitHub user “wwmm” for creating EasyEffects. Lastly, thanks to the Framework community for allowing me to find the information on how to do this. Regrettably I forget which user exactly was the one to talk about these presets, and for that, I’m sorry. If you would like, please tell me if that was you in the comments.)
A couple non-framework specific, quality of life (in my opinion, anyway) improvements to do as well:
I personally recommend that you use Wayland over X11. Wayland may be a bit more buggy than X11 true, but on a laptop like the framework, it’s your best bet.
Not only is Wayland’s fractional scaling better than X11’s, but you get access to native touchpad gestures as well.
As for the scaling of the display, I recommend scaling the Framework’s display to 160%, anything less is just too small in my opinion.
Recommended utility to improve battery management:
OpenSUSE comes with TLP for battery life management by default, which works well and all, but I honestly recommend that you switch it out for auto-cpufreq instead. It does a better job, I think, at least from the times I’ve used it, and you don’t give up turbo boost either. From what I remember, I am pretty sure you lose turbo boost with TLP, but I could be wrong.
Setting up auto-cpufreq:
Note: I know there is a snap package of auto-cpufreq available, but I honestly do not like snaps, so I will not be going over how to install the snap. But if you want to go ahead and install snap support on openSUSE, and then install the auto-cpufreq snap feel free.
You can get auto-cpufreq from from the correct link in my “sources” pastebin.
The latest version available here is quite a bit outdated. Thanks to the help of an openSUSE user in the openSUSE Discord/IRC/Matrix group, I was able to build an up-to-date RPM of the auto-cpufreq package, it can be from the corrent link in my “sources” pastebin.
It needs to be installed via YAST or the terminal, as there are a few minor errors in some of the checking systems in the package, making discover not want to install the package.
I’d recommend installing the package using YAST. In KDE, YAST is not the default option for installing RPMS. To make YAST open an RPM, you need to right click on the RPM, and YAST should be an option under the “Open With” submenu.
YAST will begin to install the RPM, as it is doing so, an error will most likely appear. This error isn’t important and can be ignored. The package will install and function just fine despite the error.
Next open a terminal. The first thing that needs to be done is uninstall TLP so it doesn’t interfere with auto-cpufreq. This can be done with:
sudo zypper rm TLP
Reboot your laptop just to be safe.
Then we can enable auto-cpufreq with:
sudo systemctl enable autocpu-freq && sudo systemctl start autocpufreq
Next check if it is running with:
If you get an output from this it’s working! You can then quit the monitoring process with CTRL+C. Doing this will not stop auto-cpufreq.
You now have a bit of a better battery management service on your Framework than what openSUSE comes with!
I hope that this guide was able to aid you in getting openSUSE up and running on your Framework device. If you have any questions/suggestions feel free to comment them below.