00:20 <enyalios> is it possible to control the keyboard backlight or the mute led from in the OS

00:20 <enyalios> i dont see anything in for either in /sys/class/leds

00:22 <anthony25> On certain laptops it's handled by the EC

00:24 <enyalios> the EC?

00:24 <enyalios> oh sorry i have an x13s

07:19 <steev> no you can't enyalios, and yeah, it's as far as we know, controlled by the ec. some work has been done to try to understand it, but as far as i know, its still incomplete

07:20 <steev> https://github.com/SoMainline/linux/commit/c0cc2c60177a33597c33586bfe27b5f440e36745#diff-a54aa3c7bfa1118237e7d2825cde96ccf1471e6420289aee2c71631d621b85a0

07:21 <steev> there is however, an x1e ec that someone submitted and it may be possible to use that as a base

09:05 <anthony25> enyalios_: embedded controller, there's a controller that handles keyboard backlight and LEDs, and it's not individually exported in sysfs

17:16 <JensGlathe[m]> It was probably the NIC that made my Sanpdragon DevKit instable. It was semi-stable with 1G transfer mode, but really flakey with 2,5G - resetting the whole device. The NIC is an odd one, RTL8125 on an M.2 2242 B+M key card, including isolation transformer on card. Now it's just an RTL8153 USB adapter, seems stable again.

20:48 <alexVinarskis[m]> robclarkperhaps a silly question, in which tree shall I find `msm-next`? You mentioned that one of my patches for LTTPR didn't apply cleanly, and I should rebase. Just checked, applies on both latest `linux-next` and `drm-misc-next`. Only `msm-next` I found is 2month old, so i guess I got the wrong tree

20:57 <robclark> alexVinarskis[m]: https://gitlab.freedesktop.org/drm/msm/-/commits/msm-next?ref_type=HEADS .. but that should also be merged into linux-next

20:58 <robclark> in which case I'll have to double check what I have in my local branch that isn't in linux-next

21:09 <alexVinarskis[m]> robclark: Indeed, does not apply, it seems `msm-next` is quite a bit behind. v2 applies, in v3 i rebased on `drm-misc-next`/`linux-next` since it was newer, as correctly pointed out by Dmitry.

21:11 <robclark> maybe something touching msm dp code was merged via some other tree.. msm-next is intentionally behind drm-next but should normally be ahead or current for msm code other than patches merged via some other tree

21:13 <alexVinarskis[m]> https://lore.kernel.org/all/20250324-drm-rework-dpcd-access-v4-2-e80ff89593df@oss.qualcomm.com/

21:13 <alexVinarskis[m]> this seems to be missing/breaking change

21:14 <robclark> hmm, ok

21:16 <alexVinarskis[m]> yup, with that series applied LTTPR series also applies cleanly

21:16 <alexVinarskis[m]> I guess, I should leave v3 as is then? since `linux-next` is ahead, and respinning just to collect r-by/t-by would be unnecessary noise

21:18 <robclark> yeah

21:18 <robclark> are you still seeing ordering issues? Ie. it mattering which order you connect ports?

21:21 <alexVinarskis[m]> Did not test yet, don't have Yoga myself, need to borrow it again, maybe next week. Didn't have that issue on XPS nor Zenbook though.

21:22 <robclark> hmm ok

21:24 <alexVinarskis[m]> I think it was something on my side though, since it worked for you. Like I mentioned, for that test I used new dtb, but still Ubuntu Concept kernel, which iirc is/was still on 6.14, that may explain it. Jens Glathealso did not have issue with using all three video outputs on devkit sequentially.

21:29 <alexVinarskis[m]> just tried on Asus Zenbook A14: HDMI, Type-C, Type-C - all three worked as well.

21:30 <robclark> ok

21:55 <craftyguy> Has anyone successfully booted the x13s to el2 with slbounce using the 6.15-rc kernel? it seems to hang at "exiting boot services" for me