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
swaggie has joined #asahi-alt
swaggie has quit [Remote host closed the connection]
swaggie has joined #asahi-alt
jamespmo_ has joined #asahi-alt
jamespmorgan has quit [Ping timeout: 480 seconds]
swaggie has quit [Remote host closed the connection]
swaggie has joined #asahi-alt
swaggie has quit [Ping timeout: 480 seconds]
swaggie has joined #asahi-alt
swaggie has quit [Remote host closed the connection]
swaggie has quit [Remote host closed the connection]
swaggie has joined #asahi-alt
swaggie has quit [Ping timeout: 480 seconds]
swaggie has joined #asahi-alt
swaggie has quit [Ping timeout: 480 seconds]
swaggie has joined #asahi-alt
Dcow has joined #asahi-alt
Dcow has quit [Ping timeout: 480 seconds]
swaggie has quit [Ping timeout: 480 seconds]
Glanzmann has joined #asahi-alt
<Glanzmann>
jannau: Thank you. I'll incorporate it. I have only a 2k screen on the mini. Ry_Darcy has a 4k screen on the mini, but he did not complain. So I assume it works for him. What kind of resolution do I need to reproduce the error? Unfortunately the biggst screen I have is a TV with 4k.
<mps>
how can I know if I have display with this thing called 'notch'? I'm using m1pro macbook
<Glanzmann>
mps: I think the current m1n1 spares out the notch.
<Glanzmann>
If you want to use the notch areas you need to patch m1n1. Don't know the details but it was in the irc backlog somewhere.
<mps>
Glanzmann: thanks. I don't have any incetive to extend screen area just curiosa
<Glanzmann>
mps: I see.
ashi has joined #asahi-alt
swaggie has joined #asahi-alt
<ashi>
mps: the notch is hidden by default, I can only speak for the m2 air, resolution is 2560x1600 with notch hidden, but there is an extra space with rounded edges and no pixels where the webcam is, making ist 2560x1664 (64 extra height)
<ashi>
mps: I enabled the notch area and patched gnome3 css to make the top panel 64 pixel, and moved the date/time display to the right with a gnome shell extension, this is super cool imo, so 2560x1600 real screen resolution with the area around the notch for panel applet stuff
<ashi>
mps: enabling the notch is a kernel/module parameter, you do not patch/compile anything yourself
<j`ey>
mps: the 'notch' is the webcam that comes over the screen a bit
<ashi>
"2560-by-1600 native resolution at 227 pixels per inch"
<ashi>
Anyway using that area with a DE with a top panel makes sense
<mps>
ashi: j`ey: I see, thank you
<mps>
on my m1pro resolution is 3456x2160
<ashi>
mps: let me know if I should look up how I enabled it
swaggie has joined #asahi-alt
<mps>
ashi: not needed, I know what is needed in kernel cmdline 'apple_dcp.show_notch=1'
<ashi>
mps: looks familiar ;)
<mps>
will test right now
Dcow has quit [Ping timeout: 480 seconds]
<ashi>
Problem is if you really go fullscreens then the notch might be annoying, but for desktop stuff I like it.
<mps>
ashi: yes, it works out of the box
<mps>
but yes, looks like is not good to enable it for my setup
<mps>
btw, I noticed again u-boot boot loop with usb-c ssd plugged when booting
<ashi>
mps: Which setup do you use, out of curiosity...
<mps>
ashi: awesome wm with status bar on bottom
<mps>
maybe I should move status bar to top
<ashi>
mps: yes, or get another one for free :)
<mps>
another status bar?
swaggie has quit [Ping timeout: 480 seconds]
<ashi>
Yes, I mean you now have a "black status bar" on the top :D - you could also fill the area with anything you like left and right to the notch :)
<mps>
ashi: just changed to top, now screen look better
<mps>
but I will have to get used to it
<ashi>
screen estate is valueabe, so could make sense one you get used to it ;)
<jannau>
Glanzmann: configuring the display in m1n1 to a resolution larger than 2560x1600 (real limit is above that but that's the commom display resolution which I remember still works)
<jannau>
Glanzmann: Ry_Darcy complained a few weeks ago and I think you confirmed. no need to patch m1n1 except for testing. it will land in upstream m1n1
<mps>
ashi: mostly irritating thing for me is firefox which also have tabs and menu on top and then I have two bars on top
<mps>
rest of software I use daily is fine with awesome wm status bar on top
swaggie has joined #asahi-alt
swaggie has quit [Ping timeout: 480 seconds]
Ry_Darcy has joined #asahi-alt
<Ry_Darcy>
I have automatic 4K display resolution now (M1 Mini) without doing any echo display= etc.
Ry_Darcy has quit [Remote host closed the connection]
jamespmorgan has quit [Remote host closed the connection]
jamespmorgan has joined #asahi-alt
swaggie has joined #asahi-alt
<ncopa>
should apple_dcp.show_notch=1 work on mbp 14 too? Does not seem to work on my machine
<jannau>
Ry_Darcy: yes, but only after the drm driver has reconfigured the display
<jannau>
ncopa: yes, it was only recently merged. you need asahi-6.1-2
<ncopa>
mps: I am refactoring the alpine linux-asahi and u-boot-asahi packages. You will have to `apk add u-boot-asahi` as linux-asahi will no longer depend on u-boot-asahi. I have also moved the update script for m1n1 to a trigger to u-boot-asahi, so it gets triggered when either kernel, u-boot or m1n1 is updated
<ncopa>
jannau: should be the kernel i am running
<ncopa>
Linux ncopa-mbp14 6.1.0-2-asahi #3-Alpine SMP PREEMPT Fri, 23 Dec 2022 13:53:36 +0000 aarch64 Linux
<ncopa>
ok. so if i charge the iphone via usb port
<jannau>
winter: mostly unrelated: xvmc is dead and will never supported on apple silicon devices
<jannau>
mps: which u-boot version/commit boot loops? Any u-boot messages printed? if not recognizable try recording it with a smartphone camera with slow motion
<winter>
xvmc? or maybe the asahi pkgbuild just includes it with other stuff that tpw's package disables
<mps>
ncopa: jannau suggested to not enable APPLE_DRM for distros yet
swaggie has joined #asahi-alt
<mps>
because this I didn't enabled it though I was very tempted
<mps>
jannau: what you think about this ^
<mps>
jannau: u-boot boot looping is this tagged release asahi-v2022.10-1
<mps>
oh, btw I'm also tempted to enable ASAHI_DRM for alpine but didn't
<jannau>
it's too early to enable it in distro's main linux kernel package. same for DRM_ASAHI
<mps>
jannau: for u-boot message I have to make video or photo
<mps>
ncopa: see what jannau says about distro kernel ^
<mps>
though I found both working fine but understand that they still are not 'stable'
<ncopa>
so, this would be for alpine edge (rolling) kernel itself is in testing repo, so i don't think anybody expect anything to be stable at this point
<winter>
DRM is enabled in edge though, iirc, right?
<mps>
jannau: u-boot loop messages is same as earlier when we had this issue, saying from memory
<mps>
winter: not on alpine edge
<mps>
winter: it is on asahi alarm linux-asahi-edge pkg
<winter>
yeah, by "edge" i meant asahi-edge on alarm
<winter>
sorry for the confusion
<mps>
winter: np
swaggie has quit [Ping timeout: 480 seconds]
<mps>
ncopa: also I think kernel linux-asahi should depend on u-boot-asahi for alpine
<mps>
and the versioned dependency
<mps>
much safer
<jannau>
mps: what kind of SSD is that? this seems to be a different issue than the device not ready fix for usb-c hubs/card readers
<jannau>
I don't remember what the issue was with your ssd. I thought it was the same issue as the card readers but the fix for that is in asahi-v2022.10-1
<mps>
jannau: I could test later with another usb-c ssd
<mps>
and with usb-c hub with mmc card reader
jamespmorgan has quit [Remote host closed the connection]
<ncopa>
mps: i disagree on the hard dependency of u-boot-asahi for the kernel. At some point i will boot the kernel in qemu, and you don't need u-boot for that
<mps>
ncopa: you will boot linux-asahi kernel in qemu? why?
swaggie has joined #asahi-alt
<mps>
jannau: I tested u-boot with another usb-c ssd and it works fine, i.e. no boot loop
<mps>
jannau: also tested with usb-c hub with two mmc card readers, also works fine
<mps>
jannau: so boot loop happens only with above mentioned transcend usb-c ssd
<ncopa>
mps: because i want test boot the kernel to make sure its not completely broken before pushing it on updates
<ncopa>
it lets me test that the trigger scripts works as they should, that installer works as it should, etc
<mps>
ncopa: but testing linux-asahi in qemu doesn't guarantee it is ok
<ncopa>
of course not, but it lets me conveniently test everything around it in a virtual environment
<mps>
ncopa: ok, do what you think is best
<ncopa>
just like i test the linux-lts kernel in qemu, not only the linux-virt kernel
<mps>
I usually test kernels with external usb ssd or stick before pushing upgrades
<mps>
yes, this makes sense for linux-lts but not sure about linux-asahi
<mps>
ncopa: to be clear, I trust you that you will do proper things and I don't argue with your opinions, just expressing my my thinking
swaggie has quit [Ping timeout: 480 seconds]
<mps>
btw, Greg Kroah-Hartman just told me that we don't need to enable CMA for arm64 kernels in general, and only for specific SoCs cases
<mps>
so I will disable it for alpine kernel
<jannau>
CMA is not needed for asahi. we have IOMMUpple sisahi. I think it's still enabled in out configODODODODODODODthe asahi disto config
<jannau>
CMA is not needed for asahi. we have IOMMUs. I think it's still enabled in the asahi distro config