09:47 <ncopa> has the asahi kernel a usable defconfig?

09:47 <j`ey> https://github.com/AsahiLinux/PKGBUILDs/blob/main/linux-asahi/config

09:48 <j`ey> there's some stuff which is 'default ARCH_APPLE' which helps

09:51 <ncopa> so it is not added as a defconfig to asahi branch

09:51 <j`ey> ah, right, no

09:53 <mps> ncopa: could you tell list of dir vendorfw on ESP you created with installer

09:54 <mps> is there cpio file or tar?

09:54 <ncopa> dont know yet, i have only installed uefi on it so far

09:54 <mps> I cannot try to reinstall these days to check myself

09:54 <ncopa> i'd like to build my own alpine boot image

09:55 <mps> ncopa: when you installed in uefi mode it creates some dirs on ESP, one is extracted firmware

09:55 <j`ey> I just untar'd the minimal alpine (VM?) image :D

09:56 <ncopa> the alpine-virt iso image?

09:56 <j`ey> yeah I guess it was that

09:56 <j`ey> alpine-minirootfs-3.15.0-aarch64.tar.gz

09:57 <mps> ncopa: you could try to flash this https://dev.alpinelinux.org/%7Emps/m1/m1-usb-alpine-install.img.xz on usb stick and boot it from usb

09:57 <ncopa> thats the tarball for docker image. it does not even have any kernel

09:57 <ncopa> mps, i know, i'd just like to build my own image, that let me run alpine from tmpfs

09:58 <mps> yes, that is what I think should be final image for install alpine

09:59 <ncopa> so, i guess what i really should do is to have 2 alpine installs

09:59 <ncopa> one for my actual work

09:59 <ncopa> and one for testing the alpine installer

10:01 <mps> this will be possible when m1n1+u-boot is ready for loading from different ESPs

10:01 <mps> not sure if anyone tested this, yet

10:02 <mps> maybe it is tested with openBSD

15:12 <Glanzmann> j`ey: Any idea what I can make to fix that? https://pbot.rmdir.de/mXV-xtxapqHATYFGXFHiTQ

15:12 <Glanzmann> I try to adapt the standard debian kernel config with the asahi options.

15:12 <Glanzmann> Debian users writing me emails about missing config options that they need every other hour ...

15:12 <j`ey> CONFIG_OF_DYNAMIC=y

15:16 <Glanzmann> j`ey: Thanks. That seems to be rabbit hole: https://tg.st/u/screenshot-mini-2022-12-13-16_16_24.png

15:17 <Glanzmann> So I need CONFIG_OF_UNITTESTS=y

15:17 <Glanzmann> And what does that select by [n] mean? Does it mean if any of the conditions are true it is set to 'n'?

15:18 <j`ey> try enabling CONFIG_OF_OVERLAY

15:20 <Glanzmann> j`ey: Yeah, that did the trick. Thank you.

15:20 <Glanzmann> Now lets see if it compiles. And if it compiles, if it boots. And if it boots if usb is working. :-)

15:21 <j`ey> and if usb is working is it usb3 etc

15:22 <Glanzmann> yep.

15:27 <Glanzmann> Btw. I have a nice new usb bug, but sven probably don't want to hear about it or knows it anyway. Here it goes: U-boot is slow on the mini to boot if there is a usb-c device connected. So I press a lot of buttons to speed up loading of u-boot, grub and kernel/initrd loading. In the old days I pressed 'shift' but now during kernel I just type random crap on the keyboard. If I do so than Linux appears

15:27 <Glanzmann> to loose keystrokes if I type fast. If I use left and right shift to speed up the kernel loading, I don't have this issue.

15:27 <Glanzmann> Now I know why maz is running legacy u-boot.

15:35 <Glanzmann> 2023 is year of the Asahi Developers running their own code on the desktop. Than they'll care.

15:36 <Glanzmann> sven: But what is strange is that when I press random keys on the keyboard while the kernel is loading. The kernel appears to loose characters from my usb keyboard when I type to fast. When I press shift to speedup kernel/initrd, it does not. But maybe it is just my immagination but I think I can reproduce it.

15:37 <sven> I don't care about u-boot because other people do

15:37 <Glanzmann> Good thing than that we have kettenis otherwise we would all run with a raspberry pie around.

15:39 <Glanzmann> sven: But my hypothesis is, that if I press random characters during kernel/initrd loading this somehow gets the hardware or linux driver in a state that it looses keystrokes. But maybe I'm only imagining things.

15:39 <Glanzmann> Oh and of course Linus Torvalds which just bought an m2 air so Hector wrote a keyboard driver for the m2/u-boot.

15:40 <sven> 🤨

15:46 <Glanzmann> Does someone have a font for alacritty that he can recommend that has svens smileys in?

15:50 <Ry_Darcy> @Glanzmann running 6.1.0-rc8-asahi #51 at the moment. Are there known wireless activation issues?

15:51 <Glanzmann> j`ey: The kernel boots, has no oops, no deferred probing, dcp, gpu, usb-a and usb-c and boots on the mini and the air. So lets ship it.

15:52 <Glanzmann> Ry_Darcy: Wifi does not work with wpa3, I think. Why? what problem do you have?

15:54 <Ry_Darcy> Cannot get wlan0 to activate. See https://paste.debian.net/1263941/

15:54 <Glanzmann> Debian folks: We have a working kernel with the distro options taken from config-6.0.0-5-arm64

15:54 <Glanzmann> Ry_Darcy: can you paste the output of 'ip a s' and 'dmesg'?

15:54 <mps> Glanzmann: you ship gpu to end users?

15:55 <_jannau_> isn't wpa3 working for months, some wpa-enterprise configs missed a crypto option in asahi

15:55 <Glanzmann> mps: Yes.

15:56 <Glanzmann> jannau: Yes, I saw that. Probably the debian kernel had that so it was working most of the time for me. And I wondered why the others complained. Anyway I still have access points that asahi will not associate with just with psk. With macos it works ...

15:56 <mps> Glanzmann: and you ship unstable mesa?

15:57 <mps> _jannau_: yes, kernel option was missing, forgot which one because I enabled this from the start on alpine kernel

15:57 <Glanzmann> mps: Yes. Debian soon freezes. So even if mesa would release it would take another 3-4 years to get into Debian.

15:57 <Ry_Darcy> Voilà - https://paste.debian.net/1263942/

15:57 <mps> Glanzmann: heh, for debian this makes sense :-)

15:58 <Glanzmann> Ry_Darcy: Looks good. Have you tried to do a ifup 'wlan0' after editing /etc/wpa/wpa_supplicant.conf ?

15:59 <_jannau_> wasn't wpa3 broken with wpa_supplicant?

15:59 <mps> hmm, so I have to think about enabling gpu by default for alpine (and push mesa-asahi pkg)

16:00 <_jannau_> please don't

16:00 <mps> _jannau_: iirc it was broken earlier but about 2-3 months ago it is fixed

16:01 <mps> _jannau_: ok, will follow your advice

16:04 <_jannau_> providing an option to get testing packages for mesa and kernel with gpu driver enabled is probably fine there is no expection of support unless reproduced with asahi

16:04 <Ry_Darcy> @Glanzmann had an old wpa config file that works. Copied same into the right place and ca marche. Thanks.

16:05 <Glanzmann> Debian folks: patch_kernel_config.pl can now take a Debian upstream config and turn it into an asahi config.

16:05 <Glanzmann> Ry_Darcy: Perfect.

16:05 <Ry_Darcy> Thanks.

16:05 <_jannau_> but it should not be the default which requires dcp+gpu to disabled explicitly in the case of problems

20:25 <Glanzmann> mps: I'm currently on a phone with a friend and he pointed me to 'compton' which is a compositor for x11. And guess what the tearing is gone for me when I play videos. Konfig: https://tg.st/u/.compton.conf

20:25 <Glanzmann> The config has shadows, not that I see them when running my windows in fullscreen.

20:32 <mps> Glanzmann: I don't see any tearing when playing your video with mpv on m1pro

20:35 <mps> yes, I know for comptom but never tried it

20:35 <mps> comton*

20:35 <mps> compton*

20:36 <Glanzmann> I see.

20:36 <Glanzmann> mps: I can see it on my mini clearly.

20:37 <Glanzmann> But only when I play the high resolution videos. But with compton it is gone.

20:38 <mps> hm, could be because I use clients (apps) in awesome without any decors, just plain on screen

20:39 <mps> even without window handles

20:39 <Glanzmann> mps: Same for me. I have 1 pixel border that's it.

20:40 <mps> uhm, I removed xfce else I could try with it

20:42 <mps> Glanzmann: did I told that I don't use '--vo=gpu' with mpv, only xv or x11

20:43 <mps> with --vo=gl or --vo=gpu tearing is there ofc

20:45 <mps> and I still didn't upgraded gallium driver to latest commit

20:47 <mps> oh, and I think playing long videos with 'mpv --vo=xv $filename' could crash X servers, but didn't yet confirmed

21:05 <Glanzmann> mps: I do the same gpu is to slow at least for the high resolution/high fps video.

21:06 <Glanzmann> mps: FOr me x never crashed. Okay once it froze when I tried the tear free patch.

21:16 <mps> I just upgraded gallium/mesa to latest commit, lets see will it be more stable

21:17 <Glanzmann> mps: I already have it while at the latest commit.

21:18 <mps> I don't see any difference in speed, just hope mpv will be stable with --vo=xv

21:19 <mps> but overall it is quite fine

21:20 <mps> (now I can search for riscv notebook and forget apple :) )

21:23 <Glanzmann> mps: Yes, for me it is also stable. Only thing that is not working for me is xfreerdp. Sometimes I need it, but than I switch to the nuc on my table.

21:25 <mps> last thing that is missing is color temperature, and I will add another machine on my pile of arm notebooks. "meine liebe mit apple ist ende" :)

21:26 <Glanzmann> :-)

21:29 <mps> seriously now when ncopa stepped to make alpine better on apple m1 (and I'm sure he will do a lot better than I did) I will step back and move to riscv development

21:32 <Glanzmann> I see. I look forward until everything is upstream but that will take quiet a while.

21:32 <Glanzmann> mps: Which riscv system you will work with?

21:33 <mps> Glanzmann: for now I have starfive visionfivev1 SBC

21:34 <mps> it is not 'first class' SBC but good enough for experimenting

21:35 <Glanzmann> I see. I didn't know it before you posted it but found it on ali express.

21:35 <mps> I maintain opensbi, u-boot and kernel for riscv64 on alpine

21:36 <mps> actually riscv foundation sent 4 boards to some alpine devs, one of them I'm

21:38 <Glanzmann> I see. Cool.