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
nick_ has left #asahi-dev [#asahi-dev]
kesslerd_ has quit [Quit: Konversation terminated!]
kesslerd has joined #asahi-dev
stipa is now known as Guest7513
Guest7513 has quit [Read error: Connection reset by peer]
stipa has joined #asahi-dev
kesslerd has quit [Remote host closed the connection]
barrett has quit [Ping timeout: 480 seconds]
barrett has joined #asahi-dev
kesslerd has joined #asahi-dev
kesslerd has quit []
eiln has quit [Remote host closed the connection]
eiln has joined #asahi-dev
systwi has joined #asahi-dev
systwi_ has quit [Ping timeout: 480 seconds]
zef_ has joined #asahi-dev
zef has quit [Ping timeout: 480 seconds]
barrett has quit [Ping timeout: 480 seconds]
barrett has joined #asahi-dev
chip_x has joined #asahi-dev
chipxxx has quit [Ping timeout: 480 seconds]
barrett has quit [Ping timeout: 480 seconds]
<marcan>
oh god I'm testing this on an M2 Air and this is so broken
<marcan>
plasmashell fails to start half the time and stays like that, even if restarted
<marcan>
it segfaults
<marcan>
I can't debug it with gdb because gdb is *also* broken (known upstream bug, fixed in main)
<marcan>
meanwhile the kwin blur glitches are horrible but not only that, sometimes I get cursor redraw glitches even with blur disabled which tells me there is a deeper problem
<marcan>
I suspect half of this is bugs unrelated to us but I am not patching random KDE packages and we know we can't upstream anything to ALARM
<marcan>
jannau: how practical would it be to get cursor planes into dcp? that would at least alleviate the worst of the kwin issues I think
<marcan>
and I need to track down this segfault mess
* marcan
compiles gdb...
<marcan>
at this point I'm half tempted to just throw the towel on ALARM and switch to Fedora and get everything sorted out there, I know I can get this stuff fixed on short notice
<marcan>
the cursor redraw glitches go away at 100/200% so this is totally yet another kwin fractional scaling bug... sigh.
<marcan>
and gdb still crashes... wtf.
<marcan>
aaand the fix the bug was closed by did not fix it
<marcan>
I guess I'm bisecting gdb now...
<marcan>
segfault is in Qt... sigh... gdb 12.1 works and 13.1 fails.
c10l57 has joined #asahi-dev
c10l5 has quit [Read error: Connection reset by peer]
<jannau>
marcan: we need a solution to deal with a partially off-screen cursor. I want to try if I can get away with adding 32 pixels to the stride and map it between a transparent page. that should give us 31 pixels transparency horizontally/vertically to work around dcp's limitation
<jannau>
that depends on unmanaged iommu domains, I don't want to rush that
<jannau>
we can of course also deal with it by copying the visible part of the cursor to a shadow buffer if it is partially offscreen
<jannau>
ugly but not hard to implement
<marcan>
ah right, the partial cursor issue. argh.
<marcan>
jannau: it doesn't work using the source x/y box to offset it?
<jannau>
I don't follow. inpractice we have the issue at the bottom and right screen edge so source x/y are always 0
<dottedmag>
a stupid question: if it's RGBA (it's RGBA, right?) can we play with w/h/stride of the buffer to tell DCP that the plane is exactly the size to fit on screen (and thus effectively hide the part of buffer that'd be rendered offscreen)
<jannau>
marcan: sigh, the surface limitations are biting us as well surf[2] doesn't overlay on surf[1] (with our current code), surf[1] on top of surf[0] does but uses overlays the background as well
<marcan>
jannau: and cropping w/h at src box doesn't work for that case?
<marcan>
or is this a min plane size thing when w/h drop too low?
<jannau>
dottedmag: the issue is that dcp expects an overlay to have at least 32x32 pixels on screen, if not it starts scaling the overlay
<dottedmag>
ugh, ugly
<marcan>
urgh okay
<dottedmag>
jannau: So this is also a problem for small cursors, not only partially off-screen ones, right?
<jannau>
dottedmag: default curser fb size is 64x64 independently of the cursor size
<jannau>
lol, I found a solution for the bottom edge. I can display the cursor offscreen as long as src and dst rect have a width of at least 32x32
<jannau>
a, my code is broken, I think that should work for the right edge as well
<jannau>
no, that trick doesn't work at the right edg
<marcan>
:(
<jannau>
also we can't support a2rgb10 cursors, which kde uses. I was under the impression that the cursor fb is supposed to be argb32
chadmed has quit [Remote host closed the connection]
<jannau>
marcan: btw, I have see no issues with plasma/wayland on alarm with asahi-dev
<marcan>
jannau: this is random, it's particularly bad on my M2 Air for some reason
<marcan>
plasmashell just dies on half the logins
<marcan>
as for kwin, the non-integer scaling artifacts got a lot worse recently
chadmed has joined #asahi-dev
<marcan>
now cursor redraws leave garbage behind
<marcan>
this=0x3f sigh
<marcan>
this is some... heap memory manager... collecting stuff from the javascript stack?
<marcan>
if this is another page size thing...
<ChaosPrincess>
in case it matters - i can also confirm cursor redraw leaving garbage in a square-shaped patter around cursor on plasma. didnt report it at first cause running gentoo, not arch, but apparently its not just my distro being broken.
<jannau>
maybe related to the pick boxes I see on kde login on m2, but I've never seen a crash
<marcan>
nah, the pink boxes are probably the gpu driver still missing sync
<jannau>
cursor leaves square artifacts on the panel but nowhere else
<marcan>
it does that on random surfaces for me, including title bars sometimes
<marcan>
it's not consistent
<jannau>
I see have cursor artifacts pretty consistently on the panel but nowhere else with fractional scaling
<marcan>
maybe it only happens without plasmashell running (which is the state I'm in right now)
eiln has quit [Quit: Page closed]
<chadmed>
ChaosPrincess: i try very hard to not release broken garbage so whatever state gentoo is in is what is going on in asahi
<chadmed>
unless you dont use the overlay in which case youre on your own i guess
<chadmed>
the only cursor artefacts ive noticed is occasionally a thick black outline appearing around it but it seems completely random
<ChaosPrincess>
i have a smashed together install with some packages from overlay and some from my own weird scripts, but iirc mesa is overlay
<marcan>
sigh... valgrind doesn't repro, libasan just deadlocks (??)
<jannau>
have you tried booting with arm64.nobti / arm64.nopauth to rule out bti/pac issues if you're testing fedora? I suppose valgrind doesn't support that
<marcan>
this is alarm
<marcan>
and I think it is a race of some sort
<marcan>
somehow pipewire is involved in the deadlock with asan
<marcan>
and gettext
<marcan>
why is everything so broken
<jannau>
strange that I don't hit that on the mbp 13" m2
<marcan>
if it's a race it's probably going to depend on nonsense like how big my taskbar is and what widgets I have on it
<marcan>
how the hell is gettext deadlocking, who is holding this lock?
<dottedmag>
why there is a lock in gettext anyway
<dottedmag>
maybe something else is screwed up and it's not gettext?
<marcan>
maybe, or maybe gnulib locks are broken on M1 because reasons
<marcan>
this is getting ridiculous
<psykose>
wouldn't surprise me re gnulib
<psykose>
could be the classic "m1 is so o-o-o even gnulib is broken"
<marcan>
ok wtaf this is a pthread mutex under the hood and as far as I can tell it is unlocked and locking it deadlocks
<marcan>
is glibc broken now too?
<marcan>
... and I just realized ALARM is shipping glibc 2.35 while their PKGBUILD is at 2.37-2
<marcan>
this is going great.
<psykose>
does it magically fix itself if you build 2.37?
<marcan>
good question
___nick___ has joined #asahi-dev
<jannau>
kwin ctm night color fixes are merged and should be in the upcoming 5.27.3
<marcan>
now it's starting to look like someone unlocks an already unlocked lock
<marcan>
gettext bug?
<marcan>
wait, not sure
<marcan>
okay no it's just asan
<marcan>
the asan hooks end up with it doing a rlock -> (asan) -> wlock -> wunlock -> (out of asan) -> runlock sequence I think
<marcan>
which is illegal
<marcan>
and this all happens because it tries to dlsym... swift_demangle??
<marcan>
... which should only happen for things that look like Swift symbols??
<marcan>
which is things that start with _T
<marcan>
... and there is a _TLS_MODULE_BASE symbol
skipwich has quit [Remote host closed the connection]
skipwich has joined #asahi-dev
___nick___ has quit []
bisko has joined #asahi-dev
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
<marcan>
jannau: QV4_MM_AGGRESSIVE_GC=1 *may* help repro the issue
<marcan>
this is some messed up javascript type confusion thing or something...
<marcan>
sigh, and now hardware watchpoints don't work properly?
ChaosPrincess has quit [Quit: WeeChat 3.8]
<marcan>
(and software is too slow here...)
ChaosPrincess has joined #asahi-dev
Mary6 has quit []
<jannau>
marcan: reproduced with QV4_MM_AGGRESSIVE_GC=1
Mary6 has joined #asahi-dev
<marcan>
and the bad value is in the JS stack
<marcan>
I might just punt this to upstream
<marcan>
jannau: consistently?
<jannau>
yes, with startplasma-wayland from a tty, plasmashell crashes consistently, starts as expected without QV4_MM_AGGRESSIVE_GC=1
<marcan>
ok yeah, repro'd on M1 Pro
<marcan>
this is just broken everywhere depending on when GC runs
<marcan>
I'll file a KDE bug
<marcan>
(though it might be a Qt issue)
<marcan>
let me see if I can repro this on a random Arch amd64 system
nyilas has joined #asahi-dev
<jannau>
reproduced on fedora 37 on m2
<marcan>
does not repro on amd64 :/
<marcan>
what bugs me here is this *could* be a random memory corruption issue
<marcan>
but I just can't get the gdb watchpoint stuff to not suck
<marcan>
sigh
<marcan>
I think this is another gdb bug...
<marcan>
I think if you set a watchpoint and it gets hit by "dc zva", it hangs
chadmed_ has joined #asahi-dev
chadmed has quit [Read error: Connection reset by peer]
<marcan>
and "stp" also...
<jannau>
have you tried lldb?
<marcan>
ok, it's a JIT bug
<marcan>
I worked around it with a ridiculous number of automated breakpoints to skip over the problem areas
<marcan>
the write of the bad value occurs in what pretty clearly is JIT code
<marcan>
let me see if I can do this again in a less stupid way...
<marcan>
ok, WTF, this JIT code is calling a function then immediately storing a caller-preserved register into the stack
<marcan>
did they get the ABI wrong?!
<marcan>
ok, I think we are shipping QV4_FORCE_INTERPRETER=1
<marcan>
that makes it work and it's not that slow
gladiac is now known as Guest7557
gladiac has joined #asahi-dev
<jannau>
ABI allows to return more 8 byte directly so x1 could be part of the return value. the rules for function arguments apply to return types as well
<marcan>
jannau: the problem is x9 getting clobbered
<marcan>
see toot
<jannau>
yes, I overlooked that, the x1 looked unusual as well
Guest7557 has quit [Ping timeout: 480 seconds]
<marcan>
jannau: the fedora repro, was that on qtdeclarative-5.15.8?
<marcan>
5.15.8-1.fc37 I assume
<marcan>
jannau: the really nasty kwin stuff goes away with plasmashell running, probably by accident
<marcan>
so we can prooobably punt on that as long as we at least disable blur by default because that is very broken
zef has joined #asahi-dev
<jannau>
marcan: yes, 5.15.8-1.fc37
zef_ has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
c10l57 has quit []
c10l has joined #asahi-dev
<jannau>
marcan: plasmashell is slow with QV4_MM_AGGRESSIVE_GC=1 but the patch seems to fix the segfaults
tobhe_ has joined #asahi-dev
<kettenis>
all the world's x86 linux ;)
tobhe has quit [Ping timeout: 480 seconds]
<marcan>
jannau: yes, it's supposed to be slow as heck with that
<marcan>
pushed another asahi-configs bump to disable blur by default in kwin
<jannau>
kettenis: u-boot patches sent, should I have cc-ed Tom?
<kettenis>
jannau: see it; does this diff actually fix booting linux or does it merely prevent a (very annoying) warning?
<kettenis>
(the apple pcie diff I mean)
<jannau>
kettenis: it avoids the warning and prevents the disabled root ports from being discovered. i.e. it restores the observed pcie setup to having the ports deleted from the dt
<jannau>
the lmb max region change fixes booting, the issue was that there was no lmb region for the uefi binary
<kettenis>
The 2023.4 release is around the corner, and already has the number of lmb regions bumped to 16
<kettenis>
I'm basically asking whether we should push for these changes to be included in 2023.4 or not
<jannau>
16 is should be ok for now, pcie is mostly cosmetical and releng has pcie disabled anyway. no need to rush any of the two patches
gladiac is now known as Guest7571
gladiac has joined #asahi-dev
<kettenis>
thanks; hopefully this will be merged into the next branch or merged onto master early in the 2023.7 cycle
Guest7571 has quit [Ping timeout: 480 seconds]
veeyee has joined #asahi-dev
bisko has quit [Read error: Connection reset by peer]
bisko has joined #asahi-dev
leftas has joined #asahi-dev
Leftas7 has quit [Ping timeout: 480 seconds]
pranav has joined #asahi-dev
bisko has quit [Read error: Connection reset by peer]
amarioguy has joined #asahi-dev
nyilas has quit [Remote host closed the connection]
barrett has joined #asahi-dev
nyilas has joined #asahi-dev
pranav has quit [Quit: Connection closed for inactivity]
MajorBiscuit has quit [Ping timeout: 480 seconds]
barrett_ has joined #asahi-dev
barrett has quit [Remote host closed the connection]
<amarioguy>
maz: heads up running those pmuv3 tests now
amarioguy has quit [Remote host closed the connection]
veeyee has quit [Quit: Leaving.]
amarioguy has joined #asahi-dev
<maz>
amarioguy: great, thanks. let me know when you have something!