03:17 <steev> bamse: since i just saw the pull request for 6.16 dts, and it mentions crypto stuff... is anyone doing that work testing with CRYPTO_MANAGER_DISABLE_TESTS not set? Debian's kernel does not have that option set, and it seems (at least with 6.14) i am getting what i presume to be an serror because the system just reboots when qcrypto loads - if i set modprobe.blacklist=qcrypto i can boot

06:37 <JeromedeBretagne[m]> steev: I have seen the same audio input issue within Gnome on x13s, I can't select the built-in mic on Debian testing

06:37 <JeromedeBretagne[m]> (but plugging a 3.5mm headset with a mic works and adds this mic dynamically in the audio input settings which were empty otherwise)

06:47 <SpieringsAE> brandon63: don't know if you're still here, but the x elite asus vivobook is pretty good imo.

06:48 <SpieringsAE> Current issues are: no audio (can be enabled but risks damage), no webcam, but I may want to look into that soonish, because I have been hearing some noise around that starting to come up

06:49 <SpieringsAE> and the hdmi port is a bit funky it works in very specific ways.

06:50 <SpieringsAE> Some stuff is not yet upstream, sd card reader/usb A is heading there with 6.16 I think. Still waiting for bluetooth to be accepted, may need to resend that. And I haven't submitted the dp altmode patch yet

07:07 <JensGlathe[m]> SpieringsAE: I have a package which supports also the Purwa variant of the Vivobook, would like to upstream.

