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
mikelee has quit [Remote host closed the connection]
mikelee has joined #asahi-dev
ellyq has quit [Quit: system poweroff requested]
<marcan>
ah yes, totally forgot about that, thanks!
<marcan>
kettenis: sounds reasonable
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<marcan>
tarzeau: glad to hear that! hope you hang around and feel free to ask any questions :) (I know this stuff is kind of complicated)
<marcan>
cy8aer: kernel dual-boot rollbacks are not (fully) supported when device tree compat breaks happen. this is expected and a limitation we accept. once device tree bindings are upstreamed, they become stable, and this doesn't happen any more.
<marcan>
you still want to pull device trees from the most recent installed kernel, since backwards-compatible changes do happen that are required to support new hardware, and you also often need m1n1 updates to go along with it (though we generally try to keep the m1n1 side also backwards compatible)
jeisom has quit [Quit: Leaving]
jeisom has joined #asahi-dev
ourdumbfuture has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
jeisom has quit [Ping timeout: 480 seconds]
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-dev
cylm has joined #asahi-dev
cylm_ has quit [Ping timeout: 480 seconds]
gabuscus has quit []
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-dev
gabuscus has joined #asahi-dev
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #asahi-dev
bisko has joined #asahi-dev
crabbedhaloablut has joined #asahi-dev
bisko has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
bisko has joined #asahi-dev
leitao has joined #asahi-dev
leitao has quit [Ping timeout: 480 seconds]
tstraus13 has quit [Remote host closed the connection]
bisko has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
sefidel has quit [Remote host closed the connection]
sefidel has joined #asahi-dev
mikelee has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
mikelee has quit [Ping timeout: 480 seconds]
<jannau>
bluetooth seems to be broken on 6.4
mikelee has joined #asahi-dev
<jannau>
oh, the issue is on 6.3.0-asahi-13
mikelee has quit [Ping timeout: 480 seconds]
eiln has joined #asahi-dev
<jannau>
pairing of a logitech mouse persistantly failed with kde's wizard but worked with bluetoothctl on the first try
<eiln>
^same, im on 6.3.0
roxfan has quit [Ping timeout: 480 seconds]
<cy8aer>
marcan: Yes I accept this too and declare this as something we call in german a childhood desease.
<cy8aer>
But with the possibility to rebuild the boot.bin before rebooting into another kernel via "update-m1n1" like in the asahi dists (and not via a packaged and assembled boot.bin we just have with the debian packages) this is a good compromise. And for debian I look for creating a clone of the asahi-scripts and contact @Glanzmann for this.
<marcan>
jannau: that smells like not a kernel thing?
lena has joined #asahi-dev
adryzz has quit [Ping timeout: 480 seconds]
<eiln>
marcan: I have a sw-eng question related to v4l2
<marcan>
I don't know much about v4l2 but go ahead :)
<eiln>
isp processes frames in batches (2 <= n <= 10), so all n frames are bundled up in a single doorbell / interrupt cycle. batch count can differ per cycle, macos usually uses 2 or 3, prolly their timing/scheduling algo
<eiln>
the problem is that it's minimum 2 frames, but I have no guarantees on the number of (user) queued buffers (because they're from users). past the limit (v4l2 max buf count is 32) I can at least split them into sub-batches
<eiln>
from my understanding (limited) the only way to enforce the "at least 2" is by making up a fake format of 2 chroma & 2 luma (...)
<marcan>
oof, yeah, no, that's a bad idea
<eiln>
I can't just hang until the user queues another one, so rn I have a "fallback" second frame under kernel ownership, which wastes half of the work (but it's better than nothing)
<marcan>
hmmm :/
<marcan>
what do you mean by wastes half the work?
<eiln>
batch count is n=2, user queued 1, so the 2nd frame is the fallback
lena has quit [Ping timeout: 480 seconds]
<marcan>
right, but then you could deliver the fallback next time the user pops a buffer?
<marcan>
I think I don't really understand what the problem is
<eiln>
under read_frame in case IO_METHOD_MMAP, the user dequeues a (done) buffer, and enqueues another for processing
<marcan>
right
<marcan>
so the idea is you force the buffer count allocated to always be at least 2 (or 4), and then tell ISP it's okay to deliver 2 frames once 2 free buffers are available
<eiln>
they can dequeue all four at once, then enqueue just one, which leaves me with 1 frame
<marcan>
yeah, so then that blocks
<marcan>
that's a userspace problem
<marcan>
if we find stuff that breaks under that model, we get it fixed :)
<eiln>
It'd be stuck cause userspace polls till dequeue signal
<marcan>
yeah, that's fine
<marcan>
if userspace refuses to give buffers back and waits for a new one, that's its problem
<marcan>
there's a reason there were 2+ buffers to begin with
<eiln>
it's that I need 2 queued, which isn't a requirement anywhere
<marcan>
yeah, but is there any userspace out there that breaks like this?
<marcan>
normally you expect buffers to be dequeued, processed, and enqueued again
<marcan>
without any random blocks
<marcan>
one thing you *could* do is unconditionally always allocate at least 1 more buffer than userspace requested, so that if userspace is trying to allocate some exact number of buffers it wants "in flight", there will always be one extra one in the queue (but userspace could still use too many in that case anyway)
<marcan>
and that looks like exactly your use case
<eiln>
that's only checked once before start_streaming is called
<marcan>
yeah, but it looks like exactly your use case in practice
<marcan>
I think it's perfectly fine to block if there's only one buffer queued
<marcan>
and only submit a request to ISP once you have at least 2
<eiln>
I'll definitely check with userspace
<eiln>
should I bother changing the batch count?
zkrx has joined #asahi-dev
<marcan>
not sure, might be worth experimenting with.
<marcan>
larger batches = more efficient, more latency I assume
<eiln>
yeah, mostly the interrupt/ack dance
<marcan>
fwiw I just checked ffplay and it requests 256 buffers, gets 32, pops 6, then starts alternately queuing and dequeuing, eventually catching up with more queueing (?)
<marcan>
so that would work perfectly fine with your use case
<marcan>
eiln: looks like queue_setup is allowed to do stuff with the buffer count, see e.g. v4l2-pci-skeleton.c
<marcan>
I'm trying to understand how that works, sort of looks like an additional buffer count?
<eiln>
if there's 6 in, I can process 2-6 at once. if i do 6, they'd pop one, and add one. the next dequeue would hang without a way to enqueue
<eiln>
the buf_dq ioctl waits
leitao has quit [Ping timeout: 480 seconds]
<eiln>
** waits for me to process, which I'm blocking
<marcan>
yeah, so you never want to do the full queue size
<marcan>
actually no, if you do 6 why wouldn't that work? they'd pop one, and add one, but there's 5 more left to pop so it won't block
<marcan>
once at least 2 are enqueued again you can fetch another batch (of at least size 2)
<eiln>
ones I process are marked done and out of the queue
<eiln>
delivery/dequeue are the same
<marcan>
I'm lost
<marcan>
if the queue has 6 empty buffers, you request 6 frames from ISP, they come back. you mark all those buffers as full. userspace dequeues one, enqueues it, dequeues another one, enqueues it, etc. until it either runs out of all 6 or the driver decides to ask ISP for more data
<marcan>
where's the deadlock?
<marcan>
eiln: sorry if I'm completely misunderstanding the issue here, queueing shenanigans get hairy :(
<eiln>
marcan: deadlock is the VIDIOC_DQBUF ioctl, which polls for one buf to be processed by the driver
<marcan>
even if there are already buffers ready?
<eiln>
user initally requests all buffers with VIDIOC_REQBUFS. that count I can modify/gurantee. after that, when stream starts, the driver marks the processed buffers and kicks them out of the queue. then those can be delivered to userspace polling with VIDIOC_DQBUF. most processes would use alternating enqueue/dequeue, which for the ISP is NOT 1 but the batch count.
<eiln>
say the reqbufs count is 3. I'd mark two done, leaving me with 1 in the queue. but the user would typically only poll for one dequeue, and (logically) enqueue one more. there's now 2 in my queue, which I'd process both and send off. the user (again) dequeues one and enqueues another, leaving 1 in the queue. they'd hang on the next dequeue because we're not operating on the same
<eiln>
batch count
<eiln>
if i block
<marcan>
but it's not dequeuing empty buffers from the queue, it's dequeueing processed buffers, no?
<eiln>
empty buffers?
<marcan>
let me rephrase your scenario, tell me where I'm confused
<marcan>
reqbufs is 3, you send 2 off to ISP. ISP comes back with that data, you mark 2 code. there are now 2 complete buffers in the queue and 1 empty buffer. user dequeues one of the complete buffers, and re-enqueues it. there are now 2 empty buffers in the queue, which you send off to ISP, and they come back. userspace dequeues one buffer from the processed list, and re-enqueues it. there is now 1 ...
<marcan>
... empty buffer in the queue. the next dequeue it grabs another processed buffer, since you still have 2 of those.
<marcan>
*mark 2 done
<marcan>
like the way I see this there are two queues, one of empty buffers and one of processed buffers, and buffers move from empty to processed under driver control, and from processed to empty under userspace control
<marcan>
is that wrong?
dylanchapell has quit [Ping timeout: 480 seconds]
<marcan>
I think I'm right, one list is q->queued_list and the other q->done_list?
<marcan>
qbuf puts stuff into queued_list, and dqbuf grabs stuff from done_list
<eiln>
I only have one queue, p->queued list. I don't track done bufs. the user has to re-queue it into the queued list
<eiln>
which they can't if I'm blocking on the "one empty buffer in the queue" part
<marcan>
what's p?
<eiln>
typo, ignore
<marcan>
q is vb2_queue
<eiln>
the ioctl behind buf_queue is list_add_tail(&buf->link, &isp->buffers);
<eiln>
that private list is the one I operate on
<eiln>
in the irq I'd do vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_DONE); list_del(&buf->link); for both buffers
<eiln>
the buf being buf = list_first_entry_or_null(&video->buffers, struct aspeed_video_buffer, link);
<marcan>
let me write this up in a gist
<_jannau__>
I don't think there is a problem from my experience writting and reading v4l2 uuser space code
<_jannau__>
user space dequeues buffers as fast as it needs to and holdson to as many buffers as it needs
<_jannau__>
in a typical display scenario 3 buffers are needed. user space needs 1 for display and enqueues it after next was dequeued and is display. the driver has in the mean time 1 frame for processing
<_jannau__>
if the driver needs at least 2 frames for processing the queue size has to be at least for. the driver can enforce that at request_buffers time
<_jannau__>
if if user space needs more buffers, it needs to request buffers. we can add 1 or 2 to that number
<marcan>
basically every time you call vb2_buffer_done those get put into a list, and dqbuf will pull from that list
<marcan>
(as well as remove from the main queued list)
<marcan>
queued_list is "buffers not owned by userspace", isp->buffers is "buffers owned by the device", and done_list is "buffers waiting to be dequeued by userspace"
<marcan>
where everything in either of the second two lists is also necessarily in queued_list
<marcan>
you don't actually block in the driver proper, you just add buffers to isp->buffers until there are enough to submit, and only submit at that point
<eiln>
marcan: give me a few minutes I'll push the branch
leitao has joined #asahi-dev
leitao has quit []
MajorBiscuit has joined #asahi-dev
<marcan>
unrelated note: finally got around to poking SMC from macOS. on an M1 air in screen-off idle, with SSH over WiFi active, PSTR claims 0.2-0.4W
<marcan>
so that's our target for figuring out runtime PM and whatever is eating power
<marcan>
that would be 250 hours of s2idle best case
<marcan>
(at which point I'd be very happy telling people they don't need real s2ram)
<marcan>
PPBR (battery power) is higher but I think that might be a lie, since it doesn't track PSTR well at all
ohmadcs^ has quit [Remote host closed the connection]
<chadmed>
what does PHPC say
<marcan>
0.5
<chadmed>
hmmm ok i think we're a bit higher than that with EAS at the desktop so there might be some gains left on the table in the cpus
<marcan>
Battery PPBR 1.6 W flt
<marcan>
Heatpipe PHPC 0.5 W flt
<marcan>
System Total PSTR 0.2 W flt
<marcan>
honestly those numbers are kinda weird
<marcan>
I'm not sure what PSTR means in relation to PHPC
<marcan>
and >1W going elsewhere doesn't make any sense
<chadmed>
time to scratch up some power planes >:)
<marcan>
I mean we have schematics for some of these things, and plaintext SMC firmware for all the M1s :p
<marcan>
we can find out exactly how all this stuff is calculated
<chadmed>
oh right its not encrypted
<marcan>
it is
<marcan>
but the keys for 13.0beta1 or something got posted
<marcan>
that's how I found that 80% battery charge limiter
<chadmed>
ah ok
<chadmed>
doing those glmark2 runs ages ago really made some of those keys seem like nonsense
leitao has joined #asahi-dev
leitao has quit [Ping timeout: 480 seconds]
<eiln>
marcan: Ohhh
<eiln>
The index of the last dequeued buffer is re-queued
<eiln>
So I can pass on the doorbell until the queue accumulates
<eiln>
fucking hell why did that nearly explode my brain
<dsharshakov>
Does macOS feature some sort of autogain + compressor for that?
<chadmed>
yeah its a bit more than that though, its a lookahead delay with a ramping feature
<chadmed>
im not really entirely sure how it works and its been over a year since i even looked at coreaudio's graph
<dsharshakov>
libebur128 + some modification like EE's one but with inertia (not just holding the level, but ramping it to the new level)
<chadmed>
for all i know it could actually just be overexcursion but if that were the case then it would appear with my 0 dBFS sine wave
<chadmed>
but it doesnt
<dsharshakov>
lookahead? Does it work with anything other than files? Or it just buffers some time ahead?
<chadmed>
its inserted into the dsp chain in macos just like our filter chain works
<chadmed>
its just a coreaudio plugin (audio unit)
<chadmed>
all i remember is kinda speculating as to how it works based on some strings in the obfuscated plists
<chadmed>
and then reading about popping and sudden changes in volumes in the asoc and TI documentation and put the pieces of the puzzle together
<chadmed>
(i actually even managed to get macos to pop once)
<dsharshakov>
does it add latency? is there a way to know whether it's used when RT apps like DAWs do their output with latency-critical params?
<chadmed>
theres a coreaudio preset which gives "raw" access to the output but i would wager this never, ever, ever gets used
<chadmed>
and you cant call it up from anywhere in macos
ourdumbfuture has joined #asahi-dev
<dsharshakov>
so it's likely to be that this AU doesn't have huge buffer
<chadmed>
and i would assume it adds _some_ latency of course but i havent benched or RE-ed any of the coreaudio stack beyond reading strings in plists
<chadmed>
everything ive done has been by ear
<dsharshakov>
does EE (easyeffects) autogain give similar results when you drag the slider after the expected volume change? which content causes this?
<chadmed>
good example is town.mid (the microsoft one) played through fluidsynth
<chadmed>
the bass hits cause the popping above ~70% volume
<dsharshakov>
well, it's certainly not just zero latency, but probably rt-friendly if supposedly used in any scenario
<chadmed>
now that ive started testing on a 13" with different codecs but the same woofers, im leaning towards this being some limitation in the digital side of the codecs
<chadmed>
i can crank absolutely heinous volumes through those and get some very obvious overexcursion but none of this digital-sounding popping noise
<dsharshakov>
we can move to #pipewire, maybe there are some people who could help
<chadmed>
im there :)
<dsharshakov>
maybe it's a D/A side thing, why would TI write else? btw is their doc not confidential?
<dsharshakov>
try to make a recording of the noise as well and put that on PW Matrix
<dsharshakov>
13" Intel Pro uses an HDA codec or something T2-related?
jeisom has joined #asahi-dev
<chadmed>
its a cirrus hda thing, the driver is an out-of-tree monstrosity but it works ~the same as ours does (raw access to the individual drivers)
<chadmed>
anyway re confidentiality, the codecs are just TAS2764 with a different name lasered on to the top
<dsharshakov>
I meant some writeup re volume changes. Is it in datasheet or an article by ti?
<chadmed>
i cant remember where i saw it
<chadmed>
oh its in the datasheet right there
<chadmed>
the chip tries to do it itself to "minimise audible artefacts"
<chadmed>
but it evidently sucks at it
<chadmed>
they have it on the DVC too but we dont touch that
<chadmed>
OH
<chadmed>
oh oh oh
<chadmed>
it _might_ be pipewire
c10l has quit [Quit: Bye o/]
<chadmed>
im not going to run the unconstrained raw output for long because its not pay week this week, but it doesnt _seem_ to happen via the raw output even up to 100%
<chadmed>
so we're either saturating the convolvers somehow (even though the volume isnt indicating anywhere near 0 dBFS anywhere) or something deeper is up
<chadmed>
ive already bypassed the bass thing and the compressor and it just gets worse so im thinking its something in the convolver
<chadmed>
(probably some gain level in the IR pushing that component of the input to saturation)
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<chadmed>
if thats the case ill need to rethink the dynamics processing
chadmed has quit [Quit: Konversation terminated!]
c10l has joined #asahi-dev
chadmed has joined #asahi-dev
leitao has joined #asahi-dev
chadmed has quit []
chadmed has joined #asahi-dev
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-dev
chadmed has quit []
chadmed has joined #asahi-dev
Cyrinux9474 has quit []
Cyrinux9474 has joined #asahi-dev
<dsharshakov>
which branch of the dsp repo do you use?
<dsharshakov>
is it with bankstown in?
<chadmed>
yeah im just rocking main atm
<dsharshakov>
unsure if it will be reproducible with typical hw, but will try
<chadmed>
dont sweat it if its not, i can deal with it now that i have something to work with
<chadmed>
i just have to change where we add the compensatory gain, ill just tweak the dynamics processor to deal with it
<marcan>
kettenis: definitely not off by a factor of 10, that would be too much.
<kettenis>
currently in OpenBSD I'm still above 2 W (according to PSTR) in suspend :(
sid-linux has joined #asahi-dev
<kettenis>
on the M2 air PMVC seems to track the CPU clock frequency
<kettenis>
so that seems to be the power consumed by the cores?
<kettenis>
that is still 1.2 W in the lowest idle state it seems
<marcan>
I think I remember <0.5W on Linux for that?
<marcan>
do you have the deep idle stuff hooked up?
<kettenis>
I do
dsharshakov has quit [Quit: Page closed]
<marcan>
are you sure it's working? and dynticks and all that kind of stuff? the CPUs need to go idle and stay idle
<marcan>
kettenis: also you need to make sure the CPUfreq is set to the lowest pstate when going idle
<kettenis>
I *think* it is working, and when I actually suspend clock interrupts are completely disabled
<kettenis>
of course when I read the SMC one of the E-cores isn't idle
<kettenis>
but I do the read in the SMC power button event handler that wakes up the machine
<kettenis>
with "lowest pstate" you mean the lowest state advertised in the app tables in the DT isn't it?
eiln has quit [Quit: WeeChat 4.0.2]
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
nela has quit [Quit: bye!]
nela has joined #asahi-dev
ourdumbfuture has joined #asahi-dev
mikelee has joined #asahi-dev
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
cylm has joined #asahi-dev
mikelee has joined #asahi-dev
matrix_ds has quit [Quit: Bridge terminating on SIGTERM]
matrix_ds has joined #asahi-dev
matrix_ds has quit [Excess Flood]
matrix_ds has joined #asahi-dev
williamdes-m has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
V--I--P has joined #asahi-dev
MajorBiscuit has quit [Quit: WeeChat 3.6]
V--I--P has quit [Remote host closed the connection]
highvoltage[m] has joined #asahi-dev
mjolnir[m] has joined #asahi-dev
paddatrapper_ has joined #asahi-dev
ahdeb[m] has joined #asahi-dev
tumblingweed has joined #asahi-dev
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
deflated8837 has quit [Ping timeout: 480 seconds]
leitao has quit [Ping timeout: 480 seconds]
mikelee has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
leitao has joined #asahi-dev
leitao has quit [Ping timeout: 480 seconds]
mikelee has joined #asahi-dev
mikelee has quit [Remote host closed the connection]
mikelee has joined #asahi-dev
sid-linux has quit [Ping timeout: 480 seconds]
mikelee has quit [Remote host closed the connection]
mikelee has joined #asahi-dev
MaxxRoach has joined #asahi-dev
hightower2 has joined #asahi-dev
MaxxRoach has quit []
MaxxRoac_ has joined #asahi-dev
Z750 has quit [Quit: Ping timeout (120 seconds)]
Z750 has joined #asahi-dev
MaxxRoac_ has quit [Remote host closed the connection]
mikelee has quit [Remote host closed the connection]
mikelee has joined #asahi-dev
mikelee has quit [Remote host closed the connection]
mikelee has joined #asahi-dev
zalyx0 has quit [Quit: later alligator]
zalyx0 has joined #asahi-dev
zalyx0 has quit []
MaxxRoach has joined #asahi-dev
mikelee has quit [Remote host closed the connection]
zalyx0 has joined #asahi-dev
zalyx0 has quit []
MaxxRoach has quit [Ping timeout: 480 seconds]
MaxxRoach has joined #asahi-dev
WindowPa- has quit [Read error: Connection reset by peer]
WindowPain has joined #asahi-dev
ourdumbfuture has joined #asahi-dev
MaxxRoach has quit [Ping timeout: 480 seconds]
MaxxRoach has joined #asahi-dev
rootbeerdan has joined #asahi-dev
MaxxRoach has quit [Remote host closed the connection]
MaxxRoach has joined #asahi-dev
maximbaz has quit [Quit: bye]
maximbaz has joined #asahi-dev
MaxxRoach has quit []
qyliss has quit [Quit: bye]
qyliss has joined #asahi-dev
MaxxRoach has joined #asahi-dev
MaxxRoach has quit [Remote host closed the connection]
MaxxRoach has joined #asahi-dev
roxfan2 has quit [Ping timeout: 480 seconds]
roxfan has joined #asahi-dev
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ourdumbfuture has joined #asahi-dev
Bey0ndB1nary has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
Bey0ndB1nary has quit []
mikelee has joined #asahi-dev
mikelee has quit [Remote host closed the connection]
MaxxRoach has quit [Remote host closed the connection]
MaxxRoach has joined #asahi-dev
mikelee has joined #asahi-dev
mikelee has quit [Remote host closed the connection]
mikelee has joined #asahi-dev
mikelee has quit [Remote host closed the connection]
MaxxRoach has quit [Ping timeout: 480 seconds]
mikelee has joined #asahi-dev
mikelee has quit [Remote host closed the connection]
MaxxRoach has joined #asahi-dev
MaxxRoach has quit [Ping timeout: 480 seconds]
mikelee has joined #asahi-dev
crabbedhaloablut has quit []
MaxxRoach has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
MaxxRoach has quit [Ping timeout: 480 seconds]
<marcan>
yes
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
MaxxRoach has joined #asahi-dev
mikelee has joined #asahi-dev
MaxxRoach has quit [Ping timeout: 480 seconds]
mikelee has quit [Remote host closed the connection]
mikelee has joined #asahi-dev
jeisom has quit [Remote host closed the connection]
jeisom has joined #asahi-dev
mikelee has quit [Remote host closed the connection]
mikelee has joined #asahi-dev
ourdumbfuture has joined #asahi-dev
MaxxRoach has joined #asahi-dev
jeisom has quit [Ping timeout: 480 seconds]
mikelee has quit [Remote host closed the connection]
ourdumbfuture has quit [Quit: My Mac has gone to sleep. ZZZzzz…]