the_lanetly_052 has quit [Ping timeout: 480 seconds]
Lightsword_ has quit []
Lightsword has joined #asahi-dev
Telvana has quit [Ping timeout: 480 seconds]
mps has quit [Ping timeout: 480 seconds]
mps has joined #asahi-dev
trouter has quit [Ping timeout: 480 seconds]
trouter has joined #asahi-dev
bps3 has joined #asahi-dev
kov has joined #asahi-dev
<jannau>
sigh, I don't know what should blame more. dcp iboot or my dell UP2414Q. 3840x2160 and 1920x1200 are the only modes which can be set in m1n1
<jannau>
the iboot allocated frame buffer on the m1 ultra is however only large enough for 1920x1080
<jannau>
setting 1920x1200 with an too smalll fb seems to crash dcp in an interesting way. display scanout still works and nothing stops it on hdmi hotplug
<jannau>
so the display still works after display power switch / hdmi unplug / replug
bisko has quit [Read error: Connection reset by peer]
EdwinMoradian[m] has joined #asahi-dev
Telvana has joined #asahi-dev
<VinDuv>
so you mean… we can avoid HDMI hotplug issues by intentionally crashing DCP? :D
<VinDuv>
btw I’m a bit surprised that DCP iBoot only gives you two modes, on my mini I get many modes including some not supported by the monitor (like 4K modes on a 1080p monitor)
<jannau>
I get 47 modes, those two modes (ignoring the refresh rate) are the only modes that work
<jannau>
and I haven't tested any modes below 1280x720
<VinDuv>
ah I see. Weird that 1080p doesn’t work then
<jannau>
the monitor seems to blame. seems to be an timing or power safe issue. other modes work shartly after powering the display on or if the display is initialized
<jannau>
s/shartly/shortly/
<jannau>
there seems to be a problem dcp shutdown in m1n1. without RTKIT_SYSLOG dcp crashes quite often on shutdown when the display didn't turned on, I haven't seen that with RTKIT_SYSLOG yet
nathanchance_ has quit []
nathanchance has joined #asahi-dev
winter has quit [Read error: Connection reset by peer]
winter has joined #asahi-dev
clee has quit [Remote host closed the connection]
Telvana has quit [Ping timeout: 480 seconds]
<jannau>
"fixed" by setting the mode twice with 2000 ms delay
<jannau>
there's nothing in the syslog messages indicating the first mode set did not work. the second modeset apparently reset the hdmi connection
<jannau>
RBEP_SHUTDOWN for dcp iboot can apparently block the mailbox send for ~33 us while m1n1 still receives syslog messages
<jannau>
not sure if it blocks only (that long) because the display is uninitialized or if there are otherwise no syslog messages
Telvana2 has joined #asahi-dev
Telvana has quit [Ping timeout: 480 seconds]
axboe has quit [Remote host closed the connection]
<VinDuv>
jannau: I guess your monitor would work with https://github.com/AsahiLinux/m1n1/pull/183 since it waits between stage1 m1n1 setting the mode and stage2 setting the mode
<VinDuv>
But it’s annoying that so many monitors have different behaviors
<jannau>
yes, it's annoying. it might already work with chainloading although it's probably too fast. so #183 would allow me to add a delay before the second modeset
<jannau>
I wasn't able to test that since the missing syslog ack blocked dcp
<jannau>
the trigger is that there is an un-acked syslog message when the display did not came up. it's not there if the display is initialized
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
psykose has quit [Remote host closed the connection]
psykose has joined #asahi-dev
___nick___ has quit [Ping timeout: 480 seconds]
<jannau>
so it's indeed the same issue I see with the linux dcp driver. the display disconnects after the modeset