02:41 <bamse> steev: i rebased the backlight friday, and it seems to work fine, just need to double check that i had resolved Uwe's feedback

02:42 <steev> <3

02:42 <bamse> robclark: i used obs-studio, running on the c630...but i apparently didn't have venus enabled in my build, so it was all software encoded

02:43 <bamse> robclark: i suppose hw encode should work, if nothing else i think it will be a good thing to test :)

02:44 <bamse> steev: i also picked up a usb-c pd debugger dongle thingie, so together with the displayport patches from the flex i will take a look at it again

02:44 <bamse> steev: so that we could close the battery^Wec driver

03:17 <robclark> bamse: ahh, I was looking at obs-studio.. which seems to be using sw encode.. which is actually ok on lazor (does ffmpeg have hw encode?) but I had to resurrect a WIP branch to use cached-coherent buffers with GPU because CPU readback of writecombine GPU buffers wasn't great

03:18 <robclark> also seems like hotkeys doesn't really work with wayland

03:24 <bamse> robclark: not sure about the encoder side, given that i hit that point 3 days after the deadline to submit the video...

03:25 <bamse> robclark: the one problem i had is that due to the screen size i had one workspace with the slides in fullscreen - that i pointed obs to...and then another one with the presenter notes

03:25 <bamse> robclark: and as a side effect the slides wouldn't update as i jumped through the presenter notes

03:25 <bamse> robclark: so every slide change is accompanied by me jumping back and forth between the two workspaces...

03:26 <robclark> heh, I'm not actually sure what the deadline is for XDC, but I guess since it starts Wed, that I'm cutting it a bit close

03:26 <bamse> robclark: not sure if that's a wayland thing or xwayland

03:26 <robclark> yeah, I think I'm going to have to do the same thing for speaker notes

03:27 <robclark> fortunately I have plenty of chromebooks lying around

03:27 <bamse> that said, i was really happy with obs...definitely going to play around more with that

03:27 <bamse> will try to enable venus and see if that affects the encoding

03:28 <bamse> hehe, i think y'all saw the third attempt of me recording my talk ;)

03:30 <bamse> had it not been for me getting it recorded last minute i really liked the pre-recorded thing and just being able to hang out in the chat answering questions, much calmer than doing it live like last time

03:30 <bamse> so next time i'll try to get it done a few weeks early and then just relax

03:31 <robclark> because I wasn't paying attention to timezone at the time, my talk is 6:45am.. and live option involves being awake an hr earlier.. so I think pre-record is the only option

03:31 <bamse> :)

03:33 <bamse> i still need to figure the whole video editing thing out, because i would like to make some sort of demo of the progress on the flex 5g

03:33 <bamse> all the cool kids at youtube makes it look so easy...

03:35 <robclark> heh, yeah.. I suppose that would be useful

14:33 <gwolf> bamse: I am not much at ease with asking for progress while unable to push for it myself, but...

14:34 <gwolf> Do you know if there is any progress (or do you expect to have it) WRT display port in the C630?

14:34 <gwolf> It seems I'll go back to in-person teaching by January... and I'd really like to avoid lugging my old, b0rken laptop with me :_(

14:35 <bamse> gwolf: there's no update on that

14:35 <gwolf> OK. Any low-hanging fruit a non-kernel-hacker can try to help with?

14:36 <bamse> gwolf: i haven't done much concrete work on the c630 displayport side, so i will try to flush out what i have pending first and then get back to it

14:37 <bamse> gwolf: but i certainly would like to land it before you get back to school :)

14:37 <bamse> :)

14:37 <gwolf> I have no idea on what is needed to help in any way...

14:39 <bamse> to give you some details, i was digging through the acpi tables and managed to figure out (and confirm by hacking the battery driver) that the embedded controller does (at least some) negotiation for display...at the time i didn't have usb altmode support in the displayport driver, but that is now resolved (hoping to post the patches in the coming days)...

14:40 <bamse> whether that's all of it or not, we'll have to see once i plug it together

14:40 <bamse> but there's at least some things that needs to happen in the EC driver...and with that figured out, i can submit the battery driver as well

14:45 <gwolf> OK!

14:45 <gwolf> FWIW, the C630 has an IMO quite good battery driver support

14:46 <bamse> gwolf: regarding things to help hack on, i'll deferr that to steev or shawnguo, i unfortunately don't have a good picture of the overall system at this point :/

14:46 <gwolf> I mean, it does report battery level and future outlook..?

14:46 <gwolf> OK!

14:46 <bamse> gwolf: yeah, but that driver isn't upstream yet

14:46 <gwolf> OK, I see.

14:47 <bamse> gwolf: landing that and the backlight patch should allow you to run the arm64 kernel that comes from the distro...rather than relying on the one we're building

14:47 <gwolf> right, that's something very much wanted (in the med/long run)

14:47 <bamse> gwolf: and for my installation that predates our debian install that would be quite nice

15:09 <steev> well, the debian kernel itself will need a lot of changes, there isn't much by way of qcom support in there

15:09 <steev> i threw together a quick hack, but... it doesn't work

15:09 <steev> https://salsa.debian.org/steev/linux

15:10 <gwolf> Well, AIUI the Debian kernel team does its best to deviate as little as possible from the Torvalds Linux...

15:10 <steev> well, yes and no :) there are definitely things in the defconfig that aren't in the debian kernel for arm64

15:12 <gwolf> I will have to accept your word for it :-] It must be a decade since I last compiled a kernel that I later used in "production"

15:12 <steev> though, there are probably things in our distro_defconfig that aren't in the defconfig as well

15:13 <steev> afaiui, shawn took the debian arm64 kernel config and then layered the snapdragon stuff on top

15:17 <steev> i am pretty sure my config options are all the changes we need, but i'm not sure how to get the modules into the initramfs properly - i tried loading in all of them that are loaded once it's booted via adding them to /etc/initramfs-tools/modules and... that 100% does the wrong thing for some reason

15:20 <broonie> gwolf: The not deviating from upstream is more about the code than the .config, the defconfigs upstream aren't things we expect people to use in production.

15:20 <broonie> The whole point with the config options is that there's no one reasonable value

15:21 <gwolf> right, I understand that broonie -- I meant it (maybe I didn't phrase it correctly) for things like the battery driver, that I understand is a code addition

15:21 <gwolf> but I don't know if the device trees count as code or config additions

15:22 <steev> in general, the debian kernel peeps don't want to accept anything if it's not at least in -next

15:22 <broonie> The whole idea with DT is that it can be distributed completely independently of the kernel.

15:22 <gwolf> steev: right, matches my recollection

15:22 <gwolf> broonie: in theory at least... but I understand that happens very seldom

15:22 <steev> the lmh driver should be in -next "very soon now(tm)"

15:22 <steev> the backlight stuff should get pushed by bamse soon

15:23 <steev> the battery driver needs to be reworked, but we have one that kinda sorta works good enough(tm)

15:23 <steev> but it wouldn't be accepted by debian for sure right now

15:23 <broonie> gwolf: depends which boards you look at.

15:24 <steev> most people just run the dt that comes with whatever kernel they're running

15:24 <gwolf> steev: Right. I guess I'm more savvy than most people, and I don't play DT

15:24 <steev> if i want to test a dt change, i usually compile it, then just copy it over, and load it via "devicetree" in the grub config

15:24 <broonie> Assuming the board has a DT upstream...

15:25 <gwolf> not with the RPis, not with the C630...

15:25 <steev> broonie: fwiw, the only one i know of that maybe doesn't.... is the apm mustang?

15:25 <robclark> We've *mostly* managed to keep backwards compat for dtb (ie. newer dtb works with older kernel), but I think there have been some breaks.. on simpler boards distributing dtb separate from kernel is perhaps easier

15:26 <steev> but i haven't powered mine on in a few months

15:26 <steev> gwolf: the c630 is dt, so you better learn yourself :P

15:26 <broonie> steev: People doing custom systems mostly aren't upstreaming stuff, nor are any of the phone vendors for example.

15:26 <steev> broonie: sure, that's arm in a nutshell

15:27 <broonie> It's the intended way for DT to be used though, allowing people to do that is a feature.

15:27 <broonie> Same way the servers all use their shipped ACPI tables rather than the kernel packaging a bunch of ACPI.

15:27 <gwolf> Oh, I know it's a point I should learn about...

15:27 <gwolf> ...but as a wise creature once said, "ad hoc, ad loc et quid pro quo. So little time. So much to know!"

16:22 <bamse> steev: on c630, which i2c device does actually represent the keyboard?

16:27 <steev> on mine, it seems to be... i2c-11?

16:28 <steev> 11-005c

16:28 <bamse> seems reasonable

16:28 <steev> gwolf: would you mind checking yours? there are some slight hardware differences between the one i have and the one you have

16:31 <gwolf> of course, I'll go fetch it. Please tell me how to do so!

16:32 <steev> the easiest way, sudo dmesg | grep i2c then look for the one that says it's a Keyboard

16:34 <bamse> so it's the touchpad that's on i2c3?

16:35 <steev> looks like it here

16:35 <steev> and touchpad is on i2c-5

16:35 <steev> er touch screen*

16:35 <bamse> but i thought we had 2 different keyboards, but it's i2c3 that has the two different devices

16:36 <steev> probably 2 different touchpads

16:36 <steev> not uncommon

16:39 <gwolf> I have my keyboard on (...)/i2c-11/11-005c/0018:6243:0001.0003

16:39 <steev> and touchpad is i2c-3?

16:39 <gwolf> mouse and touchpad in -3, yes

16:39 <bamse> cool, thanks

20:30 <steev> bamse: what is the "proper" subject for a patch that modifies the c630 dts? i see sdm845, sdm850, sdm850-yoga and c630 being used

23:20 <steev> bamse: re: https://patchwork.kernel.org/project/linux-arm-msm/patch/20210829131305.534417-12-dmitry.baryshkov@linaro.org/ - do you happen to know if the c630 is the same? i know Uffe wants changes, but for giggles, I applied the series here, and then wrote up a patch for the c630, and also added in the second channel, based on the db845c numbers, and nothing seems to blow up (and both wifi and bluetooth do work)