07:38 <alexVinarskis[m]> for the camera on Vivobook: comparing AeoB of Zenbook (https://github.com/alexVinarskis/qcom-aeob-dumps/blob/master/asus-zenbook-a14/CAMF_RES_QRD.json#L103-L142) and Vivobook (https://github.com/alexVinarskis/qcom-aeob-dumps/blob/master/asus-vivobook-s15-s5507/CAMF_RES_QRD.json#L103-L141), as well as sensor model (https://github.com/alexVinarskis/qcom-aeob-dumps/blob/master/asus-vivobook-s15-s5507/SCFG_FRONT_QRD.json#L3) it

07:38 <alexVinarskis[m]> seems they are 1:1 the saame. You could try copy Zenbook patch (https://github.com/alexVinarskis/linux-x1e80100-zenbook-a14/blob/master/0015-WIP-arm64-dts-qcom-support-camera-on-Asus-Zenbook-A1.patch), goes on top of Bryan branch.

07:38 <alexVinarskis[m]> on Zenbook im getting an error I haven't seen on other devices or heard about,  cam_cc_ife_1_gdsc status stuck at 'off'. But the sensor probes and talks just fine.

09:10 <JensGlathe[m]> Of my tree, [6.15.0-rc4-jg-3](https://github.com/jglathe/linux_ms_dev_kit/tree/jg/ubuntu-qcom-x1e-6.15.0-rc4-jg-3) is now pushed and on [GoogleDrive](https://drive.google.com/drive/folders/1Lps5o3FXroAJFDiKj18vutJbC1uld49s?usp=sharing).

09:18 <JensGlathe[m]> What's new:... (full message at <https://matrix.org/oftc/media/v1/media/download/AXA7_FekwG6PxQonEsQ2dlnTnQUXZSXqC8LWj93zERfK4aQkqsEdXCOgwqWb31pxBYZJfmjqnSXdXJrqCNarnFFCeXC-MymQAG1hdHJpeC5vcmcvVm9sT3Zyd2xNU2dvdFlTeUFMVmFtQXRj>)

09:21 <JensGlathe[m]> - also Surface Laptop (Romulus): support for dp Altmode in the dt

10:31 <jhovold> Here's an updated wip branch for the X13s:

10:31 <jhovold> - https://github.com/jhovold/linux/tree/wip/sc8280xp-6.15-rc6

10:31 <jhovold> Changes include:

10:31 <jhovold> - fix cpufreq stuck throttling differently (6.15-rc3 regression)

10:31 <jhovold> - fix gpu throttling boot crash

10:31 <jhovold> - update dp lttpr fixes to v5

10:31 <jhovold> Here's an updated wip branch for the T14s and X Elite:

10:31 <jhovold> - https://github.com/jhovold/linux/tree/wip/x1e80100-6.15-rc6

10:31 <jhovold> Changes include:

10:31 <jhovold> - fix cpufreq stuck throttling differently (6.15-rc3 regression)

10:31 <jhovold> - fix gpu throttling boot crash

10:31 <jhovold> - update dp lttpr fixes to v5

10:31 <jhovold> Known issues:

10:31 <jhovold> - ath12k fw in linux-firmware-20250508 is broken (revert to previous version)

11:02 <anthony25> jhovold: thanks! About ath12k, do you know if it something that needs to be fixed in the driver or if the firmware needs to be updated?

11:41 <jhovold> they should never have pushed that untested firmware in the first place

11:42 <jhovold> and when people told them about the breakage a week ago they should have reverted

11:43 <jhovold> that's probably still the right way to go even if the maj linux-firmware release is now broken

11:43 <jhovold> may*

11:44 <anthony25> thanks!

11:44 <jhovold> it's possible that they can push some change to the driver for this, but then that would need to propagate into every distro kernel to unbreak things

11:44 <jhovold> a major mess up

12:50 <JeromedeBretagne[m]> I have found some pictures of the Surface Pro 9 5G motherboard, front side here :

12:50 <JeromedeBretagne[m]> https://cdn.shopify.com/s/files/1/0092/8133/9443/files/A61UJm1NbEiAyHl1.jpg

12:50 <JeromedeBretagne[m]> Back side here :

12:50 <JeromedeBretagne[m]> https://cdn.shopify.com/s/files/1/0092/8133/9443/files/hZRCRVo1GgcLHgkO.jpg

12:52 <JeromedeBretagne[m]> The built-in LCD display FPC connector is here with the yellow arrow, near the Surface Connect port, both are at the opposite side of the 2 USB-C ports

12:54 <JeromedeBretagne[m]> Can anyone at Qualcomm or Linaro help get the built-in eDP display working on the SP9 5G, with some board schematics maybe?

12:58 <JeromedeBretagne[m]> With simple trial and error, I'm stuck. My latest patch attempt looks like this for reference:

12:58 <JeromedeBretagne[m]> https://github.com/JeromeDeBretagne/linux_surface_pro_9_5G/commit/3428f3cf01bf926328d2b3987d66bad7b7102f2a

14:02 <d0pefish> JensGlathe[m] - I just applied your Romulus link-frequencies DTS changes to my Denali (Surface Pro 11) DTS and for the very first time I have a working external monitor - nice! :) I had the mdss_dp0/1 nodes already but the link-frequencies lines were the key to get it working

14:05 <JensGlathe[m]> I would assume its the same M/B in the WDK2023. I could open it and disassemble far enough to see if its on this connector. Or you just try mdss0_dp2 like in the blackrock dt.

14:30 <JeromedeBretagne[m]> d0pefish: do you plan to upstream your work for the Surface Pro 11 ?

14:31 <JeromedeBretagne[m]> How are the fans when running Linux : quiet, almost never running, or very noisy ?

14:33 <JeromedeBretagne[m]> I did try mdds0_dp2, without success so far, I wonder how to confirm if using gpio 25 is the right one or not (from Windows, from the ACPI table)

14:45 <steev> JeromedeBretagne[m]: yeah, it looks like its gnome or something - pavucontrol shows the mic

14:45 <steev> but pavucontrol says Microphone (unplugged)

14:45 <JeromedeBretagne[m]> I will double-check and confirm when I have a chance

16:49 <d0pefish> JeromedeBretagne[m]: I would love to but most of these patches would never be accepted, there are quirks like this where there doesn't seem to be any clean way to work around it: https://github.com/dwhinham/kernel-surface-pro-11/commit/dcd5809be80213fecfc866027ada97ba25451bf9

16:50 <d0pefish> Or this, where the only way to get ath12k to work is to pretend that rfkill doesn't exist: https://github.com/dwhinham/kernel-surface-pro-11/commit/00ed1906811eb61393c69310c8972dbd05dea1ef

16:52 <d0pefish> Maybe the device tree could be merged with some polish, but man, I need to sit down and do some serious studying on how to submit to LKML, I tried once before and it got ignored because I missed off a critical email address

16:53 <d0pefish> As for the fans, the machine is pretty much silent when idling, I only hear them when I do something like compile the kernel. Seems OK overall but it's hard to tell what's working and what's not when it comes to power management

16:56 <d0pefish> "almost never running" I'd say

16:57 <steev> https://kernelnewbies.org/FirstKernelPatch

16:59 <steev> or perhaps https://people.kernel.org/monsieuricon/sending-a-kernel-patch-with-b4-part-1 (i prefer b4)

17:00 <JeromedeBretagne[m]> d0pefish: the devicetree to start with would be a great first step, I've done it for the Surface Pro 9 5G and it was a nice collaborative experience

17:00 <d0pefish> Thanks steev, I'll take some time to go through these

17:01 <JeromedeBretagne[m]> Further changes would then be applied when relevant to similar devices upstream, no need to rebase on your own

17:02 <steev> b4 makes it *super* easy to do a lot of the tasks that the FKP page does, but can be overwhelming, especially as a newbie (not that i consider myself more experienced, even just reading over it now i felt a bit overwhelmed, and i've got a few commits in)

17:02 <d0pefish> JeromedeBretagne[m]: That's great and reassuring to hear, let's start with that then :)

17:03 <steev> d0pefish: why do you need to short circuit rfkill? it just acts like it's always on?

17:05 <d0pefish> steev: Yes - everything probes just fine but it will be hard-blocked with no way to unblock it. I think there are some config bits in the ACPI that say "don't use rfkill" and if the driver could see them then maybe it'd be fine, but I'm not sure how to get ACPI working (or whether it's even possible) on aarch64

17:06 <d0pefish> There are 'feature flags' in the DSDT for WCN7850 and rfkill seems to be disabled if you hand decode them from the DSDT, then there's this which interprets them: https://lore.kernel.org/all/20250113074810.29729-3-quic_lingbok@quicinc.com/

17:11 <steev> d0pefish: hm, not sure either, maybe could do something like a quirk flag in dt? so if ath12k-disable-rfkill is set in the dt, it sets ath12k-disable-rfkill = true in the sources?

17:11 <JeromedeBretagne[m]> d0pefish: we can even do an early review of your latest devicetree before your submit it, to share some tips beforehand (I've seen quite a lot of feedback on the mailing list about the ordering of the different nodes, most of them can be avoided with extra care)

17:13 <d0pefish> steev: Yes, maybe - and maybe also for the other hack to override the display panel issue - if I could put an override in the device tree to fix the reported DPCD link rate then that hack could go away

17:13 <steev> that part i'm not at all familiar with, and i'd let someone like lumag or robclark chime in as they're smart and i'm... less smart

17:18 <d0pefish> JeromedeBretagne[m]: That would be very much appreciated :) My DTS is mainly educated guesses and fragments borrowed from other devices like Romulus and CRD so it could definitely use a more experienced pair of eyes on it

17:19 <JeromedeBretagne[m]> well, that's exactly the right way to start with, without access to the board schematics, that's exactly how I did it

17:19 <JeromedeBretagne[m]> up to a certain point, and then it can get really complicated without some technical datasheets for some parts

17:20 <d0pefish> That's good to know, so far I've just been lucky that most of the hardware follows the common reference design reasonably closely

17:22 <d0pefish> When I first started with this it would partially boot and then the screen would power down after a few seconds - I had no working USB and no network support so I had to do a lot of trial and error to get USB and Ethernet working from an initrd, and from there I could ssh in and debug further

17:22 <d0pefish> Now it's pretty usable!

17:24 <JeromedeBretagne[m]> It reminds me of my own experience, except I was able to get Wi-Fi working quickly and then I could ssh in remotely

17:26 <d0pefish> was a big eureka moment getting WiFi working just by patching out rfkill, for sure. The WiFi is even pretty reliable, I haven't seen any of the other issues that get discussed occasionally

17:27 <JeromedeBretagne[m]> I don't know why the screen powers down, I have faced the same "issue", while with Linux 6.10 I was able to keep efifb running which was super convenient (since I still don't have the correct nodes for the built-in screen yet on the SP9 5G). I should try to bissect which commit introduced this change of behavior, as it's annoying and it makes the early bring-up much more difficult

17:30 <d0pefish> it's been a while since I was poking at that issue but maybe it was something like, if the relevant regulators aren't claimed by the devicetree and the drivers aren't loaded then the regulators can end up getting turned off ... or something. I remember playing with clk_ignore_unused pd_ignore_unused to get past this annoyance

17:33 <JeromedeBretagne[m]> that rings a bell indeed. I should check if I have the same boot parameters for my different kernel versions (but normally, it should be the case so that wouldn't explain a difference of behavior between 2 different kernels, with the rest of the system being the same)

17:37 <d0pefish> I first started on this with 6.13, and pretty sure I was having the 'screen off' issues back then, FWIW

17:43 <JeromedeBretagne[m]> That would match my experience, I got my devicetree working with 6.10, then stopped for a while and when trying 6.13 and 6.14, I've faced this issue

17:44 <JeromedeBretagne[m]> <steev> "but pavucontrol says Microphone..." <- Confirmed

17:45 <JeromedeBretagne[m]> pavucontrol show a line for the built-in mic and the sound detection reacts when making some noise around the mics location

17:46 <JeromedeBretagne[m]> However, the mic detection is wrong has it says unplugged until I insert a headset in the jack

17:48 <JeromedeBretagne[m]> I would expect to have 2 devices:

17:48 <JeromedeBretagne[m]> - the built-in mic always available

17:48 <JeromedeBretagne[m]> - external microphones plugged into the headset jack appearing when plugged / disappearing when unplugged

17:52 <JeromedeBretagne[m]> jhovold: ^ Have you ever seen this audio behavior on your x13s with the mic detection?

17:54 <JeromedeBretagne[m]> I see it with the Linux 6.14 image packaged in Debian experimental

17:55 <steev> JeromedeBretagne[m]: i see it with all kernels, 6.12 from testing, 6.14 as well as custom built kernels

17:56 <JeromedeBretagne[m]> I don't know if it's a "known issue" then as the audio is described as working for this model

17:56 <steev> d0pefish: fwiw, when i submitted my first bluetooth bits, i did mention in the comments (what you put under ---) that i didn't know the actual numbers and they were guessed based on what i saw in other places, and while they worked for me, they probably needed corrections

18:02 <d0pefish> That's good to know. I'll try to make it clear when something isn't confirmed to be correct

18:26 <steev> JeromedeBretagne[m]: honestly, i'm assuming this is something on pipewire's end... maybe i'll poke in there