10:33 <Woutervanh> continuation of my quest, I have dual display running (actually ignoring the ptn3460. It's just doing it's thing now, might need some polishing afterwards). Now I have 2 outputs (eDP-1 and LVDS-1) running. Both showing weston background or terminal. But is there a way nog to address an output? Let's say I want to put my weston-terminal on eDP-1?

10:33 <Woutervanh> now it's also showing on LVDS-1

10:43 <qschulz> Woutervanh: yes

10:43 <qschulz> https://man.archlinux.org/man/weston.ini.5.html#OUTPUT_SECTION

10:44 <qschulz> vaguely remember doing it, not entirely sure if I'm misremembering, I don't have a lot of devices with multi displays

11:03 <Woutervanh> qschulz, thanks. Running kiosk-shell + specifying app-id fixed it

11:22 <mmind00> question all around ... can I interest someone to take a look at https://lore.kernel.org/lkml/20250220234141.2788785-2-heiko@sntech.de/T/#m30f8da8e776199564a663dca94b4ead4f4b24d74 and possible provide a reviewed-by?

11:22 <mmind00> While that is touching the DRM driver, the change itself is pretty small and self-explanatory I think ... but drm-rules encourage getting a Reviewed-by ;-)

12:02 <CounterPillow> mmind00: sure, what's the ideal platform to test this on and the ways I can try and reproduce the original problem? I assume RK3399 and just looking closely at serial while having a monitor plugged in and doing a few reboots? Currently in the middle of some RK3576 clock wrangling but maybe I'll have some time tonight

12:28 <qschulz> CounterPillow: not sure but I vaguely remember splats when forgetting to attach a DSI display and rebooting

12:38 <mmind00> CounterPillow: just insert a return -EPROBE_DEFER into the rockchip_drm_bind() [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/rockchip/rockchip_drm_drv.c#n141]

12:39 <mmind00> CounterPillow: then boot and do a poweroff or reboot

12:41 <CounterPillow> mmind00: kk, thanks. Will try that tonight

12:41 <mmind00> CounterPillow: thanks a lot :-)

13:02 <CounterPillow> No worries, this is in the shared rockchip drm code so I can log it as part of the RK35xx work and briefly escape the ALSA mines :D

13:17 <mmind00> CounterPillow: ALSA-mines :-D

20:13 <CounterPillow> mmind00: does this look like the right splat I'm reproducing? https://0x0.st/8A7Y.txt

20:29 <CounterPillow> mmind00: alright, managed to reproduce it and apply the fix and confirm the fix is working and also reviewed the very small diff which seems to sensibly work around the problem

21:08 <mmind00> CounterPillow: yep, that was the "expected" result :-)

21:08 <mmind00> Thanks for testing and the tags

21:12 <CounterPillow> First spent an hour shaving a yak (<https://en.wiktionary.org/wiki/yak_shaving>) to get the comfy boot-kernel-and-initramfs-fit-over-http setup I've got going on my Sige5 to also get up and running on my ROCK5B but now that it is I should quickly be able to do future test runs like that

21:13 <CounterPillow> (in my ideal world, the rootfs would be fetched over the network too, but Linux gets weird when your initramfs is your rootfs and just a Debian rootfs in a trenchcoat. Maybe in the future I'll set up NFS or NBD or something)

22:05 <mmind00> CounterPillow: I've heared that yak-shaving at some point before :-) ... I'm running all my boards as fit-(kernel,initramfs)-over-tftp and Debian as rootfs on nfs ... in the stylish Ikea-Ivar-boardfarm I built in 2016 :-D

22:06 <mmind00> at Fosdem they had this talk of usb9pfs ... https://fosdem.org/2025/schedule/event/fosdem-2025-6103-usb9pfs-network-booting-without-the-network/

22:07 <mmind00> but then past experience tells me that usb-gadget support most of the time takes way more work than getting some network ;-)

22:08 <CounterPillow> Yeah lol, was about to say