00:01 <bamse> HdkR: if you get v_level reached maximum printout in log, you have the cable upside down...

00:02 <bamse> HdkR: but even when linux is happy, one of my tvs claims there is no signal at 4k resolution...performing a mode switch to 1080p brings picture

00:02 <bamse> it's a recent regression, but i've not found the time to debug it

00:45 <Dylanger> Hi all! This still working? Also thank you to Collabora for bumping mt8195-tracking-master-rolling 👍️

01:07 <HdkR> bamse: arandr didn't even show anything connected so I think it is a different issue sadly

01:13 <bamse> HdkR: nothing useful in dmesg?

01:14 <bamse> HdkR: do you have battery status?

01:19 <HdkR> uh, let me check, just got back home

01:22 <HdkR> So one hub I have shows up as a USB hub, but no logs about the HDMI port on it.

01:25 <bamse> with a monitor connected i presume?

01:25 <HdkR> yea

01:25 <bamse> and do you have battery status?

01:26 <HdkR> How do I check again?

01:26 <HdkR> Another USB hub also just shows up as a USB hub, DP connection on it isn't visible

01:27 <bamse> /sys/class/power-supply/ should have couple of qcom-battmgr-* instances

01:27 <HdkR> and my final hub negotiates a USB hub but now power

01:27 <HdkR> Has four qcom-battmgr folders in it

01:28 <bamse> and "cat /sys/class/power_supply/qcom-battmgr-bat/manufacturer" doesn't fail?

01:28 <HdkR> "No such device"

01:29 <bamse> okay, so do you have the pd-mapper service running?

01:29 <HdkR> I don't have a process called that running according to htop

01:29 <bamse> ENODEV on the battery properties tells us that we don't think the firmware in charge of battery and usb type-c isn't running

01:34 <HdkR> `pd-mapper.service: Start request repeated too quickly.` what

01:36 <HdkR> Trying to manually run it just says `no pd maps available`

01:38 <bamse> you should have some .jsn files in /lib/firmware/qcom/LENOVO/21BX/

01:38 <HdkR> Looks like it tries to parse `/sys/class/remoteproc/` for subdirectories

01:38 <bamse> and that's empty?

01:38 <HdkR> no jsn files in there

01:39 <HdkR> Only mbn

01:39 <bamse> but is /sys/class/remoteproc empty as well?

01:39 <HdkR> Has two folders in there, remoteproc{1,2}

01:39 <bamse> pull battmgr.jsn from upstream linux-firmware and place alongside the .mbn

01:40 <bamse> although it might be unhappy with the lack of adsp*.jsn...

01:43 <HdkR> Looks like I can read the power_supply stuff now

01:46 <HdkR> Oh, looks like display might work on one of my adapters now

01:46 <HdkR> As long as I can fix my other PC with radeon crashing the kernel...

01:47 <HdkR> lol wtf is this random resolution, 2048x1152

01:48 <HdkR> That seems to work, let me check the other adapters

01:51 <HdkR> Other basic adapter works...

01:51 <HdkR> Now the stupid one that breaks things

01:53 <HdkR> lol, this one doesn't even show up as a USB hub anymore

01:54 <HdkR> zero messages in dmesg, and the battery indicator light just constantly blinks

01:57 <HdkR> That's okay though, now I can just disable the internal display and use this other hub

01:57 <HdkR> oooh, it falls asleep when the lid is closed

02:05 <HdkR> https://gist.github.com/Sonicadvance1/dd053cf76448b4946e99ed1d0fff1b77 Maybe a bit unstable

02:08 <HdkR> https://gist.github.com/Sonicadvance1/20cb2e998b2910a0b224664756b29d08 I see, if you disable internal and try to only use external it gets /really/ fucking angry

02:09 <HdkR> and then it never comes back

02:13 <HdkR> Whatever, works well enough for testing purposes

03:06 <bamse> HdkR: is that with closing the lid, or just disabling the eDP output?

05:46 <HdkR> harvestz[m]: That's disabling eDP with only external in use

11:44 <juergh[m]> jhovold: I'm using your v6.2-rc6 branch for the x13s but with my own configs. Sometimes at boot when the console switches it stays blank and never comes back. Only sometimes though. Seems like a timing issues. Is there anything that might need to be built-in rather than a module that could be causing this?

12:25 <jhovold> juergh[m]: i would not be surprised if this is related to the broken msm drm driver

12:26 <jhovold> unless the panel driver is loaded before the msm driver it can end up "probe" deferring during component bind

12:26 <jhovold> it has led to all sorts of issues, most of which have been sorted out but there could be more lurking

12:27 <jhovold> next time this happens, can you check the logs and see if the drm driver probe deferred?

12:27 <jhovold> a workaround is to manually load the panel driver before the drm driver

12:32 <jhovold> that prevents the late component bind failure, which is annoying due to the error messages (that should be kept until the driver has been reworked)

12:34 <jhovold> haven't had any troubles with the driver not recovering when this happens after my drm fixes went in, though

12:37 <juergh[m]> jhovold: panel driver is builtin msm is a module. if I interpret my old logs correctly it looks like the panel driver had problems detecting the panel.

12:38 <jhovold> i have both built as modules, but load them explicitly to avoid the component bind failure

12:38 <jhovold> apparently the pi

12:39 <jhovold> ...panel driver probes after the drm driver with you config still

12:40 <jhovold> # cat /etc/modules-load.d/drm-msm.conf

12:40 <jhovold> # This is enough to avoid the bind "probe" deferral

12:40 <jhovold> panel-edp

12:40 <jhovold> msm

12:43 <juergh[m]> I'll play around with that to see if it helps. Thanks!

15:16 <krzk> :n

19:09 <steev> c440000.spmi:pmic@0:adc-tm@3400 qcom-spmi-adc-tm5: get dt data failed

19:09 <steev> waht am i forgetting, because this is bugging me