08:31 <apple-corps[m]> I think ubuntu desktop uses sddm or gdm3 and it's generally a login option from the display manager to start a wayland session. On my vivobook s15 x1p wayland crawled due to a lack of gpu driver and I switched to i3 and the laptop is much more usable.

08:34 <apple-corps[m]> I should say gnome 3 crawled. And other wayland compisotors just didn't work... (sway, hyprland)

08:34 <apple-corps[m]> It was the expose like transitioning effects that were terrible. And I couldn't find a gnome tweak that actually disabled them. Much happier with i3 regardless...

11:30 <krzk> tobhe: all previous mainline kernels (rcX) were working. Only switch to v6.14 breaks things, so I suspect it does not properly detect version/ABI.

12:20 <JensGlathe[m]> Sound is up on ThinkBook 16

12:26 <JensGlathe[m]> interestingly, the sound keyboard controls work

12:26 <pengyu[m]> If one driver is probed twice, I want to make two instances know/access each other, Is setting a global list a reasonable method?

12:27 <pengyu[m]> I am not familiar with related API

12:29 <krzk> Pengyu[m]: no, it is not. If we speak about DT platforms, then instances knowing each other mean you have hardware conenctions, so this mus tbe explained in DT.

12:30 <krzk> And DT then will provide you necessary links (phandles).

12:35 <pengyu[m]> I see, thank you, krzk. My device has two i2c backlight ICs, they are supposed to be written simultaneously.

14:15 <krzk> tobhe: I know why flash-kernel fails... this dumb scripts compares machine name, which CHANGES, e.g. t14s got renamed. This makes no sense - the name of the machine is not the ABI.

14:15 <krzk> The compatible is and script is supposed to read compatible. All kernel updates for people relying on flash-kernel will be risky/broken whenever upstream decides to do anytihng in the machine name (and we do change there) :/

14:17 <JensGlathe[m]> flash-kernel is both boon and bane

14:35 <krzk> tobhe: and I think when you update your Ubuntu kernel to newer mainline you will hit it as well. I guess flash-kernel needs new machine name to support both old and new, but the best would be to rewrite it to use actual ABI - so the compatible.

14:38 <krzk> bryanodonoghue: you asked for some tests, so your patches cherrypicked on top of v6.14 johan's branch result in probe errors:

14:39 <krzk> bryanodonoghue: https://pastebin.com/WU20ezpa

14:45 <krzk> bryanodonoghue: also after looking at your commit 8f52ee38396 "Fix the regulators consistent with schematic for ov02c

14:45 <krzk> and looking at schematics I have these should be: L4, L2 and L7 (so the second list). At least that's clear on the schematics, but of course not sure if the schematics are common to all models.

16:58 <krzk> bryanodonoghue: just checked now - I need for ov02c10 on my t14s l2, l4 and l7, so like the schematics suggested

19:24 <tobhe_> krzk: urgh makes sense yes

19:32 <tobhe_> flash-kernel has been the default way to deal with dtbs on Debian and derivatives but I'm hoping to eventually replace it entirely with automatic dtb selecting on every boot rather than doing that only in the installer

19:44 <JensGlathe[m]> could be overridden I hope, with explicit dtb= parameter

19:49 <alexVinarskis[m]> tobhe_: doesn't selecting on boot require _all_ device trees to be installed to `/boot`? With ~140KB per dtb, few variants per model (LCD vs OLED etc), times all the models out there (growing fast), times a few... (full message at <https://matrix.org/oftc/media/v1/media/download/AQ75acz3EOVJwIJdtGzzy7QPzC6F4ZSCAiNZPzjKHgaEOUjC1W-Fo6ClKloD3EMaOZ4LI8Tm5SLuII7HQ2agAkVCeWVL_OCwAG1hdHJpeC5vcmcvYnB5c2tQZ1Vnc1JSUUl3YXJHdVJOcmxw>)

19:52 <alexVinarskis[m]> <JensGlathe[m]> "Sound is up on ThinkBook 16" <- With some guidance from Jens Glathe, sound is working on Asus Zenbook A14 too, speakers/MICs/jack

20:11 <steev> alexVinarskis[m]: it's only ~25MB :P

20:12 <steev> the device trees only need to be in /boot if the rootfs is encrypted

20:12 <steev> oh, but it's a live iso, and can't read from the squashed rootfs huh

20:13 <JensGlathe[m]> Live ISO has its merits, and way too many drawbacks

20:15 <steev> well live/installer

20:15 <steev> i mean, the general recommendation has usually been an efi partition of about 300MiB, so 74MB of dtbs doesn't seem like that much of an issue

20:16 <alexVinarskis[m]> steev: Ubuntu concept'kernel's dtbs add up to 68MB, just checked. Another ~75MB for initrd+vmlinuz. Sure its still fine, 'few GB' boot partition solves _today_. Just wondering how scalable it is long term.

20:16 <alexVinarskis[m]> I hope most people would have it

20:16 <alexVinarskis[m]> > the device trees only need to be in /boot if the rootfs is encrypted

20:17 <alexVinarskis[m]> s/'/ /, s/75MB/65MB/

20:17 <alexVinarskis[m]> s/'/ /, s/75MB/120MB/

20:17 <tobhe_> alexVinarskis[m]: that number is way higher than it would have to be though. we currently copy all of qcom I think

20:18 <steev> well most people are going to just have the 1 on their install

20:18 <JensGlathe[m]> you're also booting other platforms, so why select in qcom

20:18 <steev> this is the x1e concept image i think they are meaning, not in general

20:19 <tobhe_> correct

20:19 <JensGlathe[m]> thinking of a future-safe (if not proof) solution

20:19 <tobhe_> because the auto dtb loading hackery was never needed for anything non qualcomm so far :)

20:21 <tobhe_> I do hope that the number of desktop devices that require manual dtb management by the OS does not grow to infinity

20:21 <tobhe_> there are a few other things that don't scale well such as figuring out the smbios mapping

20:21 <JensGlathe[m]> well, technically it won't

20:24 <tobhe_> hopefully not even to a point where the dtbs make the size of an iso or boot partition explode

20:34 <erebion3421EPVPN[m]> steev: I just get an empty content back.

20:34 <erebion3421EPVPN[m]> wc -l /sys/class/power_supply/qcom-battmgr-bat/uevent

20:34 <erebion3421EPVPN[m]> 0 /sys/class/power_supply/qcom-battmgr-bat/uevent

21:13 <steev> can i see your dmesg output?

21:16 <erebion3421EPVPN[m]> steev: https://pastebin.com/t8QpGEmu

22:02 <steev> Direct firmware load for qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn failed with error -2

22:03 <steev> your firmware seems to be missing

22:06 <steev> maybe that's in the initramfs though; there's a file you can poke in /sys to start it manually - echo "start" > /sys/class/remoteproc/remoteproc0/state

22:07 <steev> does that start it up?

22:07 <steev> might need to do that with remoteproc1 as well

22:07 <steev> erebion3421EPVPN[m]: ^