boardwalk has quit [Quit: Ping timeout (120 seconds)]
boardwalk has joined #asahi-dev
ivy_[m] has joined #asahi-dev
user974[m] has joined #asahi-dev
lowz[m] has joined #asahi-dev
M0x8FFshulkk[m] has joined #asahi-dev
eeao^ has joined #asahi-dev
the_lanetly_052__ has joined #asahi-dev
roxiun[m] has left #asahi-dev [#asahi-dev]
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
akamizu[m] has joined #asahi-dev
<dottedmag>
FWIW, what needs to be done in KMS driver so that compositors can handle it (TL;DR: provide fake EDID, as it ended up in uABI): https://paste.debian.net/plain/1240762
<dottedmag>
marcan: Does display controller really hide EDID from the CPU? I remember you talked about it, but I may have missed something in meantime
* maz
watches the Studio updating macos at a glacial speed... thank fsck this is the last time I'll see that.
<maz>
(update failed... good stuff)
<_jannau_>
dottedmag: weston / kwin work without problems with the WIP dcp drm/kms driver
<j`ey>
maz: you jinxed it
<_jannau_>
I'm not sure the data is completely hidden, we might just not yet found it
<maz>
j`ey: I'll put it out in the bin... ;-)
<j`ey>
maz: I run a bin collection company, whats your address? :P
<_jannau_>
dottedmag: the dcp co-processor reports modes which we report to userspace
<psydroid[m]>
I see your experience updating macOS on Apple hardware is about as good as mine in QEMU :)
<_jannau_>
dottedmag: I think dcp reports all necessary information. make, model and serial number are reported as properties (not parsed atm). Timing and colorimetry modes as well
Lucy[m] has joined #asahi-dev
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<maz>
_jannau_: what's the best way to get started on the t6002? the "old" way (install m1n1 by hand and bootstrap the whole thing), or the Asahi installer?
<dottedmag>
_jannau_: yeah, shouldn't be too hard to expose. It is unfortunate that it has to be packed into fake EDID though
the_lanetly_052___ has joined #asahi-dev
<_jannau_>
maz: the installer needs trivial changes to work and an updated m1n1 checkout
<_jannau_>
so you would have to build it yourself
<maz>
building m1n1 is easy. it's the installer itself I'm unsure of.
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<_jannau_>
building the installer itself is not hard either. It builds however m1n1 with chainloading which requires bleeding edge rust
<j`ey>
the main thing the installer does is make the partition, but if youre not going to use macOS (dual boot) and you're not using the internal disk, maybe it's not so useful? it does firmware stuff, but you can do that manually too
<arnd>
maz: I meant just to get you started with setting up user space. Once it works in the VM, you can obviously boot the same kernel natively from proxyclient, and then move to u-boot the last step. I found the vm proxyclient to be super helpful just getting started when not following the normal install
arti1208 has joined #asahi-dev
<maz>
arnd: oh, I have a full userspace ready to be plugged in (my Mini is the donor system). I used proxyclient until about 8 months ago, at which point I switched to u-boot. I now have u-boot correctly probing USB, so it is only a matter of building the kernel, dumping it on the Mini's FS, and moving the disk over.
<maz>
_jannau_: I'm really tempted to stick that counter reset in u-boot itself! :D
nicolas17 has joined #asahi-dev
<arnd>
maz: makes sense. I wasted a ton of time just finding the right kernel config. I had started with arm64 defconfig and then turned on stuff one option at a time, which meant a lot of reboots until I had something working ;-)
<arnd>
I still want to eventually turn on all those options in mainline, so I can just build a defconfig kernel and not think about it much, but there is not much point until enough drivers are there
<sven>
_jannau_: wait, if I have a newer iboot I can no longer forcibly reset this thing because I’m too lazy to issue a real reboot?
<_jannau_>
sven: linux resets the counters on boot
<sven>
I’m not running the asahi branch
<sven>
and even if I was right now there are times where it serrors very early because if this tbt mess
<sven>
*of
<_jannau_>
then you will have to reselect the m1n1 partition every ~10 resets as startup disk
<sven>
*sigh*
<sven>
guess I’ll be careful to not update iboot then
<maz>
this is going to be super annoying, as the box will be in a rack with no way to interact with it other than the serial console...
<_jannau_>
I was tempted to add the boot_error_count reset optionally to m1n1
<maz>
+1.
<sven>
I’d very much like that
<maz>
100% in favor.
<maz>
just make it optional.
<sven>
yes
<nicolas17>
add a remote actuator for the power button like AWS did for their Mac EC2 instances :D
<maz>
nicolas17: for a number of reasons, I don't want to do *anything* like AWS does... :-/
<nicolas17>
lol
<_jannau_>
it would not help at all with the problem
<nicolas17>
ah you'd need a full *graphical* console to select the boot partition again?
<_jannau_>
yes, it boots into macos recovery
<maz>
_jannau_: do you have to select dual mode for DWC3 to work? or host? I have the former in my kernel config, and the ports don't seem to get detected...
<jannau>
maz: I think so, host breaks iirc due to typec interaction
<maz>
jannau: OK, so I'm missing something else.
<jannau>
which kernel? if upstream it's missing support for the iommu variant? otherwise do you have CONFIG_TYPEC_TPS6598X ?
<maz>
jannau: using your t6002 branch. I have this module, but the controllers themselves don't seem to appear, and it is like the driver never really probes them.
<maz>
feels like a missing dependency.
<jannau>
i2c
<maz>
CONFIG_I2C_APPLE=y
<maz>
and I see a bunch of cd321x devices hanging off the i2c bus.
<maz>
ah, I can finally feel a bit of heat coming from the box! :D
roxfan has joined #asahi-dev
<maz>
4:17 for a full debian kernel. not bad. I think I'm limited by the I/O here. already 30% faster than my current box, with only a fraction of the CPUs.
rdltromw^ has quit [Remote host closed the connection]
Telvana2 has joined #asahi-dev
Telvana has quit [Ping timeout: 480 seconds]
yuyichao_ has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
jakebot has joined #asahi-dev
jakebot has quit []
jakebot has joined #asahi-dev
tanty has quit [Remote host closed the connection]
tanty has joined #asahi-dev
Telvana2 has quit [Ping timeout: 480 seconds]
ricekot has quit [Quit: Connection closed for inactivity]
<Eighth_Doctor>
marcan, svenpeter: so I know that linux-5.18 is coming up in a couple of weeks, I was wondering if you folks would be so kind as to be willing to prepare a branch off the 5.18 tag with the remaining non-upstream Asahi stuff that exists so far?
<Eighth_Doctor>
that way I can cherry-pick it all onto the Fedora kernel tree once we start our 5.18 rebase
<Eighth_Doctor>
for the kernel-asahi package I'm working on
<j`ey>
Eighth_Doctor: the current branch is based on 5.18rc4