Add prebuilt packages for ArchLinux

[StefanescuCristian]

Hello,

In ArchLinux AUR, there is a package you can build the kernel from your kernel source. The time compiling this on our laptop is huge on today's standards, so I have built them on another machine and installed on our little laptop.

I have made this packages public and I'll try to maintain them as much as I can and the time permits, but since there are two big distro users who are building from your sources (Debian and Arch) and you already release binaries for one of them (Debian) are you interested in adding the binaries I compiled to your releases page?

I think adding the Arch kernels here will be easier for users to find them.

If you are interested, you can find the files here.

[heikomat]

I'm definitely interested in supporting arch linux the same way debian is supported (in the best case scenario even through the same install-script)

I currently build the debian kernel packages in a docker container (see here). I haven't yet had the time to create a similar (working) docker container for arch, but having the config files necessary to build the kernel packages will definitely help me, as i haven't actually used arch yet.

I'm currently busy studying for exams, but will come back to this issue when i have the time and patience to do so.

If you happen to know your way around docker, and have the time to do so, you could help me with this, if you want to

[StefanescuCristian]

Cool,

I'll try to write a Dockerfile for Arch and make a PR.

[heikomat]

cool, thanks :D
For debian, there are two files on the docker_builds-branch: Dockerfile_debian and build_debian.sh.

When executing ./build_debian.sh, it creates the container according to the Dockerfile_debian, which builds the kernel packages, then copies the resulting packages to the host system and deletes the container. I then upload these packages to a new github-release and adjust the version-number in the installer script

The analogous files for arch (Dockerfile_arch and build_arch.sh) already exist on that branch, but are as of now just copies of the debian-files and don't work.

If you could edit these files in a way that would make them build the working arch-packages and put them on the host machine (just like the debian version), that would be really epic :D

[StefanescuCristian]

I've made PR #9

It worked for me, but you should give it a try to see if you manage to get the linux*.xz files.
It was fun to play around with docker. I still don't like it, but was a nice weekend project 😆

[heikomat]

Well, docker allows me to build the kernel on my macbook without dualbooting and guarantees that the kernel-build-environment is independent of the host machine, so that it works the same everywhere.

I'm glad it was a nice project for you :)

[7twin]

@heikomat I have actually polished my docker knowledge through multiple projects since we last had this topic and came up with my own Dockerfile/Compose now, it built the 5.0 branch just fine too.

I'll make it into an interactive script, then link it here, the only difference is that I build based on the same instructions posted here: https://github.com/7twin/arch_sound_e200ha so after it has done building, you transfer the zip that got volume mounted onto the e200ha, unzip and install it. (could have a script for that too, I'll see how fancy it'll end up being)

Just need some more available time on my hands to compile it all together and test if the build that went through fine, is also actually bootable. (saw you guys had some issues in the previous docker PR)

[StefanescuCristian]

Hello,

I've forgot about this, sorry. I never got to update the PR, because life happens sometimes.

@7twin You can use my dockerfile as a template/example and modify it you think it helps. I've commented almost every command and I think it's easy enough to understand it.

[7twin]

@StefanescuCristian Don't worry, we all have our fair share of life, so things do move slow sometimes. As mentioned once I have some more time on my hands I'll test if the build is bootable and create also interactive scripts for it. ☺️

[heikomat]

Nice to hear that you guys are still on it :)
@7twin the 5.0-branch is not merged yet, because when i docker-buillt it for debian/ubuntu the same way i built 4.20, the laptop wasn't booting anymore. I need a free evening to debug this and see why this happens.
Have no plans for the weekend yet. If it stays that way, i'll try to fix the 5.0-branch

[7twin]

@heikomat I should also have some time available soon'ish. I have already generated 3 zip files, each in different size depending on how many cores I built it (not sure why, e.g. on 32 cores it built to a zipped 450MB where as on 16 it built to 746~MB). I will try if any of those work to boot from and report back, though if you building as "usual" made it not boot, then something more major might be wrong.

[7twin]

