10:07 <Tooniis[m]> lumag: gtk4 apps are most problematic but it happens elsewhere

10:07 <Tooniis[m]> it's been the case since around 6.1

10:46 <ungeskriptet> Can someone take a look at https://lore.kernel.org/all/20230723190725.1619193-1-davidwronek@gmail.com?

12:31 <Marijn[m]> ungeskriptet: for Sony we name our DTS `<soc>-sony-<board>-<device>.dts`, should it perhaps be named `sm7125-xiaomi-miatoll-joyeuse.dts`?

12:32 <Marijn[m]> e.g. adding the miatoll name in there?

12:34 <Marijn[m]> Hmm it seems that other xiaomi / oneplus devices didn't really have a board name (let's assume they use the same board for all devices on the same SoC), and use `<soc>-<vendor>-common.dtsi` + `<soc>-<vendor>-<device>.dts` instead...

12:52 <ungeskriptet> Yeah the board name is unofficial

12:53 <ungeskriptet> The custom ROM community decided to name it like that

12:53 <ungeskriptet> mi + atoll

12:53 <JIaxyga[m]> <Marijn[m]> "Hmm it seems that other xiaomi /..." <- They commonize no more than two or three devices in fact

12:54 <Marijn[m]> ungeskriptet: ah okay, thanks! Then maybe this should follow the `-common.dtsi` + `-<device>.dts` pattern

12:54 <Marijn[m]> At least Sony has official, known board names

16:17 <Tooniis[m]> <JIaxyga[m]> "They commonize no more than..." <- msm8996-xiaomi-common will be used by up to 5 devices. 2 remain up to this point

16:18 <Tooniis[m]> but yes, there is no official common board name

16:18 <Tooniis[m]> not one that is published at least

16:20 <JIaxyga[m]> Tooniis[m]: We try to stick to the same idea on sm7150 (Not upstream yet). 4/6 devices have been tested and can be submitted soon:

16:20 <JIaxyga[m]> https://github.com/sm7150-mainline/linux/tree/next

17:00 <aka_[m]> 8953 xiaomi also should get commonized at some point(already in msm8953-mainline)

17:00 <aka_[m]> and i would like to start spliting 8953 motorola into shared to before adding One support

17:01 <aka_[m]> konradybcio: how are you with adding msm8953-pm8953?

17:01 <aka_[m]> This soc never used any other PM and Qcom document outline intended usecase for each regulator

17:03 <konradybcio> every pmic has such outlines btw

17:03 <aka_[m]> then why duplicate stuff in multiple devices

17:04 <aka_[m]> tho camera regulators are often quite board-specific

17:04 <aka_[m]> konradybcio: at this point i guess everyone have noticed

17:04 <aka_[m]> still why noone acted yet

17:06 <aka_[m]> Tooniis: do you have audio accessory support over tusb320?

17:06 <aka_[m]> i wonder how hard would be getting leeco to output music over it, it can either mux headphones or digital signal

17:06 <aka_[m]> i believe adapter is getting recognized via tusb320 and then analog lines are getting muxed

17:35 <Tooniis[m]> aka_: no

17:36 <Tooniis[m]> i dont think the driver supports it yet

17:36 <Tooniis[m]> i dont believe tusb320 itself can mux the analog lines either

17:36 <Tooniis[m]> there should be something else that does that

17:37 <Tooniis[m]> tusb320 only affects the type of port announced to the other end

17:37 <aka_[m]> i guess CC lines aren't supported now

17:40 <Tooniis[m]> > 7.2.3.1 Audio Accessory... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/gfDxKbUyhplUOFWDPanlnsVV>)

17:41 <Tooniis[m]> basically tusb320 only detects connection of audio accessory

17:41 <Tooniis[m]> then you do with that info what you want