ChanServ changed the topic of #asahi-alt to: Asahi Linux: porting Linux to Apple Silicon macs | User-contributed/unofficial distribution ports | Logs: https://alx.sh/l/asahi-alt
Etrien___ has quit [Ping timeout: 480 seconds]
Etrien has quit [Read error: Connection reset by peer]
<caden>
Hello. I am looking for assistance in the "Fedora Desktop" alt release
caden has quit [Quit: caden]
caden has joined #asahi-alt
caden has quit [Remote host closed the connection]
Glanzmann has joined #asahi-alt
<Glanzmann>
caden: I will upgrade the Fedora as soon as it is released. I'll also update the kernel with the new features as soon as marcan has updated alarm with it.
Etrien has quit [Read error: Connection reset by peer]
Etrien has joined #asahi-alt
chadmed has joined #asahi-alt
<chadmed>
sam_: has there been any discussion upstream regarding rust BDEPENDs for kernel builds? since i suspect we're going to need that sooner than most i'd like your thoughts on how we should approach that
<chadmed>
actually i guess its an RDEPEND since building the kernel happens at runtime from portage's point of view
Etrien has quit [Read error: Connection reset by peer]
Etrien has joined #asahi-alt
<Glanzmann>
chadmed: I see. Lets fix that.
Etrien__ has joined #asahi-alt
Etrien has quit [Ping timeout: 480 seconds]
<Glanzmann>
chadmed: I enabled DRM_APPLE the kernel boots, x starts but I don't have mouse, keyboard (via usb-c or usb-a) or network. Either it crashed or all the devices no longer work (they worked before, but reboot did not work). Maybe someone else has an idea, otherwise I'll wait a little bit longer till things are ready for enduser consumption.
<Glanzmann>
Interesting. So the power button worked. So all usb-a/usb-c and network seems to be the issue. Now it ahngs on shutdown.
<chadmed>
try doing a cold boot. theres an issue with DARTs locking on soft reboots which need a full poweroff to fix (at least for t600x, no clue on t8103)
<Glanzmann>
Tried that. After the reboot I still don't have a single I/O device (usb-a, usb-c, network).
<Glanzmann>
So I just revert back to the old kernel and wait a little bit longer.
Etrien__ has quit [Read error: Connection reset by peer]
<jannau>
note that internal displays come back with minimal brightness from DPMS on M1 devices but not M1 Max (and I assume Pro)
<Glanzmann>
Yes, I read that. I just tried on the mini for now. Not planing on the notebooks at the moment.
<Glanzmann>
I still read all the backlog of IRC every day. :-)
<cy8aer>
Glanzmann: just a question from an unitiated: For the core dcp/gpu no mesa is needed? And if it is needed: is there a special version to be compiled with Debian?
<cy8aer>
(just a question what must be prepared if it is on the official kernel)
<chadmed>
mesa is required for the gpu since it contains the userspace portion of the driver (GLES implementation etc). DCP doesnt do rendering and so doesnt "require" mesa to operate, but mesa provides llvmpipe which software renders your desktop
<chadmed>
someone will need to provide a mesa debian package with the asahi driver compiled. they might just already build all possible drivers for a platform upstream so best to check there
<mps>
did anyone tested 4K page size with current asahi-wip branch
<cy8aer>
chadmed: Ok, then it would be some libdrm-apple I guess. How deep is it in the upstream codebase are the patches still beside the upstream?
<chadmed>
upstream master branch tracks pretty closely since alyssa submits stuff to the CI bot and it gets merged, not sure what the go is with dot number releases though
<cy8aer>
Then I will look at the packaging stuff of the other mesa modules how it is done. If it is simple to build I try it, otherwise I will report a wishlist bug.
<cy8aer>
(it must be build officially anyways)
<_jannau_>
changes to work with the linux kernel driver are not upstream though
<cy8aer>
_jannau_: yes just pre preparation and having an overview.
<cy8aer>
... how the packaging works for mesa.
psydroid[m] has quit []
Dcow has joined #asahi-alt
ashi has joined #asahi-alt
<ashi>
Glanzmann: wouldn't it make sense to strip all the other arm platforms (amlogic, imx etc) from the kernel config. Also amdgpu noveau and other drm drivers can be removed I think. Helps compilation time a lot. :)
<Glanzmann>
ashi: I aggree. But I tried to stay as close to the debian config as I could. THat is the reason why the Debian config is so bloated.
<Glanzmann>
cy8aer: I had the same question, that you asked, and now it is a little bit clearer.
<Glanzmann>
mps: I did not try 4k for a while.
<ashi>
Glanzmann: Yes, that makes sense somehow, but also assumes that the kernel should work everywhere. At least my local config is now without a lot of stuff because I lack patience ;)
<Glanzmann>
mps: But probably rmk (Russel King) did because he needs it.
<Glanzmann>
ashi: I have very fast build machines and ccache. So for me it is fast. But I'm crosscompiling. But If I had to build my kernels on a m1, I would also be to impatient.
<ashi>
Glanzmann: I also do cross-compilation but on a fanless x86-86 which is slower than the m2 macbook air, but I do not want to let this run hot so long.
<ashi>
Glanzmann: another thing... is there a reason you went for CONFIG_DRM_APPLE which is disabled in the official config?
<ashi>
offical=asahilinux arch
<j`ey>
ashi: to try it out!
<ashi>
j`ey: okay, I enabled PM_SUSPEND to try it out :P - *seems* to work at least somehow
<j`ey>
thats good
<ashi>
I did not stay suspended last time I tried, but this time it seems to stay somehow suspended, there are some errors in dmesg that something could not reach a power saving state but I do not know the impact
<j`ey>
before the fixes it was *obviously* broken ;)
<ashi>
Now it is probably not perfect but at least not obviously ;)
<ashi>
dumb question, does having dcp support now means brighness support on a laptop screen?
<_jannau_>
no
<Glanzmann>
ashi: Because dcp was only very recenlty merged.
<_jannau_>
unless by brighttness support you mean switching to minimal brightness after suspend
<ashi>
_jannau_: no I prefer "last brightness from macos" behaviour
Dcow_ has joined #asahi-alt
<chadmed>
i need to have a think about how to bring the new fw handling across to gentoo. i like to think we have some latitude in terms of outright guarantees that stuff works with no intervention since... well, its gentoo
<chadmed>
but getting the firmware into the initramfs in a way that is consistent with asahi by default is good, users who gun for nonstandard setups are on their own though
<_jannau_>
I'd just make a dracut module for it, can probably shared with fedora. anyone using something else has to deal
<_jannau_>
also see if bootloader options to add the cpio are feasible
<chadmed>
we can just add to /etc/default/grub for the bootloader, or whatever sd-boot does (been meaning to look into that)
<j`ey>
markan mentioned GRUB_EARLY_INITRD_LINUX_STOCK
<chadmed>
yeah thats the one
<chadmed>
at the same time if we have a dracut module (akin to mkinitcpio hooks) we can just copy the firmware into the initramfs proper and disregard bespoke bootloader configs
Dcow has quit [Ping timeout: 480 seconds]
<chadmed>
the main thing is that the firmware gets loaded on first boot, which already isnt a problem for us because the gentoo install script i wrote runs update-vendor-firmware inside the chroot so that all the firmware is where the kernel modules expect it to be when you reboot into the rootfs
<_jannau_>
firmware handling in the initramfs instead of copying allows us to distribute installer images
<chadmed>
yeah, the idea appeals to me
<chadmed>
oh wow yeah ok this will be quite easy with a dracut module
<mps>
Glanzmann: thanks for info
ashi has quit [Ping timeout: 480 seconds]
marve has joined #asahi-alt
<marve>
hi
chadmed has quit [Quit: Page closed]
marve has quit [Quit: Leaving]
chadmed has joined #asahi-alt
ashi has joined #asahi-alt
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-alt
chadmed has quit []
ashi has quit [Quit: Leaving]
leif has joined #asahi-alt
<leif>
chadmed I started including the firmware in my image with a similar method. IIRC I though you said dracut wasn't working for you.
chadmed has joined #asahi-alt
<sam_>
chadmed: gentoo-kernel it'd be BDEPEND, for gentoo-sources it's more complicated but it's still pretty much a BDEPEND because nobody installs a binpkg of *gentoo-sources*
<chadmed>
dracut module works
<sam_>
but no, no discussion yet
<chadmed>
understandable, ill keep thinking. i think the most annoying thing is going to be having to pull in a specific version since rust_is_available complains if your rustc/bindgen is too new
<_jannau_>
it complains but builds fine, I'd restrict the version only if there are problems
<leif>
Interesting, I'd like how you approach that. I'll take a stab at this weekend.
<leif>
There's something about the firmware that I don't quite understand. After the all_firmware.tar.gz file gets created during the install process -- does ever get updated after that? Just trying to work out whether the firmware extraction piece is just a one-time operation.
<Glanzmann>
leif: Currently not, but there are plans to do so.
chadmed has quit [Read error: No route to host]
<Glanzmann>
But there might be later on needed to be extracted additional firmware from all_firmware.tar.gz in order to support previously unsupported hardware.
<Glanzmann>
That happened before with bluetooth.
<Glanzmann>
leif: markan planned on creating a stub upgrader if it becomes necessary for example once the gpu code is shipped.
<_jannau_>
leif: yes, it get's updated. asahi ships asahi-fwextract. used to extract the bluetooth and the usb pcie hcd firmware
<leif>
However, this only extracts firmware from all_firmware_tar.gz. What I was asking is whether there was a process in place to update the all_firmware_tar.gz file itself.
<leif>
Glanzmann Thanks
<_jannau_>
ah, sorry. I misread that. yes, that will only be updated by non-existing stub update progress
leif has quit [Quit: Leaving]
chadmed has joined #asahi-alt
chadmed has quit [Read error: No route to host]
<Glanzmann>
About the kernel and rust. Is a newer version fine or should I install exactly the version the kernel expects?
<Glanzmann>
Guess, I'll try it later and revert back for now. Interesting how to set up a rust build environment. But I went the unsuported way with gcc ...
<tobhe>
Glanzmann: did you manage to build a deb or just plain mainline kernel?
<mps>
hmm, interesting, I've built kernel and got appledrm.ko without any change in build env, even didn't knew this module is build
<_jannau_>
Glanzmann: you need GPU support in m1n1
<mps>
is the appledrm.ko gpu driver
<_jannau_>
tobhe: isn't 'make deb-pkg' in the kernel dir enough
<_jannau_>
no, appledrm is dcp
<Glanzmann>
jannau: I hope that I have it because I use the 'origin/lina/gpu-wip' branch of m1n1. This is how I build it: https://tg.st/u/gpu.sh
<tobhe>
_jannau_: depends on how you package i guess
<tobhe>
i was assuming debian use their own kernel build infrastructure
<Glanzmann>
tobhe: I did not create a deb, but I could do that.
<Glanzmann>
tobhe: You can use 'make; make modules_install; make install' on Debian if you want to redistribute it, you would use make bindeb-pkg (what I normally do).
<tobhe>
ah ic. Ubuntu doesn't use the upstream bindeb infrastructure and i wasn't sure about Debian
<Glanzmann>
tobhe: I'm not sure if Debian does, but I usually do it like this. At least since it is available. Before that I used something different.
<_jannau_>
Glanzmann: see "memremap attempted on ram 0x0000000bfff74000 size: 0x4000". unfortunately little information why there's a problem with that
<Glanzmann>
jannau: Do you think it makes a difference if I update my first stage m1n1?
<Glanzmann>
jannau: I have the 16 GB m1n1. IIRC markan has the 8 GB m1n1. Maybe there is a subtle difference.
<Glanzmann>
mps: As j said before. apple_drm is dcp and asahi_drm is the gpu.
<Glanzmann>
jannau: You did a nice job on dcp. I tested it only on the mini but the resolution is detected and powering off and on the monitor brings back the picture. I worked the whole day with it.
<Glanzmann>
jannau: Modeswitching also appears to be working nicely. :-)
<mps>
hmm, lets try build again then
<mps>
though I don't need gpu for now
<Glanzmann>
mps: Let me know, if it works for you.
<mps>
uh, I see it will not work, probably have to add some things to build env. have to look what
<mps>
maybe need to add rust to makedepends
<jannau>
Glanzmann: I can't see how 1st stage m1n1 would make a difference, running here with random 1st stage m1n1, probably from the 1st alpha release
<jannau>
no, should work with 16GB, and the failing address is at the end of 16GB physical ram as expected
<Glanzmann>
jannau: I see, maybe I should try to build it with clang than.
<jannau>
build 2nd stage m1n1 with clang? makes no difference. mine is build with gcc
<Glanzmann>
I see, I thought about building the kernel with clang. Because I'm using gcc for the kernel and the rust kernel quickstart said gcc is experimental.
<Glanzmann>
jannau: If you want you can send me your kernel config and I'll give it a spin. But this time I started fromt he PKGBUILDS/asahi config and only added apple_drm and asahi_drm + plus dependencies.
<Glanzmann>
But I can also wait a little bit longer until it is in the official installation and than try again.