marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | Not ready for end users / self contained install yet. Soon. | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
Gaspare has quit [Quit: Gaspare]
willemml has joined #asahi
willemml has quit [Quit: willemml]
jx0 has joined #asahi
sri has joined #asahi
sri_ has quit [Ping timeout: 480 seconds]
<marcan>
tpw_rules: re the display stuff, can you poke around the sequences a bit? I can't really test it without a monitor that repros :(
<marcan>
I really don't want to add a 5 second delay for everyone...
<marcan>
though we could make this configurable if it comes to that
kov has quit [Quit: Coyote finally caught me]
phiologe has joined #asahi
kov has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
<tpw_rules>
marcan: the patch seems like a poor man's way of implementing hotplug support. is there a way to do that for real?
<tpw_rules>
i'm not sure that is because you would have to have code in the background monitoring the hdmi connection i would think. and in u-boot and its efi services. but i think the sequence of operations as documented in the issue is accurate. i don't know how you would predict how long it would take a slow monitor to disconnect so you know it's connected for good before you leave the init function
<tpw_rules>
kov: finally sat through the webkitgtk build and it seems to work properly now with your patch, thank you!
<tpw_rules>
updated my nixos stuff to the shiny new asahi branches. hoping to revise the guide soon
gladiac is now known as Guest340
gladiac has joined #asahi
Guest340 has quit [Ping timeout: 480 seconds]
axboe has quit [Quit: leaving]
psykose has quit [Remote host closed the connection]
psykose has joined #asahi
<marcan>
tpw_rules: hotplug isn't really practical here, we don't do interrupts or timers or anything and we definitely don't want u-boot doing the same and nothing in the boot stack expects hotplug framebuffers
<marcan>
so that's basically out of the question
<marcan>
the screen gets initialized once, and better stay there; that's also how iboot did it anyway
<marcan>
one workaround we *could* add is a second hotplug pass after loading payloads and such, just to parallelize the delay a bit
<marcan>
but really what I want to know is can we do this in a way that does not introduce a 5 second delay for everyone
<marcan>
1-2 seconds would be tolerable
<marcan>
if there's no workaround for this it's going to have to be some kind of payload option people with problematic screens can enable at install time
<marcan>
what I want to know is whether invoking DCP ops in e.g. a different order, or doing something different, can mitigate the issue
<marcan>
since the current sequence is basically guesswork based on static RE, since we don't know what iBoot ddi
<marcan>
*did
<marcan>
*why* do those monitors re-hotplug? that doesn't make a lot of sense
<tpw_rules>
marcan: ah, ok. well i can tell you that whatever iBoot did didn't work on my monitors
<tpw_rules>
but i see what you mean better now, i'll see if i can figure out something
<tpw_rules>
how did you discover the information on the iBoot protocol you have already?
<j`ey>
I guess that driver got added after dmitiry's shutdown notifier patch was written
<as400[m]>
So we don't need it actually ?
<mps>
as400[m]: no
<mps>
it is for freescale
sri has quit [Remote host closed the connection]
sri_ has joined #asahi
sri has joined #asahi
<Glanzmann>
as400[m]: You need to disable that kernel option.
<as400[m]>
Glanzmann: yes, I did.
<as400[m]>
thx
<Glanzmann>
as400[m]: It was also disabled in my config, I just checked.
<Glanzmann>
as400[m]: But I had the same issue yesterday.
sri_ has quit [Ping timeout: 480 seconds]
<Glanzmann>
jmr2: Maybe it was the issue in m1n1, because I thought I update m1n1 on my webserver when I run bootstrap.sh from the m1-debian repository, but I don't so maybe my m1n1 was a few days old. But I corrected that and will see if I see the issue later on.
bps has joined #asahi
<mps>
I don't understand why REGULATOR_PFUZE100=y is problem? if it doesn't exist it will not be detected by kernel, or it exists in M1?
<j`ey>
it's a compile time error, because an API has changed from a commit that got cherry-picked
<mps>
j`ey: ah, that make sense then
<marcan>
j`ey: I dropped the patch for that because I thought it was an example, didn't realize it actually broke with the shutdown notifier patch
<marcan>
I'll put it back in a bit when I do another cleanup pass
<j`ey>
ah ok, I assumed it was just a new driver in the mean time
<kov>
tpw_rules, \o/
off^ has joined #asahi
<as400[m]>
guys - how much time do you get from battery with cpufreq enabled ?
<Glanzmann>
as400[m]: At least 6 hours.
<Glanzmann>
Now I think more like 10 hours.
<Glanzmann>
Before cpufrequ It was giving me 6:41 during a regular work day.
<as400[m]>
What ? Really 10 hours ????
<Glanzmann>
But I was only charged like 80%
<as400[m]>
Wow - impressive
<Glanzmann>
as400[m]: If you want I pull the plug now and tell you when the system crashes.
<Glanzmann>
as400[m]: I'm on macbook air.
bps has quit [Ping timeout: 480 seconds]
<mps>
as400[m]: with conservative cpu freq policy I expect more than 10 hours
<as400[m]>
Nah - don't do this to your poor mba :)
<mps>
maybe I should add event handler for power plug to switch policy automatically from performance to conservative when unplug power cable
ciggi has joined #asahi
<j`ey>
mps: can you do it without udev?
<mps>
j`ey: yes, with busybox acpid but if there are event signal
<mps>
or with libudev-zero with script handler
<j`ey>
ah
<mps>
but I don't see any event when I plug/unplug power, so maybe with small 'sleeping' daemon for now or cron job
<sven>
not sure if the current smc driver does it but you can also activate those events and will get a rtkit message on those
<mps>
you got dmesg as I do, I mean on /dev/input/eventX
<sven>
someone just needs to hook up those events to whatever is the correct subsystem otherwise
<Glanzmann>
sven: I thought about starting to be able to turn of the lcd backlight on and off.
<mps>
yes, that part is missing
<sven>
isn’t that DCP? Or is that smc as well?
<Glanzmann>
sven: The backlight is smc.
<Glanzmann>
But I think only on and off.
<Glanzmann>
But for a start that would be enough.
<mps>
Glanzmann: till someone find registers and values for backlight/brightnes control
<as400[m]>
Glanzmann: doesn't the backlight go off for you automatically ?
<Glanzmann>
as400[m]: Nope. When you're in a dark room, you can see that the backlight is on when the lid is closed.
<Glanzmann>
I found a simple enough backlight driver: drivers/video/backlight/gpio_backlight.c
<Glanzmann>
I thought about playing with it by copying the driver and see if I get to the point where I can turn it off and on.
<mps>
Glanzmann: does it works for you
<Glanzmann>
mps: No, I was just searching for an easy example.
<mps>
ah, I see
<mps>
but do anyone knows how backlight is controlled in M1
<j`ey>
via the dcp
<mps>
by setting pin or register/s
<Glanzmann>
j`ey: I thought about this in the wiki smc documentation: * `gP12`: on at least one system, the LCD backlight. Can be turned off, which reduces apparent power consumption, and turned back on.
<mps>
my guess is that backlight is controled by PWM, but don't know
<j`ey>
Glanzmann: yeah, you can try thta from m1n1, that will be the best way to start
<j`ey>
proxyclient/experiments/pcie_enable_devices.py is a good example to look at
<Glanzmann>
j`ey: I see, thanks.
<sven>
if it’s a smc gpio it might just need a device tree node to hook up that gpio backlight driver to the smc
<as400[m]>
I guess also nvme uses a lot of power
<Glanzmann>
sven: I also thought about that. :-)
<Glanzmann>
But have not figured out how to do that. That would be really nice.
<sven>
You want to look for the dt binding of that driver
<sven>
it should contain an example
<sven>
but I’m willing to bet it just needs the right compatible and a gpio = <…> reference to the smc if it’s indeed just a smc gpio
<Glanzmann>
sven: I found an example from another device table which is using it.
<sven>
I haven’t looked into the smc driver but I assume there’s a node that is a gpio-controller
<Glanzmann>
sven: Yes, I think there are also other references to the gpio in the device tree.
<sven>
ok, so just do the same for the backlight node then
<Glanzmann>
Okay, I'll try that. But first I try that thing with m1n1 if really does what I think it does.
<jannau>
there's also tools/smccli.py
<Glanzmann>
I see.
sri has left #asahi [Leaving]
<j`ey>
macOS does read the smc a whole lote
<j`ey>
constantly reading MSX2 key
<tpw_rules>
VinDuv: yes, both of my monitors displayed the same symptoms
<Glanzmann>
I tried by modifying proxyclient/experiments/pcie_enable_devices.py and it works.
<j`ey>
as in, the screen goes blank?
<Glanzmann>
Yep.
<Glanzmann>
And it goes on again with the same content
<j`ey>
and then you can turn it back on with writingg 1 instead of 0?
<Glanzmann>
Yep.
<j`ey>
cool!
bps has quit [Ping timeout: 480 seconds]
bps has joined #asahi
bps has quit [Ping timeout: 480 seconds]
<kov>
nice
<VinDuv>
tpw_rules: I see. I guess whatever delays iBoot uses are not sufficient with your monitors. I’m still wondering if iBoot somehow manages to avoid the disconnect/reconnect wait period in my case, or if it waits for it asynchronously while booting the rest of the system
<j`ey>
remember that you wont get brightness 'steps' with this, just on/off
<Glanzmann>
I know, good enough for me.
<tpw_rules>
VinDuv: so your monitors did work with iBoot 11.x?
<tpw_rules>
that did confuse me a bit
<tpw_rules>
i wonder what happens if you set the mode while the monitor is disconnected. presumably the problem is that dcp forgets the mode when the monitor disconencts
<tpw_rules>
i read the HMDI spec and it seems well within the monitor's rights to cycle like this. like i said before i don't think anything is going wrong aside from hotplug not being supported
<sven>
getting true hotplug to work correctly inside m1n1 would be quite annoying :/
<tpw_rules>
yes, i recognize that
<sven>
we could always hack it by having a second core polling the whole time but that’s quite ugly :D
<tpw_rules>
and will stop working once u-boot gets started, right?
<sven>
oh, right. yes
<sven>
but I thought the monitor only did that weird disconnect/connect dance once
<tpw_rules>
well the problem is you have to wait a while for it. and the time it takes for m1n1 to init the hardware and load u-boot is pretty negligible
<tpw_rules>
so waiting in the main thread while a second core polls isn't any better than just polling in the main thread i don't think
<sven>
ugh, right.
<VinDuv>
tpw_rules: one of them yes, the other one still occasionally fails (power-up then “no signal”) with 11.x
<VinDuv>
I’m also pretty sure that it only starts waking up on dcp_ib_swap_begin, not dcp_ib_set_mode
<tpw_rules>
then how does your new code work?
<tpw_rules>
i thought it still only did one swwap
<VinDuv>
it does the wait and the set_mode after swap_begin and before swap_end
<VinDuv>
which is probably extremely not like things should be done
<VinDuv>
(I think I tried doing the wait/set_mode after swap_end; it worked and the monitor stayed up, but it was blank, probably because the framebuffer address changed)
<tpw_rules>
oh, i think i misunderstood it then
<kov>
one thing I have come to like on macos is the trackpad behaviour where a drag will have a small timeout before it drops (so you can quickly take the fingers off and resume the drag), is that a thing that can be configured in X/libinput does anyone know?
tomtastic_ has joined #asahi
tomtastic has quit [Ping timeout: 480 seconds]
<mps>
kov: this looks more like it is in firmware for touchpad than it is libinput option/feature
<kov>
mps, could be, so would have to be exposed by the driver like the swap_ parameters I guess
<mps>
kov: you could try play with TappingDragLock maybe will work (I didn't tried)
<tpw_rules>
the EFI partition doesn't have the concept of users and groups so those operations will fail
<tpw_rules>
but it doesn't matter
<mps>
tpw_rules: yes, this annoys me currently because I install vmlinuz-$ver-$var-$min to ESP (vfat) now
<Glanzmann>
David[m]123456789: as tpw_rules said the last tar was good
<David[m]123456789>
The script for downloading the wifi firmware in the debian wiki page did not finished (nothing displayed), the python3 (wich is installed) call did not worked it seems but I cped the wifi folder in `/usr/share/firmware/wifi` to my USB key
<David[m]123456789>
s/but/so/
<Glanzmann>
David[m]123456789: This needs to run under macos.
<Glanzmann>
Can you please paste the complete output?
<David[m]123456789>
there was really nothing
<Glanzmann>
David[m]123456789: have you seen the video?
<David[m]123456789>
will rewatch it
<Glanzmann>
David[m]123456789: So when I run this command under macos or 1tr I get the output, you see in the video.
<Glanzmann>
Maybe you misstyped the command.
<Glanzmann>
But in order to help you, you must paste the complete output (including the command you issued).
<David[m]123456789>
curl -sL tg.st/u/fwx.sh | sh
<David[m]123456789>
* `curl -sL, * | sh`
<David[m]123456789>
I remeber runing it by mistake before so maybe this folder was created at this time
<j`ey>
David[m]123456789: can you run it again?
<j`ey>
on macOS or 1TR
<David[m]123456789>
seems to works now, thanks
<Glanzmann>
Perfect. Do not forget to copy the firmware to the usb stick, if you plan on installing debian over wifi.
<David[m]123456789>
macOS
<j`ey>
David[m]123456789: did you copy what the script told you to copy?
<j`ey>
/usr/share/firmware is the wrong thing
<David[m]123456789>
Yes, i'm connected
<David[m]123456789>
The debian installer displays nonsense characters in french. Will upload pics once done
off^ has quit [Ping timeout: 480 seconds]
mlq has quit [Quit: WeeChat 3.0]
off^ has joined #asahi
<j`ey>
i'm looking at https://support.apple.com/en-gb/HT212749 because I pretty much want to wipe my m1 now that Im going to upgrade to 12.x, does this actually erase all the paritions? or should I delete them with diskutil first
<tpw_rules>
i think if you try to delete them with diskutil it will let you, but force you to reboot into recovery mode to install the os again
<j`ey>
i meant the paritions I made for m1n1 etc
<tpw_rules>
oh. i would just delete them all with diskutil and not bother with whatever that utility is
<Glanzmann>
j`ey: Easiest way is to delete them using linux (rember to keep the first two and the last parition)
<Glanzmann>
j`ey: Under macos you can use diskutil apfs deleteContainer to delete the stub partition.
<Glanzmann>
j`ey: If you find a way to delete the esp and linux parition let me know, than I document it.
<tpw_rules>
Glanzmann: afair you can just use the minus button in disk utility
<tpw_rules>
or diskutil mergePartition or so from the command line
<Glanzmann>
tpw_rules: It did not work for me if the type was Linux or esp.
<tpw_rules>
hm, i thought i've done it before
<Glanzmann>
When they have the parition type msdos, it works.
<Glanzmann>
but not for efi or Linux or I did not find out how.
mlq has joined #asahi
<Glanzmann>
anyway I'm sure it works on the cli diskutil, but don't know how. If someone finds out, let me know I would like to document it.
<Glanzmann>
Btw. about the backlight, it need to be attached to a display as far as I can tell.
<j`ey>
Glanzmann: what do you mean attached to a display?
<Glanzmann>
Yes, but I'm not sure anymroe. Because I search for an example and could not find one.
<Glanzmann>
One my thinkpad the intel_backlight is part of the intel drm driver.
<j`ey>
has anyone got output of a fresh macOS: diskutil list?
<mps>
gpio pins could be controlled by shell by writing values in proper files under /sys
<mps>
s/by shell/by echo/
jmr2 has joined #asahi
<jmr2>
j`ey: my experience with "erase all content and settings" is that it won't resize the macos partition to use the whole disk in some cases. Not clear which. But it will properly reinitialize macos.
axboe has joined #asahi
<jmr2>
So if you want a specific partition layout, my recommendation is to do it manually.
<jmr2>
I personnally chose to have the Linux partitions before the macos ones, because macos's diskutil renumber partitions when you create new ones, which force you to update anything that refers to nvme0n1pX.
<jmr2>
For info, I also got a corrupted m1n1 stub in the process, requiring marcan's "double-click and hold after 3s" trick. The installer was reporting it as a "broken stub", but I ignored that - to my expense.
<jmr2>
David[m]123456789: by curiosity, what ended up being the solution to your "unknown user David" issue?
<David[m]123456789>
it was david
<j`ey>
jmr2: how did you get the macOS ones first?
<jmr2>
David[m]123456789: OK, thanks.
<j`ey>
jmr2: I erased all my linux stuff, and then I did resizeContainer diskX 0, to get the freesoace used by macOS
<jmr2>
j`ey: I'm not sure I follow you.
<jmr2>
Do you mean the Linux ones first ?
<j`ey>
jmr2: yes sorry
<jmr2>
OK. What I did was 1) install m1n1 2) set that partition as startup disk 3) boot from it in recovery mode 4) delete the macos partition
<jmr2>
5) create a temporary 30GB "placeholder" partition, to be used for the m1n1 + EFI + /boot ones later 6) create an apfs one of the size I want for MacOS
<jmr2>
7) install macos in that one 8) create multiple smallish partitions at the end of the disk, to be used for /root over lvm
<j`ey>
ok that sounds pretty complex
<jmr2>
My goal is to be able to have more linux or more macos space as needed, without needing to reinstall again.
<jmr2>
MacOS can expand easily into free space, and linux can expand through more lvm partitions.
<jmr2>
I'm just tired of reinstalling it all :-)
<j`ey>
heh yeah, it's a bit of a pain
<David[m]123456789>
followed the debian installer video but when I rebooted, there were a simili 2 flashes of the Apple logo then I entederred recovery which says tha amy custom kernel was not able to boot and then proposed to change my startup disk with only Machintosh HD available (which I did), there is still no more available asahi available as startup disk
<David[m]123456789>
s/followed the debian installer video but when I rebooted, there were a simili 2 flashes of the Apple logo then I entederred recovery which says tha amy custom kernel was not able to boot and then proposed to change my startup disk with only Machintosh HD available (which I did), there is still no more available asahi available as startup disk/followed the debian installer video but when I rebooted, there were 2 flashes of the Apple
<David[m]123456789>
logo followed by recovery which says that my custom kernel was not able to boot and then proposed to change my startup disk with only Machintosh HD available (which I did), there is still no more available asahi available as startup disk/
<j`ey>
Glanzmann: I didnt figure it out at the diskutil cli, but I managed to do it from the GUI, I think you have to erase/reformat as APFS before you can delete the volumes
<Glanzmann>
j`ey: Thank you.
<j`ey>
so maybe trying with eraseVolume (I think that was a diskutil apfs command) first will help
<Glanzmann>
j`ey: I think I tried that once, maybe I managed, maybe not
jmr2 has quit [Remote host closed the connection]
<David[m]123456789>
Glanzmann I installed U-Boot and booted the installer through it
<tpw_rules>
you can delete a non-apfs partition with: diskutil eraseVolume free n disk0sX
<tpw_rules>
where that n in the middle is literal
<j`ey>
free meaning.. make it free space or?
<tpw_rules>
yes
<Glanzmann>
David[m]123456789: Yes.
<j`ey>
tpw_rules: nice, diskutility GUI crashed when i erased the first volume heh
<Glanzmann>
Nice.
<tpw_rules>
you have to use diskutil apfs deleteContainer disk0sX to get the stub
<j`ey>
I need to understand it a bit more, I thouht that my efi/data volumes were part of my container stub
<j`ey>
but when i deleted that container, they were still there
<tpw_rules>
no
<tpw_rules>
containers are physical partitions with a bunch of logical APFS volumes
<tpw_rules>
each OS is a separate physical partition, plus more for efi and data
<j`ey>
well I never explicitly created volumes or containers, only partitions with diskutil addPartition
<tpw_rules>
when you formatted the first one as apfs in order to make the stub, it turned into an apfs container
<tpw_rules>
then the install process added a few volumes
<j`ey>
fair
<sven>
apfs containers are more like volume groups. we’d need a pretty good apfs driver to use them from linux
<tpw_rules>
can containers span multiple physical partitions?
<sven>
no idea
<j`ey>
it's funny, even with needing 70GB or so for the macOS space, Im still going to have more storage than I do on my current computer :D
<jannau>
tpw_rules: I think it can have 2 physical partitions as it supports apple's SSD+HDD Fusion drives
<sven>
ohhh… right, those things existed:D
<sven>
but I guess it would just use one of those two as a cache instead of increasing the totale space
<sven>
Or did it actually combine the space and just distribute stuff depending on how often it was used
<jannau>
I think it distributed blocks depending on how often it was used
<mixi>
Glanzmann: https://tg.st/u/backlight_notes.txt looks right to me, and should make a /sys/class/backlight/backlight appear (the "backlight:" is only necessary if you want to refer to it from another node though)
<mixi>
it should also have created /sys/firmware/devicetree/base/backlight entry from the device tree node alone though, so my first guess would be that you are loading the wrong device tree again
bps has joined #asahi
zv has joined #asahi
da_n has joined #asahi
<zv>
hello, anyone experience mac mini going to a black screen immediately after flashing "Options" (after the reboot in step 2) ?
<zv>
from fully powered off, I hold the power button for ~12 seconds, I see "Options" then the display goes black.
<tpw_rules>
that sounds like you are holding the power button too long?
<tpw_rules>
and it's just shutting back off agian
<zv>
it's definitely on -- caps lock LED lights, mouse lamp is on...
<j`ey>
try the recovery thing that marcan wrote about
<jannau>
when did you run/downloaded the installer? today or a couple of days ago?
<zv>
a half hour ago
<zv>
if I don't hold the power button, it boots to "This version of macOS on the selected disk needs to be reinstalled." and the display works, but of course it's not in the right mode.
<jannau>
which macos version did you chose for the stub install? 12.0.1 or 12.1? which version is your main macos?
bps has quit [Remote host closed the connection]
<zv>
12.1; I am running 12.2.1
<jannau>
can you easily try a different display or display cable? it sounds like recovery doesn't like your display. not sure what could be broken
<zv>
I tried a dock with displayport, same thing, but unfortunately I don't have a different monitor available.
<zv>
before (out of the box) I was able to get to the Options menu, which was necessary due to an unrelated macos installer bug
<zv>
this all worked with the same hardware as is currently connected
<jannau>
not sure what could break, recovery should behave the same way as full macos
<jannau>
does macos 12.2.1 still work with the display? you should be able to change the startup disk in the "This version of macOS on the selected disk needs to be reinstalled." recovery
<zv>
so this is *really* strange. I have a broken HDMI 7-inch display, connected it, and held the power button until it started glitching (meaning, picture). unplugged that, put back the normal monitor, and I see 3 items: macOS, Asahi, and Options. Good, right? then the display fades to black quickly, immediately after I see the picture.
<zv>
macos 12.2.1 still works fine after changing the startup disk.
<jannau>
is that repeatable if you disconnect and reconnect the display? did you ran macos 12.1
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<zv>
I think the problem is my display; I can't even source-select on it without disconnecting HDMI first (meaning the display seems to have locked up). is the mac sending non-conforming HDMI data? I need to find another display; don't think it's an Asahi problem.