ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
tobhe has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
tobhe_ has quit [Ping timeout: 480 seconds]
hwpplayer1 has joined #aarch64-laptops
hwpplayer1 has quit [Remote host closed the connection]
<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
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
<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
<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)
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
brandon63: don't know if you're still here, but the x elite asus vivobook is pretty good imo.
<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
<SpieringsAE>
and the hdmi port is a bit funky it works in very specific ways.
<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
chrisl has joined #aarch64-laptops
<JensGlathe[m]>
SpieringsAE: I have a package which supports also the Purwa variant of the Vivobook, would like to upstream.
<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.
svarbanov__ has quit [Remote host closed the connection]
<jhovold>
- ath12k fw in linux-firmware-20250508 is broken (revert to previous version)
fantom has joined #aarch64-laptops
svarbanov_ has joined #aarch64-laptops
pbrobinson has quit [Ping timeout: 480 seconds]
svarbanov__ has quit [Ping timeout: 480 seconds]
<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?
chrisl has joined #aarch64-laptops
<jhovold>
they should never have pushed that untested firmware in the first place
<jhovold>
and when people told them about the breakage a week ago they should have reverted
<jhovold>
that's probably still the right way to go even if the maj linux-firmware release is now broken
<jhovold>
may*
<anthony25>
thanks!
<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
<jhovold>
a major mess up
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
mcbridematt has quit [Server closed connection]
mcbridematt has joined #aarch64-laptops
<JeromedeBretagne[m]>
I have found some pictures of the Surface Pro 9 5G motherboard, front side here :
<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
pbrobinson has joined #aarch64-laptops
<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?
<JeromedeBretagne[m]>
With simple trial and error, I'm stuck. My latest patch attempt looks like this for reference:
SpieringsAE has quit [Remote host closed the connection]
pbrobinson has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<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
<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.
chrisl has joined #aarch64-laptops
<JeromedeBretagne[m]>
d0pefish: do you plan to upstream your work for the Surface Pro 11 ?
<JeromedeBretagne[m]>
How are the fans when running Linux : quiet, almost never running, or very noisy ?
<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)
<steev>
JeromedeBretagne[m]: yeah, it looks like its gnome or something - pavucontrol shows the mic
<steev>
but pavucontrol says Microphone (unplugged)
<JeromedeBretagne[m]>
I will double-check and confirm when I have a chance
<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
<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
<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
<d0pefish>
Thanks steev, I'll take some time to go through these
<JeromedeBretagne[m]>
Further changes would then be applied when relevant to similar devices upstream, no need to rebase on your own
<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)
<d0pefish>
JeromedeBretagne[m]: That's great and reassuring to hear, let's start with that then :)
<steev>
d0pefish: why do you need to short circuit rfkill? it just acts like it's always on?
<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
<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?
<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)
<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
<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
vfdkjted has quit [Ping timeout: 480 seconds]
<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
jglathe_ has quit [Remote host closed the connection]
<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
<JeromedeBretagne[m]>
up to a certain point, and then it can get really complicated without some technical datasheets for some parts
<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
<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
<d0pefish>
Now it's pretty usable!
<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
<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
<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
jglathe_angrybox has joined #aarch64-laptops
<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
<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)
vfdkjted has joined #aarch64-laptops
<d0pefish>
I first started on this with 6.13, and pretty sure I was having the 'screen off' issues back then, FWIW
<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
<JeromedeBretagne[m]>
pavucontrol show a line for the built-in mic and the sound detection reacts when making some noise around the mics location
<JeromedeBretagne[m]>
However, the mic detection is wrong has it says unplugged until I insert a headset in the jack
jglathe_angrybox has quit [Remote host closed the connection]
<JeromedeBretagne[m]>
I would expect to have 2 devices:
<JeromedeBretagne[m]>
- the built-in mic always available
<JeromedeBretagne[m]>
- external microphones plugged into the headset jack appearing when plugged / disappearing when unplugged
xroumegue has quit [Quit: WeeChat 2.3]
<JeromedeBretagne[m]>
jhovold: ^ Have you ever seen this audio behavior on your x13s with the mic detection?
<JeromedeBretagne[m]>
I see it with the Linux 6.14 image packaged in Debian experimental
<steev>
JeromedeBretagne[m]: i see it with all kernels, 6.12 from testing, 6.14 as well as custom built kernels
<JeromedeBretagne[m]>
I don't know if it's a "known issue" then as the audio is described as working for this model
<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
<d0pefish>
That's good to know. I'll try to make it clear when something isn't confirmed to be correct
_whitelogger has joined #aarch64-laptops
martiert has quit [Ping timeout: 480 seconds]
<steev>
JeromedeBretagne[m]: honestly, i'm assuming this is something on pipewire's end... maybe i'll poke in there
chrisl has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
xroumegue has joined #aarch64-laptops
martiert has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<anthony25>
wow, I did some updates on opensuse, and now my laptop is terribly slow to boot (even on Windows, the boot logo takes ages and windows takes 10 times longer to load)
<anthony25>
(slim 7x)
<anthony25>
tumbleweed doesn't even boot, it fails on the initramfs, and ubuntu (that I didn't touch) doesn't as well
<anthony25>
windows, once booted, seems ok
<anthony25>
and dracut loops on the partition lookup
<JeromedeBretagne[m]>
SP9 5G built-in display's EDID, extracted from the Windows partition:
<anthony25>
well, I booted in the UEFI recovery (through the pin under the laptop), forced a storage scan and MB scan, and it fixed it
<anthony25>
maybe unplugging the battery for a while to reset the firmware would have fixed it too
<anthony25>
I think what might have happened is I rebooted the laptop after compiling a kernel, the laptop was very hot, I rebooted and the heat might have corrupted something in the firmware startup
<JeromedeBretagne[m]>
parse-edid doesn't seem too happy about this EDID, I wonder if this could have an impact with the panel eDP detection and whether it could explain this message I see in the logs :
<JeromedeBretagne[m]>
panel-simple-dp-aux aux-aea0000.displayport-controller: Couldn't power on panel to ID it; using conservative timings: -110
<JeromedeBretagne[m]>
investigation for another day
<JeromedeBretagne[m]>
$ parse-edid < EDID.txt
<JeromedeBretagne[m]>
You seem to have too many extension blocks. Will not continue to parse
<JeromedeBretagne[m]>
Something strange happened. Please contact the author,
<alexVinarskis[m]>
"using conservative timings" is pretty normal thing unless panel is explicitly known."Couldn't power on panel to ID it" sounds more like whatever you set as enable pin or the supply did not turn on at all.
<alexVinarskis[m]>
Are there ACPI dumps for SP9 5G somewhere? Couldn't find them in aarch64-laptops. You would sometimes have edid of panels in the end of dsdt as well.
<JeromedeBretagne[m]>
Thanks Alex
<JeromedeBretagne[m]>
Yes, I had shared the ACPI dumps here :
<alexVinarskis[m]>
these are the two panels defined. you can find EDID blocks there as well. it also says bunch of useful stuff like backlight is a 9bit pwm, its 3rd bank of PWM 9 (as in `<&PwmPmicName 3 PwmFrequency.>`), and its pmic (power?) number 2. (as in 0,1,2, whicherve pwm capable pmic is `@2`)
<alexVinarskis[m]>
though, if you are getting error that panel is not on at all, you either defined illegaly supply or enable pin, or panel is indeed not on, either way you probably need to scroll higher and find TLMM gpios related to panel.
<JeromedeBretagne[m]>
the panel detected on Windows is an LG one: LP129WT232166
<JeromedeBretagne[m]>
that's also what I can see when uploading the EDID in this online EDID decoder: