15:15 <bamse> steev, shawnguo: have you managed to make any progress on the question of why my touchpad is gone 90% of the time i open the lid on my c630?

15:21 <steev> bamse: i have not, because i don't experience it here very often; i plan to start suspending mine more often now, but i kind of use it to build my arm images since my build server is broken and they (ovh) won't give me any kind of updates

15:24 <gwolf> bamse: I have not had any such issue, my C630's trackpad is quite reliable

15:24 <gwolf> am currently running with steev's 5.14

15:24 <gwolf> and I basically always suspend it

15:29 <bamse> it seems better if i hit the disable touchscreen button before suspending, but it might just be wishfull thinking

15:29 <bamse> and i do get input events out of the kernel, just not out of libinput...

15:30 <steev> what version of libinput?

15:32 <bamse> 1.19.1-1

15:34 <steev> that's what i have here, and 1.1.0 for the xorg driver

15:35 <gwolf> I am also running with 1.19.1-1

15:35 <gwolf> FWIW, I don't use Xorg; I found the C630 works *way* better under Wayland

15:35 <gwolf> (am using sway)

15:37 <steev> i wonder if maybe we need some sort of quirk for libinput

15:39 <bamse> gwolf: same here, we had some graphics glitches last year that made me give up on X

15:40 <bamse> steev: there must be something happening in libinput for it to decide to stop processing the input events

15:40 <bamse> steev: but userspace is hard...

15:41 <gwolf> bamse: Well, I've never dug into any other space... :-] There are rumors there is a kernel underneath, but I cannot tell for sure

15:43 <bamse> gwolf: if only it was a kernel issue, then i would know what to do...

15:44 <gwolf> bamse: I would love to be the least bit of help getting better support for the C630, but TBH I am completely lost trying to know where to poke

15:45 <gwolf> I mean, I've read a bit into the device trees, and have somwhat grokked the structure of the dtb we have in the upstream kernel

15:45 <gwolf> but I would not know where to start to try to add anything -- as I have said, I'm interested in having external HDMI support

15:45 <gwolf> Are there any pointers you suggest I could follow to try to get some light into the issue?

15:50 <bamse> gwolf: there's dsdt code that is used to retrieve and send typec altmode events to the kernel and then i have patches for displayport and qmp to get the signal out - which was determined to be completely wrong...

15:50 <bamse> gwolf: but after reworking the DP support for 8cx i will give this another try

15:51 <gwolf> right. Well, starting from the kernel side, I stopped short because I cannot find the kernel to "say" anything when I plug/unplug my adapter

15:51 <bamse> gwolf: the only problem is that there's a reference to an i2c bus from the GPU node in acpi...and i don't know the purpose of that one

15:53 <bamse> gwolf: iirc you will get a message in the some-battery driver, which we today don't handle, but that contains the typec mux and orientation as well as HPD status notification

15:53 <gwolf> where do you get those references from? I mean, I know the kernel does very little to try to map or find hardware

15:53 <bamse> gwolf: so the only wildcard in this mess is that i2c device, which i think is a PD controller...

15:53 <gwolf> DP, I guess you mean?

15:53 <gwolf> It's not out of schematics, I guess...?

15:53 <bamse> gwolf: i read the dsdt and experimented

15:54 <gwolf> OK... So at least I started at the same place, but gave up much earlier (-:

16:39 <steev> bamse: yeah, i just need to re-patch upower so it properly recognizes when AC is plugged/unplugged

16:39 <steev> really, i need to set up my own apt repo with all my custom packages

16:40 <steev> ideally we would have a proper battery driver ;) but this is a decent enough workaround

16:48 <steev> hm

16:48 <steev> rc6 gets hangry when the audio doesn't work

16:52 <steev> bamse: can you pass this on to srini? https://paste.debian.net/1215891/

16:59 <bamse> steev: consider it passed

17:32 <steev> thanks :)