Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for immutable versions of Fedora #192

Open
PVermeer opened this issue Dec 2, 2024 · 2 comments
Open

Support for immutable versions of Fedora #192

PVermeer opened this issue Dec 2, 2024 · 2 comments

Comments

@PVermeer
Copy link

PVermeer commented Dec 2, 2024

Hey @WeirdTreeThing!

I've created a copr repo to support immutable fedora distro's!

https://copr.fedorainfracloud.org/coprs/pvermeer/chromebook-linux-audio
https://github.com/PVermeer/chromebook-linux-audio

It works by packaging this repo and the alsa-ucm-conf-cros repo while disabling the git clone in your script. The alsa-ucm-conf-cros repo is then copied to /tmp so the script can use it.

The script run in the %post step so it has write access to the system and can make the necessary adjustments.

Let me know what you think!

@WeirdTreeThing
Copy link
Owner

Hi, thanks for showing interest in this. While I would like support for immutable distros using ostree, I don't feel like running the script and allowing it to modify system files is the correct approach.

If we take a look at the script, it does the following:

  • Run platform-specific configuration
  • Installs UCM
  • Installs wireplumber configuration

The last two are easy enough to just package. As part of a collaboration between Fyra Labs and chrultrabook, chromebook ucm is packaged in Fyra's terra repo, with automatic updates. Various other packages for chromebooks are also packaged in that repo.

If we take a look at platform-specific config cases:

  • hifi2_audio: Installs a modprobe config to use the sof driver and enable sof debug mode to fix a driver bug. The default driver to use is just a kernel config and I have a kernel patch to enable debug mode by default.
  • avs_audio: Prints a warning about max98357a and gives users the option to enable support or not. To be safe this could always be off (maybe a separate package could be installed to enable it?). Copies topology from the repo, I believe prebuilts from intel have been upstreamed. If not, once again can be packaged. Installs a modprobe config to use the avs driver instead of the skl driver. I have a kernel patch to do this automatically. Installs a wireplumber config, can be packaged. Installs updated DSP firmware, this is mostly a backport that probably isnt needed and is already in fedora.
  • apl_audio: Simply gives the option to choose between sof and avs. Since driver selection should really be in the kernel, this may have to be hardcoded. A separate package with a modprobe config could be used to override if desired.
  • sof_audio: Installs firmware. Symlinks certain topology files, which can be packaged. Installs backported topology for JSL, probably not needed anymore.
  • amd_audio: Only does something on mendocino (ryzen 7000) and just installs firmware which can be packaged. This may even be in upstream now, I haven't checked in a while.

As kernel patches are needed for a few, a chromebook kernel could be used instead of a script. See this for more details on the patches.
And all of them install any needed firmware, which can also be dependencies of a "chromebook-audio" package.

All of the logic in this script can be kernel patches or packages, which I believe is the best way to support immutable distros.

@PVermeer
Copy link
Author

Hi, thanks for replying to this.

First of, I cannot test it very well so I'm depending on users to report bugs. I only have one chromebook that needs this script (pujjo, adl) and it works well on this device with Bazzite (I also do some retro gaming on the go with this device :) ).

While I would like support for immutable distros using ostree, I don't feel like running the script and allowing it to modify system files is the correct approach.

I agree, but that would mean a lot of work and this statement also applies to this script setup in the first place. On image based system, it would even be better since every update starts with a clean image and everything should be removed on removal of the rpm package. My goal is an auto-updating rpm where, with minimal changes/work, immutable enjoyers can use this script.

With your notes and the script I've made the following changes:

As part of a collaboration between Fyra Labs and chrultrabook, chromebook ucm is packaged in Fyra's terra repo

This is great! However I'm using the syntax-7 branch atm because the main branch doesn't work for me. This seems to be the case for a lot of users so I'm using this for now. See update-rpm.sh and disable_git_clone.patch

  • hifi2_audio: Installs a modprobe config to use the sof driver and enable sof debug mode to fix a driver bug. The default driver to use is just a kernel config and I have a kernel patch to enable debug mode by default.

This should work out of the box

  • avs_audio: Prints a warning about max98357a and gives users the option to enable support or not. To be safe this could always be off (maybe a separate package could be installed to enable it?). Copies topology from the repo, I believe prebuilts from intel have been upstreamed. If not, once again can be packaged. Installs a modprobe config to use the avs driver instead of the skl driver. I have a kernel patch to do this automatically. Installs a wireplumber config, can be packaged. Installs updated DSP firmware, this is mostly a backport that probably isnt needed and is already in fedora.

For now I've disabled support for max98357a in disable_max98357a.patch. I could add a sub package to allow it but tbh I'm not really comfortable with providing a package that could break hardware. I rather wait for a fix.

I did disable the update DSP firmware download since it's already in Fedora (I checked). disable_avs_dsp_firmware.patch

  • apl_audio: Simply gives the option to choose between sof and avs. Since driver selection should really be in the kernel, this may have to be hardcoded. A separate package with a modprobe config could be used to override if desired.

I've defaulted to sof in use_sof_for_apl.patch since avs can, once again, damage hardware.

  • sof_audio: Installs firmware. Symlinks certain topology files, which can be packaged. Installs backported topology for JSL, probably not needed anymore.

Nothing special about this. I did disable install_package() in disable_install_package.patch since all packages are provided as requirements.

  • amd_audio: Only does something on mendocino (ryzen 7000) and just installs firmware which can be packaged. This may even be in upstream now, I haven't checked in a while.

For this I just added an exit(1) for stoney. If this needs a custom kernel I can't do anything about it and the package install should fail. fail_platform_stoney.patch

As kernel patches are needed for a few, a chromebook kernel could be used instead of a script. See this for more details on the patches. And all of them install any needed firmware, which can also be dependencies of a "chromebook-audio" package.

All of the logic in this script can be kernel patches or packages, which I believe is the best way to support immutable distros.

I agree. I don't know much about kernel patching though. For now I think this works well for most of the Fedora immutable enjoyers.

There are a lot of patches now and I think it would be better to add a --rpm-build (or anything) argument to script to make the adjustments. I could make a PR for that if you like.

Also a did make a sub package chromebook-linux-audio-debug that runs the script with --enable-debug flag for debug purposes.

If at any point you want to take over or want to build your own packages, let me know.

Project:
https://copr.fedorainfracloud.org/coprs/pvermeer/chromebook-linux-audio
https://github.com/PVermeer/chromebook-linux-audio

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants