Retr0id has quit [Read error: Connection reset by peer]
Retr0id7 is now known as Retr0id
<marcan>
ok, I think we're well overdue for a release. I'm going to write up a progress report.
<marcan>
thinking of releasing the current asahi-dev kernel (which has enough fixes and is otherwise well tested I think), just rebased on the latest -rc
<marcan>
and then merging all the fancy new DCP and USB3/ATC updates and making a linux-asahi-edge or something package (name suggestions? thinking we might want to use something other than "dev" to stop overloads)
cylm has quit [Ping timeout: 480 seconds]
<jannau>
marcan: sounds good. disabling of disp0_dart could be still useful to prevent breaking display scanout for the broken old m1n1 + new devicetree case
<marcan>
jannau: in the DT you mean?
<marcan>
yeah, probably a good idea
<jannau>
it shouldn't be necessary but if people even run into that when actively trying dcp it could prevent some support effort
<marcan>
yeah, sounds good. I might pull it in as an out-of-tree patch in the PKGBUILD. that way I can keep my plan of using the same tree with different configs for different packages.
<jannau>
yeah, it was something like dynamic filling would be required for the calibration data so I can be lazy and don't need to look at the template ADT
<jannau>
yes, user-accessible-max-nits is just on j314/j316 for the desktop vs. HDR max brightness
<jannau>
LmaxProduct is the maximum for HDR. 1600 nits
<jannau>
I'll update kernel and m1n1 PRs tonight accordingly
<marcan>
thanks :)
<marcan>
jannau: calib ended up not being necessary?
<jannau>
no, I suspect iboot does that. the firmware appears to have afk methods for that (judging by strings in the fw)
<jannau>
macos doesn't use those. I still have no idea what those set_block_dcp calls do but backlight control works without them
<marcan>
iBoot has to set the brightness to the one stored in nvram, so it makes sense that it has to take care of calibration
gladiac has joined #asahi-dev
<sven>
I’ll prepare something for usb3/atc. No m2 support unless someone gets the fuses though
<sven>
DP/dcpext is still much too unstable imho
<marcan>
yeah, usb3 would be good to get in soon
<marcan>
doesn't have to be for this release in the main kernel
<sven>
yeah, and that’s pretty damn stable
<sven>
ive been playing around with it the past days and can’t break it anymore
<marcan>
if you think usb3 is good enough to ship that would be nice
<marcan>
we can get it into today's release and at least have people test it 2 days
<sven>
let me prepare something later then
<marcan>
idea is to get everything ready today and ship on thursday if nothing explodes
<marcan>
sven: what do you need for M2?
<sven>
see #asahi-re
<sven>
someone needs to throw a t8112 kext into ghidra and extract like 10 bit locations for fuses
<marcan>
ack
<sven>
unfortunately It’s not a table so it’s a bit anoying
<marcan>
right
SSJ_GZ has joined #asahi-dev
millenialhacker has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
capta1nt0ad has joined #asahi-dev
amarioguy2 has joined #asahi-dev
amarioguy has quit [Ping timeout: 480 seconds]
bisko has quit [Read error: Connection reset by peer]
bisko has joined #asahi-dev
<marcan>
jannau: I'm cherry picking the enable commit for now into m1n1
<sven>
marcan: so I guess the easiest way to prepare usb3 for you to merge is to just base it on the current asahi-dev? it's just a few commits so it shouldn't conflict with anything (revert the old role switch quirk, add the new role switch quirk, add atcphy, add two lines to tipd, device tree updates)
atipls has joined #asahi-dev
<marcan>
sven: sure, I just updated it
<sven>
ok, let me prepare something during this very important meeting :>
<marcan>
:D
<_jannau_>
sven: add the extcon fix, it was not in rc5
<sven>
oh, right!
<sven>
that one should hopefully stick around this time and not get reverted by accident again
<mps>
sven: I've got this warning when build kernel https://tpaste.us/pnPm think it is related to tipd
<sven>
i think that one's marcan's fault :D
<mps>
asahi-wip branch
<sven>
also very harmless
<mps>
right, it works fine
<sven>
it's just about printf format specifiers. the way to get them right is to first just use %d, then compile and let the warning tell you what you should've used
<marcan>
sven: also that doesn't work, you actually need to read printk-formats :p
<marcan>
e.g. size_t is special
<sven>
fair enough
<sven>
paddr_t and friends as well
<marcan>
yeah
<sven>
let me fix that statement above then: the way to get them right for local hacks is to compile and then just use whatever it tells you :P
<marcan>
:p
<marcan>
third kernel build, hopefully this one will work
<marcan>
I'm building two packages, -edge enables DCP and turns the smc/gpio stuff into modules (since that was built in only for simpledrm's backlight stuff)
bluetail has joined #asahi-dev
<marcan>
also both packages get CONFIG_RUST now (though no actual rust drivers)
millenialhacker has quit [Ping timeout: 480 seconds]
<sven>
oh.. you have that other weird tipd irq fix in asahi-wip. let's see, i think jannau had a conflict resolution for that somewhere
<sven>
or I guess I just skip the additional tipd fixes and just do that 2 line mux commit
<_jannau_>
I have a revert for the irq fix. Is yours not in rc5?
<sven>
don't think greg sent the pull request yet
<sven>
but i've just dropped my tipd fix commits for now and will just do a quick change that only does typec_set_mode
<sven>
kettenis_: once you implement it make sure you get the order of what happens in usb3_mux_set and phy_power_on correct
<sven>
you first need to bring up the PHY, then dwc3, then do the pipehandler dance when initializing
<sven>
and when shutting down first undo the pipehandler dance and then shut down the PHY
<kettenis_>
it is unlikely that I'll copy any of the code, but there are so many registers that I may end up copying those bits
<kettenis_>
sven: thanks
<sven>
otherwise it only works sometimes
<sven>
it's very subtle unfortunately and that's the only order that works reliably so far
<marcan>
_jannau_: ack
<sven>
i think you can get away with just switching the phy mode from usb3-only to usb3/dp without shutting down dwc though
<kettenis_>
marcan: did you see my comment about the pmgr registers in the device tree last week?
<sven>
and you may need to do that if you're faster than the tps6598x thingy can negotiate the altmode
<marcan>
kettenis_: I think I missed that
<kettenis_>
pmgr on the 8112 has:
<sven>
drivers/gpio/gpio-macsmc.c: In function 'macsmc_gpio_event':
<sven>
drivers/gpio/gpio-macsmc.c:220:6: error: void value not ignored as it ought to be
<sven>
ugh
<marcan>
sven: already fixed
<kettenis_>
reg = <0x2 0x3b700000 0 0x10000>;
<sven>
ah, let me fetch again then
<kettenis_>
and then ps_disp0_cpu0 has:
<kettenis_>
reg = <0x10000 4>;
<marcan>
oh whoops
<sven>
oh, and I still need to update the tunables format in m1n1. the current atcphy code supports both but I want to move the new format I have to be consistent with the thunderbolt/acio tunables
<marcan>
kettenis_: fixed
<kettenis_>
marcan: I suppose the size of the region should be maede bigger, but I couln't quickly find out what it should be
<marcan>
kettenis_: t8103 has 0x14000 and the same offset for cpu0 so I just used 0x14000
<marcan>
not sure how I ended up reducing it for M2
<_jannau_>
sven: atcphy probing failed with the m1n1 tunable format pull request on t6001, I didn't look into why
<sven>
because I changed the format again and never tested it :D
<kettenis_>
we had an OpenBSD hackathon last week and I made some good progress on implementing "s2idle" for OpenBSD/arm64
<sven>
I’ll just drop the warn_on for now
<kettenis_>
we're also putting the infsrastructure in place to update the stage2 m1n1 from OpenBSD
<rmk>
sven: for printk stuff... if it's size_t, that's unsigned, so %zu. if it's ptrdiff_t, that's signed, so use %zd. the z flag works like l, telling printf to use whatever is the implementation's requirement for size_t or ptrdiff_t
<rmk>
guessing doesn't always work
<sven>
I never though if z as a modifier which is why I could never remember the correct thing for size_t. that makes a lot of sense, thanks!
<sven>
*of
kov has quit [Quit: Coyote finally caught me]
<sven>
bah... and I brought this cheap compile vm on hetzner down again. I should really move to compiling my kernels on the m1 as well
<marcan>
up to 6th try at a kernel tag... sigh
Dcow has joined #asahi-dev
joske has joined #asahi-dev
joske has quit [Remote host closed the connection]
joske has joined #asahi-dev
<joske>
marcan: was brightness control supposed to be in? I just built asahi-wip of 10 minutes ago, and no brightness
<marcan>
no, not yet
<joske>
ah that explains it
<marcan>
I thought you were going to respin that with the data in the DTs?
<marcan>
er jannau I meant
<joske>
thought so ;-)
<joske>
keyboard backlight is working, but when I log into mate (X11), screen is black. Same with xfce. GNOME wayland works
<joske>
GDM login manager
<_jannau_>
is it fixed byt switching to a tty (Ctrl + Option (+ Fn) + F3) and back?
<joske>
no
<joske>
that seems to get me back to lock screen
<joske>
if I enter PW again, same black screen, or bits of mate desktop, but no movement
<joske>
(X11 works with release asahi 5.19 kernel)
<joske>
ah I thought you meant marcan needed to pull that in
<sven>
yes, exactly
<sven>
because it contains atcphy
<joske>
ok, so normal it doesn't work then
joske has quit [Remote host closed the connection]
joske has joined #asahi-dev
<marcan>
can we please stop building random kernels while I'm literally in the middle of a rebase and merge cycle?
<marcan>
it just wastes everyone's times
<marcan>
*time
<marcan>
I haven't even tested it myself, I'm still working out the PKGBUILD stuff for edge
<joske>
sorry I was just trying to help
<sven>
at least we've graduated from people compiling kernels with wrong .config options and then complaining that things don't work and that it must be a bug :D
<marcan>
lol
<marcan>
well that's interesting
<marcan>
crw-rw----+ 1 root video 226, 0 Nov 15 21:03 card0
<marcan>
crw-rw----+ 1 root video 226, 1 Nov 15 21:03 card1
<marcan>
I thought dcp was supposed to take over simpledrm and cause it to disappear, and also where did the render node come from?
<marcan>
I'm pretty sure I haven't merged lina's driver yet
<jannau>
marcan: I think we have vgem built-in in the asahi config
<marcan>
oooooh
<jannau>
or some other virtual device
<jannau>
vkms maybe
<marcan>
well that would do it
<marcan>
vgem yeah
<marcan>
I guess we should just turn that off in -edge
<marcan>
and leave it on in the default one (not sure if it would load as a module?)
<marcan>
heh, display performance really is much worse with DCP. I'm not sure if this is a mode issue or an expensive redraws issue...
<marcan>
okay, so "re-use screen content" in KWin is broken. not sure whose fault that is.
<marcan>
oh wait
<marcan>
60Hz is smooth
<marcan>
120Hz is choppy
<marcan>
lol
<marcan>
no wait, 120Hz is smooth
<marcan>
... or is it
<chadmed>
did you merge "working" EAS by any chance?
<marcan>
120Hz was smooth for a while, then it stopped.
<marcan>
chadmed: you think it's EAS?
<chadmed>
it reliably destroys software rendering performance on my 14"
<chadmed>
without it dcp is smooth in x11 but sucks in wayland
<marcan>
for me dcp is smooth at 60Hz
<marcan>
at 120Hz it starts out smooth but then tends to flip into choppy mode
<marcan>
why do I get the feeling 120Hz is special...
<marcan>
anyway, I'll drop the EAS patches
<chadmed>
unless you picked viresh's fix from linux-pm then EAS wouldnt be registering anyway
<marcan>
don't think I did unless it's in -rc5
<jannau>
marcan: dcp limits the swaps in 120Hz to 60Hz anyway
<marcan>
jannau: it looks to me like it randomly decides to limit the swaps to like 15Hz
<marcan>
I suspect shenanigans, like some other dynamic switching/controls we don't do yet
<marcan>
we might want to hide the 120Hz mode for now
<jannau>
marcan: simpledrm uses a shadow fb and updates only damaged parts. that seems to be much faster
<marcan>
as I said, 120Hz starts out smooth then drops to like 15Hz
<marcan>
that doesn't sound like a rendering/damage issue
<jannau>
also llvmpipe is slow
<marcan>
that sounds like DCP
<marcan>
if it were a rendering issue it would be slow from the get go
<marcan>
and 60Hz is fine
<marcan>
I'm rebuilding without EAS and without VGEM for -edge, but you can try installing linux-asahi-edge from asahi-dev if you want
<jannau>
so you add additional problems since the swap waits randomly
<marcan>
it should coexist with linux-asahi and you get both options in GRUB (make sure to update-grub)
<marcan>
anyway, I should get some dinner :p
<chadmed>
the EM shouldnt register on rc5 anyway since that fix didnt make it in
<jannau>
dcp is slow on large repaints with an external 50 HZ display
<marcan>
that still doesn't explain why it's fast initially and then slow...
* marcan
off to dinner
capta1nt0ad has quit [Quit: Leaving...]
capta1nt0ad has joined #asahi-dev
<jannau>
I'm not sure I see what you see. dcp is choppy on large repaints like moving a large window or maximizing windows but otherwise it is okay-ish
<jannau>
have you looked at the "show fps" desktop effect
<jannau>
I think it is an rendering issue because I don't see any issues in combination with lina's and alyssa's opengl driver
capta1nt0ad has quit []
capta1nt0ad has joined #asahi-dev
<jannau>
bits/000-devicetree and bits/200-dcp are refreshed for backlight control
<jannau>
m1n1 change has only python changes and can wait
<marcan>
jannau: even the mouse cursor is choppy
<marcan>
but it's choppy a few seconds after switching to 120Hz
<marcan>
"show fps" says 60Hz at 60Hz; at 120Hz it actually says more like 90Hz while moving the mouse, but it's actually choppier (both the mouse and the graph) once it triggers
<marcan>
initially it's smooth
<marcan>
when it becomes choppy it's an instant transition
<jannau>
plasma/x11 or wayland? what I said about swap applies only to wayland
<marcan>
plasma/x11
<marcan>
I also don't know why it stutters so badly when e.g. fullscreening a window. there's no way it takes that long to render the single frame where it stalls. something's weird there.
<marcan>
like it stalls for a whole second
millenialhacker has joined #asahi-dev
<marcan>
makes me want to say it's a memory allocation issue with the surface size changing
<jannau>
resizing a window is bad with 120Hz / x11
<marcan>
it's also bad with 60Hz
kazuki has joined #asahi-dev
* marcan
back to dinner
<jannau>
but moving the same window not great but ok
<kazuki>
chadmed marcan: EAS doesn't slow down rendering on my PC
<kazuki>
It's 60hz though
<jannau>
kazuki: I don't think this issue is EAS related
<jannau>
dcp framebuffers are allocated with write combine. I'm not sure 100% if I set the uncached bit in the dart PTEs
<jannau>
resizing windows plasma/wayland is ok
millenialhacker has quit [Ping timeout: 480 seconds]
zalyx has quit [Quit: later alligator]
zalyx has joined #asahi-dev
atipls has joined #asahi-dev
atipls has quit []
<_jannau_>
marcan: not sure what the x11 issue could be but iirc there is not driver <-> dcp communication involved after the initial modeset
millenialhacker has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
joske has quit [Remote host closed the connection]
bluetail has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
millenialhacker has joined #asahi-dev
atipls has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
atipls has quit [Remote host closed the connection]
atipls has joined #asahi-dev
<marcan>
ok, I merged atcphy and backlight, tagged and pushed. doing a build now
roxfan2 has joined #asahi-dev
roxfan has quit [Ping timeout: 480 seconds]
<marcan>
the plan right now is that linux-asahi gets ATCPHY, -edge on top of that gets suspend/s2idle, DCP, and SMC and the chain of RTKit dependencies go y->m due to the removal of simpledrm backlight.
<_jannau_>
I'll look int the dcp x111 performance. I mostly looked at wayland since there's continous communication with dcp
MajorBiscuit has quit [Ping timeout: 480 seconds]
<_jannau_>
first suspect for the atrotious performance is the missing vblank irq
kazuki_ has joined #asahi-dev
<mps>
what version of m1n1 is needed for latest asahi-wip
kazuki has quit [Ping timeout: 480 seconds]
<_jannau_>
1.1.8 but maybe wait
<mps>
fine, I already have 1.1.8, but ofc I can wait
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
<marcan>
_jannau_: merged
<sven>
just in case you didn’t notice: I didn’t add the atcphy nodes for t8112
<sven>
Sounds good otherwise
<marcan>
sven: I did, don't have time to do it myself right now, hoping you get bored enough to do it :>
<sven>
lol :D
<marcan>
it's 2:30AM and my plan after kicking off a build is to take a bath and go to sleep :p
<sven>
sounds good as well
<marcan>
getting one PKGBUILD to build two kernels trying to reuse part of the build and also have them properly installable side-to-side took a bit more work than expected
r0ni_ has quit [Ping timeout: 480 seconds]
<sven>
sounds like my adventures in the typec subsystem. That’s also gonna take more work that expected
<marcan>
what little I saw of that subsystem looked kind of crazy... I guess I wasn't wrong about that.
millenialhacker has joined #asahi-dev
<marcan>
_jannau_: wait, so x11 doesn't do any swaps after the initial one?
<sven>
nope, my current idea about that subsystem is batshit crazy unless I’m missing something
<marcan>
are we sure that's kosher in the general case? there could well be dynamic PSR involved, such that framebuffer updates don't actually make it to the display in a timely fashion
<marcan>
I wouldn't be surprised if 120Hz mode specifically enables that kind of thing...
<sven>
my favorite part is an ops struct that is shared by two separate components. and each of those is really only allow to implement a distinct subset of callbacks afaict. don’t ask me why it’s not two ops struct then
<sven>
maybe there’s a reason for that but that reason is very much not obvious then
<marcan>
_jannau_: also fyi:
<marcan>
/home/marcan/asahi/git/PKGBUILDs/linux-asahi/src/linux-asahi-6.1-rc5-9/drivers/gpu/drm/apple/dcp.c: In function ‘dcp_start’:
<marcan>
/home/marcan/asahi/git/PKGBUILDs/linux-asahi/src/linux-asahi-6.1-rc5-9/drivers/gpu/drm/apple/dcp.c:249:9: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
<marcan>
| ^~
<marcan>
249 | if (ret)
<marcan>
/home/marcan/asahi/git/PKGBUILDs/linux-asahi/src/linux-asahi-6.1-rc5-9/drivers/gpu/drm/apple/dcp.c:251:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
<marcan>
251 | return ret;
<marcan>
that one's been around for a while
<marcan>
just bad indentation I think, maybe it only shows up with my compiler?
<_jannau_>
I need to check but I'm reasonable sure that there is no dcp rtkit traffic. so what I've seen with the window resize shouldn't be a scanout issue. the show fps effect reports a frame rate of 4 fps
<marcan>
I'm talking about the choppiness at 120Hz after a while
<marcan>
the window resize probably isn't a scanout issue, yeah
millenialhacker has quit [Ping timeout: 480 seconds]
<_jannau_>
waarning looks legit to me and I'd it misses braces but doesn't make a difference
<_jannau_>
not sure I've seen the choppiness yet
<marcan>
it reliably starts happening for me on xorg after a while
<marcan>
just pushed another build to asahi-dev
<marcan>
running edge from there on a j314
<marcan>
incidentally, the brightness control looks like nits-linear to me. is it supposed to be? it feels quite lopsided (normally you'd have some gamma applied to get a reasonable brightness curve, but I don't know if Linux has any standards for this)
<_jannau_>
I'll take a look. I've tested x11 only briefly since it looked unintersting
<_jannau_>
yes, it's nits linear and annotated as such. scale is nits
<marcan>
ok, I guess then we can blame KDE for not making it more human-friendly
<_jannau_>
there is no standard and no annotation for the unit
<marcan>
[ 336.387906] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
<tpw_rules>
it's always felt kind of nonlinear in macos
<marcan>
that looks good, though I do get the 5s delay
<tpw_rules>
there's a couple humps in the scale
<marcan>
_jannau_: I get a black screen after suspend/resume, but closing the lid and opening it brings it back. suspect missing backlight restore?
<marcan>
sven: s2idle kills atcphy I think, though a hotplug brings it back
<marcan>
I *think* prior to this usb2 did survive but with a bus reset (xhci still errored out but recovered)
<sven>
hrm, yeah, that’s not surprising
<sven>
usually when you break atcphy either usb2 or usb3 survives
<_jannau_>
for the brightness hotkeys apple uses their marketing table with around 17 entries. those dteps are probably not linear
atipls has quit [Quit: My laptop probably went to sleep.]
<marcan>
right
<marcan>
ok, so basically things are Mostly Breaking As Expected in -edge
<sven>
lol
<sven>
I’ll look into suspend for atcphy after that typec mess for altmode is done
<marcan>
I need to relax a bit and sleep, but I would appreciate testing with both the regular kernel and -edge (available in asahi-dev)
<marcan>
if the regular one is stable with atcphy (sans suspend) and doesn't otherwise regress things, this is releasable this week
<sven>
famous last words but I think at this stage atcphy can always recover with a hotplug in the worst case
<sven>
I haven’t even seen it complain about anything on t8103 in the last days though
<marcan>
oh yeah, keyboard backlight works too :>
<sven>
the most important feature next to backlight ;p
<mps>
marcan: yes, if you need hacky daemon for kbd backlight I can post it
<marcan>
why would I need a daemon? KDE supports it out of the box
<jannau>
mps: kde handles it fine
<mps>
ah, didn't knew
<mps>
probably because I don't use KDE ;)
<jannau>
no usb3 on m2 with linux-asahi, maybe the atcphy .compatible.
<marcan>
jannau: the DT isn't done at all, unless you did?
<marcan>
see < sven> just in case you didn’t notice: I didn’t add the atcphy nodes for t8112
<jannau>
no, I did not
<sven>
marcan did the hard part of finding the fuses
<marcan>
I pasted the fuse bits in -re, needs adding everything else
<jannau>
oh, I misunderstood you
<marcan>
(which might well be a 1:1 copypaste of m1)
r0ni has joined #asahi-dev
<jannau>
I stopped reading after the "I did" and missed that it was for the notice
<sven>
lol
<marcan>
:D
<mps>
hm, no much difference between 120 and 60 Hz refresh rate with xorg on my m1pro macbook
<jannau>
usb3 works on m2 but m1n1 doesn't disable the atcphy on its usb port
<jannau>
seems to be faster than m1 but with 5s delay
MajorBiscuit has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
<sven>
nice!
<sven>
I’ll have to take a look at macOS and see if it also has that 5s delay
<sven>
but I don’t think it does
<sven>
it’s probably something dumb again
as400_ has joined #asahi-dev
as400_ has quit [Remote host closed the connection]
<blazra>
sven: I was trying USB3 by plugging my flash disk to the 14" mbp and in one case it broke. However, replug fixed it. Dmesg: https://paste.debian.net/1260812/. Kernel 6.1.0-rc5-asahi-9-1-edge-ARCH from the asahi-dev/linux-asahi-edge package.
<blazra>
I have to apologize for playing with the brightness setting and therefore polluting the log :D
<sven>
no worries, I can use grep ;)
<jannau>
macos does additional writes on t6001 for DP but it works at least partially without that
<blazra>
I don't know if it's related, but sometimes with the port on the right side I get two of these: "[ 732.609484] phy-apple-atc f03000000.phy: timed out waiting for ACIOPHY_TOP_PHY_STAT_LN0_UNK23"
<sven>
yeah, just saw that
<sven>
maybe t6k actually needs some additional setup to work properly
<sven>
I never saw that on t8103
<sven>
[ 834.513132] xhci-hcd xhci-hcd.0.auto: USB bus 1 deregistered
<sven>
[ 834.513144] xhci-hcd: probe of xhci-hcd.0.auto failed with error -110
<sven>
that really looks like some kind of race
<sven>
oh.. wait
<sven>
nah, it just prints the error from above again
<jannau>
I don't think there was anything unknown for usb3 in the macos atc trace
<sven>
hm
<sven>
there's still that weird ACIOPHY_TOP_BIST_READ_CTRL_LN0_PHY_STATUS_RE behavior I see on t8103
<sven>
guess i'll try hotplugging some usb3 device >50 times tomorrow and see if I can provoke that -110 error
<sven>
still happy that the pipehandler sequence seems to be stable enough to recover even if that lock fails now
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
___nick___ has quit [Ping timeout: 480 seconds]
millenialhacker has joined #asahi-dev
millenialhacker has quit [Ping timeout: 480 seconds]
coutego has joined #asahi-dev
weitcis has joined #asahi-dev
coutego has left #asahi-dev [#asahi-dev]
pthariensflame has joined #asahi-dev
SSJ_GZ has quit [Ping timeout: 480 seconds]
pthariensflame has quit []
pjakobsson has quit [Ping timeout: 480 seconds]
pjakobsson has joined #asahi-dev
millenialhacker has joined #asahi-dev
<jannau>
marcan: I only see choppiness with certain rendering operations (window resize, log out screen, ...) but no issues with the mouse pointer at 120Hz
<jannau>
window resize seems to be render limited. I see very high CPU use due to fast_composite_src_x888_8888() (pixman) when resizing konsole