08:03 <rkjnsn_> I've seen lots of discussion about handling the speaker safety daemon crashing, getting killed by a signal, getting bad data from alsa, et cetera. Just wanted to call out the cases of the process hanging or getting sent SIGSTOP to make sure they don't get forgotten.

08:07 <chadmed> if the kernel driver is expecting some signal from the daemon and will enter a safe mode when it doesnt get that signal then we shouldnt have to worry about any sort of signal handling beyond gracefully exiting and writing to the syslog that we exploded

08:11 <chadmed> the nice thing is that the driver chips have a safe mode that doesnt screw with any of the "normal" controls, so we can put the codecs into that mode if the daemon dies and it wont mess with any mixer settings

08:12 <chadmed> it attenuates any input by 18 dB which is functionally equivalent to setting the mixer controls to 50

08:17 <rkjnsn_> Cool. Just wanted to make sure there was consideration for cases when the process doesn't die or close the alsa device, but merely freezes.

10:06 <jannau> sven: do you any pending dcp/dptx dp-altmode changes? it looks to me like that is one source of the flakyness. dptx seems to take much longer than macos and it gets confused if the display timeouts during initialization

10:16 <sven> I only have some changes to do the typec subsystem stuff correctly

10:17 <sven> haven’t had much time due to restructuring at $work

10:20 <jannau> ok. I've seen atcphc-20221130. typec seems to work well enough as long as dp is connected after booting

10:21 <jannau> just want make sure I don't duplicate work or create conflicts in dptx

10:22 <sven> I have some wip commits to also make it work correctly when connected before booting

10:22 <sven> but that’s also typec changes only

10:22 <sven> feel free to hack on dptx ;)