@heikomat had finally time to test it, doesn't seem to boot for me either, even though the docker build itself worked.

[heikomat]

@7twin as you know, when i tried building 5.0, i was able to build the packages, but the system wouldn't boot.
i just merged 5.1, and wasn't even able to build the packages (i got build errors). After adjusting a few lines (see here), i was not only able to build the packages, but compared to 5.0 the system boots and works as intended (or at least as good as it did with 4.20).

So i made a 5.1-cx2072x release. Could you please test your docker-arch-build with 5.1 (current master)?

[7twin]

@heikomat sounds fantastic, well done!

Will try to test it out asap and tag you here once I do!

[roethigj]

@heikomat thanks for the kernel and script!

what is the (technical) difference to Takashi Iwai's work: (kernel/git/tiwai/sound.git)? Looks like they're working on codec and driver for current kernels. your module is cht_cx2072x, their's is byt_cht_cx2072x.

I patched a manjaro kernel some days ago using their commits and it works (https://github.com/roethigj/Linux51-manjaro-cx2072x). Just needed to adjust the UCM files.

[heikomat]

@roethigj as i describe here my variant of the kernel is based upon multiple patches that Takashi created for the 4.13 kernel.
Takashi didn't (to my knowledge at least) adapt the patches to work with newer kernels (up until recently, as it seems).

I'm by all means not familiar with the kernel, but i'm capable of reading build errors and find my way around source code, so with two nights of work i was able to merge and adapt his patches into the 4.16 kernel. Keeping them updated from that point on wasn't that hard.

I was not aware, that Takashi has updated his cx2072x patches for newer kernels. As you can see, his commits are only a couple of weeks old, and there are no branches for kernel versions 4.14 through 5.0:

So... If these patches are legit (and by you're success in using them, they seem to be), then they're most likely of higher quality than my "i somehow made it work without completely breaking it"-approach. In this case, i'll probably stop using my own "based on Takeshis patches"-version, and move on to just straight up pre-building and using his patches (as the one-command-installer in this repo seems to be quite popular, especially with the linux mint folks)

[7twin]

@heikomat just to clarify: this repo will still be updated? just not with own tinkering but merging Takashi's patches instead? (assuming these actually keep coming now, because we had nothing since 4.14 up until 5.0)

I haven't yet checked enough on what @roethigj meant with "UCM files", but possibly the docker image could do it all for us; pull latest stable kernel, check for takashi patch, apply it, fix "UCM files", then compile and output (possibly even via pipeline to auto publish it to github/gitlab releases) - though as mentioned before my approach is more in line with how the arch wiki describes compiling a kernel, rather than packaging it up as some others did (still no proper grasp on how that would work to install either, just as a regular package and then it somehow creates the necessary grub entries and all that goes with it?..), so that might need adjustments too.

[7twin]

Also worth asking, should I hold off testing the current 5.1 or will we still keep it until #10 is ready?

[heikomat]

@7twin i just opened another issue to track the "Takashi has updated patches"-topic, see #10

This repository will definitely continue to exist, but if Takashis fixes work as intendet, i'll replace the current master-branch with Takashis cx2072x-5.1 branch (aka i'll replace my updated patches with his updated patches).

these files are meant when talking about the ucm files. They have to just exists for alsa to know what codec and driver to use and how to use them. As you can see here, my cx2072x-installer script just downloads them to the correct location.

I'd like to have the docker-builds still use this repositories master branch to build the kernel-packages, but in an ideal scenario, this repositories master branch is (nearly) identical to Takashis cx2072x branch.

This allows us to keep the ucm files and manuals with the install-command in this repo, while simultaneously making us independend, in case Takashi stops updating his patches.

[7twin]

@heikomat

I'd like to have the docker-builds still use this repositories master branch to build the kernel-packages

This allows us to keep the ucm files and manuals with the install-command in this repo, while simultaneously making us independend, in case Takashi stops updating his patches.

Makes sense, then we'll just keep it manual and have the docker builds just continue to pull from this repo and publish pre-built packages as releases. Indeed it's a better idea to not rely on external patches exclusively.

[7twin]

@heikomat it worked! I couldn't find any issues with it whatsoever and didn't even have to apply any renames this time 🎉 I'll need to update the instructions from 4.20 and then commit the first version of the docker setup, though I will make it into a more guided script once I have more time.

[heikomat]

Nice!

[7twin]

Updated the instructions for now (most was still the same, just some minor changes), will then in near future make the docker setup available too: https://github.com/7twin/arch_sound_e200ha

[7twin]

@heikomat v5.1 sound does not seem to work, did you try it out and it worked for you? I did make sure to change all occurences and add the new config lines, also downloaded the new ucm files.

[frantisheq]

#11 (comment)

[heikomat]

Sound works für me on linux mint with 5.1

[7twin]

@frantisheq even after that and a reboot, still only a dummy output device, sadly
@heikomat guess I'll try to build again and check to make sure the options are there, if that fails, I'll try to build with the config you have in the repo.

[7twin]

@heikomat tried to build with your config too and copied over exactly the same parameters, still no luck, in pavucontrol I can see a profile for "Atom/Celeron/.." that contains a multitude of hdmi profiles which all are marked as "(unplugged) (unavailable)" but output devices only contains the dummy.

My config is now: https://github.com/heikomat/linux_cx2072x_build/blob/master/arch_package_config/config

with that at the end:

CONFIG_SND_SOC_INTEL_BYT_CHT_CX2072X_MACH=m
CONFIG_SND_SOC_CX2072X=m
CONFIG_ACPI_ASUS=m
CONFIG_HID_ELAN=m
CONFIG_DEBUG_INFO=n

[7twin]

I think I know my mistake, my script is pulling tag v5.1 instead of the cx2072x branch, could that be it?

[heikomat]

Yes, you definitely need to build from the cx2072x branch

[7twin]

@heikomat pulling the "right" branch and rebuilding at first did nothing, but then creating a fresh .config without modifying it (it had all the options already seemingly, possibly because I was booted into a previous attempt kernel) and it worked! 🎉

Will try to do a full fresh install of arch and apply this kernel, just to make sure it wasn't some coincidence.

[7twin]

@heikomat worked absolutely flawless, I updated my repo now too, to reflect the new changes as I myself forgot while testing again to switch to the new naming of ucm files and folder.

[heikomat]

@7twin good news! Starting with 5.3, the patches for the cx2072x will be in the default linux kernel! (see this commit).

We'll probably still need the alsa-ucm files, but this means that starting from 5.3, no more custom-kernels and kernel patches will be required!

[frantisheq]

nice. if someone gets camera to work on hp x2 210 finally everything will work

[7twin]

@heikomat That's amazing news! wonder when 5.3 will be out for release.

[heikomat]

@7twin probably in about 5 to 7 weeks. But it will most likely take a couple more weeks or month before the different distros actually use the updated kernel

[frantisheq]

looks like ucm files are already there alsa-project/alsa-lib@108a2f4

[heikomat]

@frantisheq thanks for the link, i've been looking for this :D
This seems to not be releases though (can't see it in alsa-lib 1.1.9), so this will presumably be in alsa-lib 1.1.10 oder 1.2.0.

In that case, i'll need to do the following checks:

• Check if lib/firmware/intel/fw_sst_22a8.bin exists, if not install firmware-intel-sound (this is already in the script, and almost all distros already have this preinstalled)
• Check if the Kernel is at least version 5.3, if not install the latest cx2072x-custom-kernel
• Check if alsa-lib is at least version 1.1.10, if not install the ucm-files
• Disable realtime-scheduling in pulseaudio (would need to test is this is really still necessary)

This means i'll keep the installer script up to date up to the mentioned kernel and alsa versions, because everything newer should just work out of the box, and everything older can use the script :)

[marcin19883]

Im use Arch and kernel 5.3 RC1. The module cx2072x is not loaded:( but it works in ubuntu kernel mainline. Could anyone compile a kernel with the module on Arch? I do not know it, that's why I am asking you