ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
A_L_I_C_E has quit [Ping timeout: 480 seconds]
A_L_I_C_E has joined #asahi-dev
A_L_I_C_E has quit [Read error: Connection reset by peer]
<jannau>
kettenis: latching the firmware on as initrd breaks booting linux via grub. linux prefers the initrd from /chosen and booting with firmware.cpio doesn't work
<jannau>
deleting the linux,initrd* properties from chosen on u-boot command line fixes it
<jannau>
usb xhci works in linux without and with firmware (patched to check link status before setting up the port)
<jannau>
how do we want to handle the firmware? appanding it to boot.bin doesn't look very appealing to me. Do we want m1n1 to to load it from the ESP?
<jannau>
I suppose having u-boot load it from ESP is not an option since it needs to be available at init
<jannau>
ChaosPrincess: I fear you won't have much luck getting the driver merged with sw rotation. How does macOS handle this. I would expect the HW to support rotation if it is an old iphone display controller
chipxxx has quit [Ping timeout: 480 seconds]
<jannau>
did rotation in struct drm_plane change after you added panel_orientation? I suppose this is the way it is supposed to work with display controllers supporting rotation in HW
<jannau>
since you can't (yet), you proabbly have to reject plane states with rotation in atomic_check
newiz has quit [Remote host closed the connection]
<jannau>
not sure if that will fix anything since it would then depend on user space to have SW rotation fallback
<jannau>
using the sw rotation in the driver for is of course fine if it makes testing less annoying
<ChaosPrincess>
jannau: macos handles this by having surfaces rotated the right way already
<ChaosPrincess>
And i wasnt able to find rotation registers by writing random stuff to random registers and seeing what happens
<jannau>
ok. since we will be in the control of userspace we should also use pre-rotated surfaces
<ChaosPrincess>
There is also still the issue that x thinks it is the primary screen, and tries to display sddm/kde there
<ChaosPrincess>
while primary stays completely black.
<jannau>
although ideally we would prevent X form using the display at all, might be fixed by ensuring the touchbar daemon starts before X
<jannau>
I'll try to see if I can ensure that dcp reliably is card0
<ChaosPrincess>
jannau: where do i put those configs again?
<ChaosPrincess>
added https://paste.bingner.com/paste/kmr4s - now it only displays on primary, and touchbar does not even show in kde display configuration
gabuscus has quit []
<ChaosPrincess>
and, thats an X problem, wayland sees both
<jannau>
that's X config so it is expected to only affect X. it's a relieve that that works as it means we do not have to fix X. ensuring that various wayland compositors don't do silly things might take some time but at least we can fill bug reports
gabuscus has joined #asahi-dev
urothis has joined #asahi-dev
<urothis>
I have a weird issue with pikvm and the asahi bootloader. Some discussion has led me to believe this is related to the kvm wanting 50hz instead of 60. Is there any guides/data on how to check the logs or how to debug m1n1?
<jannau>
if you want a less fiddly proxy mode setup you can either do a second installation with "m1n1 proxy" or temporary replace m1n1/boot.bin on the ESP with a plain m1n1.bin
<jannau>
access is then available over usb. the m1n1's console output will be forwarded the first time you connect
<jannau>
with `tools/chainload.py -r ../build/m1n1.bin` from the proxyclient directory you can load you locally build m1n1
<jannau>
display code is in src/display.c
<jannau>
but if you just want to test if it is the refresh rate you could edit the commneted display= line in /etc/m1n1.conf and run update-m1n1
<jannau>
ChaosPrincess: dcp is intentionally written in a way it doesn't get card0 to be more resilient against error during initialisation. It removes simpldedrm late so simpledrm works as display if something fails during init
<jannau>
not sure if that still makes sense. I haven't heard any complains lately and we support nomodeset should there be issues
<ChaosPrincess>
rebased the touchscreen patches on display ones - whatever is processing the touchscreen events thinks they belong on the primary screen and so they end up on the wrong one
<chadmed>
if we're going to init dcp in m1n1 going forward anyway do we even need simpledrm at all
<jannau>
I doubt we want to init dcp for devices with integrated display. dcp will be shut down when leave m1n1 so I don't see how that changes anything and distro kernels will still built-in simpledrm and have large hw specific display drivers as module
<jannau>
ChaosPrincess: touchbar display works on M2 as well
<ChaosPrincess>
nice
<ChaosPrincess>
send the device tree my way if you dont mind, i will be changing it so mipi is not done as just a hack
<mps>
nice news, I could test it on weekend
<jannau>
works with the touchbar display m1n1 experiments, not sure if there is much to test otherwise
<jannau>
can't recommned it as video player though
<ChaosPrincess>
you can grab that
<ChaosPrincess>
lol
<jannau>
is it expected that there's sometimes a white stripe at the top above '4' during bad apple?
<ChaosPrincess>
i dont think i clear the framebuffer memory, so aside from the actual part that shows the video, the rest is mostly garbage data
<jannau>
it's black but over the the 4 is sometimes a row of white pixel of various lenght
<j`ey>
can someone take a pic of it?
<ChaosPrincess>
oh, on mine it shows snow on half the screen for the first 10-ish seconds and then goes black
i509vcb has quit [Quit: Connection closed for inactivity]
<kettenis>
jannau: the original idea was to append the cpio to the m1n1+u-boot+dtbs boot.bin on the ESP
<kettenis>
but the grub initrd behaviour makes that unattractive
cylm has joined #asahi-dev
<marcan>
jannau: we don't want to touch DCP for integrated panels, I don't think it's even safe to do that with an active framebuffer (e.g. might break backlight aging management)
<marcan>
DCP does a *lot* more magic stuff with integrated panels
<marcan>
even whatever state iBoot leaves it in might not be that safe long term, it's unclear, but we've been sweeping that problem under the rug for now; hopefully we'll promote DCP to primary driver soon so we can stop worrying about that
<jannau>
j`ey: I'll make a video once the playback experience is improved
<j`ey>
jannau: cool, ty
lewurm`` has quit [Ping timeout: 480 seconds]
lewurm`` has joined #asahi-dev
<marcan>
kettenis: I'm fine with the initrd approach, idea was to just have a subset of firmware in there for u-boot use only (we can make the installer do that)
<marcan>
we just need something to drop that from the device tree before handing off
<kettenis>
dropping it from the device tree is a bit tricky
<kettenis>
since drivers are probed lazily in u-boot and we don't want to drop an initrd loaded by the user in u-boot
<kettenis>
I suppose I could stash the location of the initial initrd and remove from the device tree early