<hogliux>
Regarding better EL2 suppoer, I was wondering if it would be possible to somehow leverage gunyah to intercept how DSPs are booted in EL1. Does this even make sense?
<hogliux>
I feel like that would be a better fit.
<hogliux>
I've written a few ALSA linux userspace devices (pulseaudio/pipewire use linux userspace devices to bridge ALSA apps to pulseaudio/pipewire).
<hogliux>
Whenever i have time I'd like to work on speaker protection. Here, I'm wondering why asahi linux use a daemon (sepakerprotectiond) for this. In my day job
<hogliux>
(but in EL2 many things don't work: bluetooth, battery-indicator,charging etc.).
<hogliux>
I also sometimes boot into EL2 (via slbounce - thank you TravMurav!) to fire up the odd VM
<hogliux>
I also have hibernation working and regularly use the built-in speakers on very very low gain.
<hogliux>
A few things don't work: I'm using the same kernel as kuruczgy (Thank you kuruczgy!!), so basically have the same things working as him:
<hogliux>
Since the day I bought it in mid-August, I've been using it exclusively on Linux and using it as my daily driver.
<hogliux>
I for one am very happy with my slim 7x. I got the 32 GB variant from lenovo.com for 1500 Euros and upgraded it myself to a 2TB ssd. I love the keyboard and the screen is just gorgeous.
2024-11-19
<hogliux>
before, when not loading snd_soc_wsa884x in initramfs (i.e. letting udev load them for me during normal bootup after initramfs), I would occasionally hit the race-condition and not have sound
<hogliux>
I use my slim 7x as a daily driver and have been using this setup for month or two now and never had the race condition
<hogliux>
what I find is that as long as the snd_soc_wsa884x kernel module is loaded before the in-kernel pd-mapper (or userspace pd-mapper FWIW), everything seems to work
<hogliux>
is the in-kernel pd-mapper <-> sound race condition still an issue for some?
<hogliux>
steev: but the screws were too thick. So in the end I just taped it down with normal tape. It's going to come and haunt me in the future some day for sure
<hogliux>
travmurav[m] and others affected by the recent commit: I just want to say thank you for all your work and help here on this channel. It's sad to see that it has come to this. I'm hoping for more normal times again.
2024-10-14
<konradybcio>
hogliux: the fan is driven by the ec, specific to each machine :(
<robclark>
hogliux: you could try increasing/decreasing /sys/devices/platform/soc@0/3d00000.gpu/power/autosuspend_delay_ms to see if that makes a difference.. also play with min/max freq in /sys/devices/platform/soc@0/3d00000.gpu/devfreq/3d00000.gpu (see available_frequencies)
<hogliux>
I was just surprised to hear it so soon on my yoga 7x
<hogliux>
I've heard it more and more on my old laptop (very old Dell XPS 13 7th gen Intel) as it gradually aged. I always assumed it's just what happens when transformers or other passive electrical components get old.
<hogliux>
I can literally hear the I-cursor blink every second in the input field of IRC and I'm sitting about a meter away from my laptop.
<hogliux>
Yeah I'm sure when I had my laptop new it was much much quieter. It's very loud when scrolling or playing animated gif. It actually goes away when the cpu is actually under load. That's why I assume it's the switching of power states or cpu freqs that I'm hearing. So a low fps gif will constantly switch between different power states between frames. But that's just my uninformed guess.
<hogliux>
I'll try UEFI later. Can't really reboot right now
<hogliux>
It's super load when loading the kernel in grub: then it's actually a whine. In linux and windows it sounds more like whispering
<hogliux>
:-( seems like it's my unit then. Just booted into windows and it's also super loud there.
<hogliux>
... from the speakers.
<hogliux>
A random question for the yoga 7x folks: how loud is your laptop's coil whine? Mine is annoyingly loud. I can actually here the I-beam of the cursor blinking and scrolling and resizing a window sounds awful. I could swear it got worse after upgrading to 6.11. Has anything changed in regards to frequency scaling? It could also be because I now load the tplg file for sound and the amps might be on or something but it doesn't sound like it's coming
2024-10-10
<krzk>
macc24: hogliux: jhovold: just a note that latest ALSA UCM for X1E80100 CRD is for kernels with DisplayPort, which is not in mainline/next, so use a bit older commit (pre DP). Also the DP one has some issues on my Debian - I think I wrote conflicting devices in wrong or incomplete way.
<JosDehaes[m]>
that's why I didn't create a PR earlier, but now hogliux confirmed it's actually working
<hogliux>
krzk: Maybe ask JosDehaes. But I think he just decompiled the tplg file of the CRD.
<hogliux>
krzk: sorry I can't help with that
<krzk>
hogliux: not good, we need the sources
<hogliux>
krzk: That's because JosDehaes decompiled the binary tplg file with `alsatplg -d`, removed the hardware relating to the audio jack and then re-compiled it with `alsatplg`
<krzk>
hogliux: something like commit 56b403ffe857dcfb264783a4a50728272fffd887 in that repo
<krzk>
hogliux: please rebase because you pushed some mixup from CodeLinaro, which I dropped while moving to Github, but what's more important - I need there source code, not BIN file
<hogliux>
kuruczgy[m]: Yes definitely. There is no speaker protection. I did a -12dB on my audio wav file in audacity before playing to be on the safe side. But be really sure that you call `aplay` with the correct format settings so that you don't start playing noise.
<kuruczgy[m]>
hogliux: krzk: Cool, thanks, will try it out when I have some time.
<hogliux>
JosDehaes: is it ok for me to PR your tplg file for the Lenovo Slim 7x? Or do you want to submit the PR?
<hogliux>
Oh beat you to it: https://pastebin.com/rn4wv1t1 . However, please, wait until JosDehaes gives his approval here. Because he created the tplg file and did all the work. It should really be him who submits the patch not me.
<hogliux>
krzk: I don't have login for codeLinaro so how can I open a PR there?
<krzk>
hogliux: or if it is too complicated maybe you have audioreach topology repo forked somewhere with your commit, so I would cherry-pick and send as pull req
<hogliux>
If you take the CRD's tplg, you'll get a ton of dsp errors. With macc24's version, alsamixer now detects everything correctly but you still get an error in dmesg that the UCM profile is missing. I'm swamped with work currently so won't be able to work on the UCM file anytime soon. But there are UCM files for the CRD so it shouldn't be that hard to adopt to the slim 7x.
<hogliux>
Hmm this is the ACPI table for the RTC on the yoga slim 7x: https://pasteboard.co/tvqaXXNM8mL8.png The _GRT method gets the current time. Doesn't look all to complicated. Does it maybe only work in EL2?
<hogliux>
Does anybody have a working realtime clock on their x1e80100 on linux (specifically yoga slim 7x)? It's annoying me that I always need to wait for internet for my clock to be correct.
2024-10-01
<hogliux>
jhovold: kind of hoping I could just copy over the dts changes to the yoga slim 7x :-)
<hogliux>
jhovold: is the web cam on the yoga slim 7x the same as on the x13s? (crossing fingers)
2024-09-30
<macc24>
hogliux: will dm you later today, got lots of life stuff to do
<hogliux>
macc24: happy to send you one if you give me dm me your address
<macc24>
hogliux: there's regulators missing for usb4 stuff
<hogliux>
travmurav[m]: but i think there would be significant effort needed to get this working on linux
<hogliux>
travmurav[m]: pcie tunneling over usb4 works in Windows on the yoga slim 7x. I have a Sonnet Thunderbolt PCIe enclosure with a PCI Aquantia NIC and that works in Windows (although an Arm driver is missing for the actual NIC itself.)
<SpieringsAE>
hogliux: fellow yocto enjoyer, I am planning on doing some too when I get my 32gb ram asus, yeah from scratch is very rough, stuff like nodejs takes half an hour ish on my ryzen 9 5900x at work
<hogliux>
spawacz: check that you have the `qcom_q6v5_pas` module loaded. Without that, my yoga 7x will also not charge.
<hogliux>
JensGlathe[m]: So on my yoga, I can't suspend the device when it's AC powered. It wakes up again immediately. But I don't really need suspend on AC power, I guess ¯\_(ツ)_/¯
<hogliux>
JensGlathe[m]: and also on Ubuntu 24.04. I've actually never had the whole system crash. I had a GPU crash once which restarted Wayland and sometimes the laptop "hangs" if I try to suspend or wakeup. But that's it. Inteterestingly: I get many more BSOD in the few times I used windows.
<hogliux>
JensGlathe[m]: I use my yoga 7x to compile yocto builds from scratch. A build can take up to two hours with fans going full speed. I've never had the laptop shut off once. I'm on vanilla 6.11 with mmac's recent EC patches.
2024-09-29
<hogliux>
macc24: you said that you would use the yoga 7x' camera as a lid switch: you have the webcam working on the 7x? Which module do I need to enable to get it working?
<hogliux>
macc24: great work on the EC driver for the yoga 7x. Suspend now works perfectly for me
2024-09-27
<hogliux>
JosDehaes[m]: I'm just trying to at least get alsa to try loading the ucm. According to this page https://wiki.postmarketos.org/wiki/Alsa_UCM , the folder and filename should match what it shows in the square brackets when running `aplay -l`. So I tried renaming the `x1e80100` folder to `X1E80100-LENOVO-Yoga-Slim7x` and `X1E80100-CRD.conf` to `X1E80100-LENOVO-Yoga-Slim7x.conf`. But it doesn't even seem to attempt to load it.
<hogliux>
JosDehaes[m]: but installing the latest `ucm2` folder from upstream alsa-ucm-conf doesn't change anything. I think maybe we just need to rename the `X1E80100-CRD.conf` to something else?
<hogliux>
macc24: hmmm simply the X1E80100-CRD-tplg.bin [1] file to `/usr/lib/firmware/qcom/x1e80100/X1E80100-LENOVO-Yoga-Slim7x-tplg.bin` seems to work much better. Still no sound, but no more DSP errors in dmesg
<hogliux>
macc24: "hogliux: yeah with arm64.nopauth firefox works perfectly fine, thanks" did you mean to direct this message to someone else?
<macc24>
hogliux: yeah with arm64.nopauth firefox works perfectly fine, thanks
<hogliux>
macc24: no sure, it's more of a sanity check. Maybe quick renaming etc. But looking at iirc more closely, I think the audioreach-tplg is based on an entirely different codec
<macc24>
hogliux: idk, if devicetree had everything that was needed then why would tplg files exist?
<hogliux>
macc24: but I don't really know what to change. Looking at audioreach.tplg, there are no obvious things missing in it which aren't also referenced in the slim 7x's devietree file (for example `VA_CODEC_DMA_TX_0` etc.)
<hogliux>
macc24: I would imagine the tplgs between the X13s and the slim 7x to be quite similar
<hogliux>
macc24: it's easy enough to decompile the audioreach-tplg.bin file for the X13s with `alsatplg --decode=audioreach-tplg.bin -o audioreach.tplg`
<macc24>
hogliux: uhh i think i saw a tplg source file for the crd on git.codelinaro.org but i don't remember where, maybe it could be modified for slim 7x
<hogliux>
kuruczgy[m]: jhovold: gabertron: does anybody have audio working on the yoga slim 7x? It looks like I'm just missing the X1E80100-LENOVO-Yoga-Slim7x-tplg.bin file. I tried using the audioreach-tplg.bin from here [1] instead but it just gives me tons of DSP errors.
2024-09-26
<hogliux>
ok kind of was expecting that
<HdkR>
hogliux: Both
<hogliux>
HdkR: "not wired up" mean it's not in the device tree or stuff needs to be added to the re-timer or other drivers - or both?
<HdkR>
hogliux: Thunderbolt/PCIe tunneling isn't wired up in Linux. Sad day I know
<hogliux>
Has anyone had any experience with USB4 PCIe tunneling/thunderbolt alt mode? I have a PCIe NIC I need for work in a thunderbolt enclosure. It works on Windows on the yoga slim 7x. Nothing happens on Linux even with all the recent patches to the retimer (i.e. DP alt mode works for me in Linux).
<hogliux>
abelvesa: Do you have any suggestions on what I could try?
<hogliux>
Yeah! Suspend to disk aka hibernation (almost) works on the slim 7x with jhovold's rc7 kernel. GPU, WiFi, Keyboard, Trackpad restores nicely again. Unfortunately, everything depending on remoteproc (battmgr, bluetooth etc.) does not survive restore. I've tried unloading qcom_glink and qcom_q6v5_pas before hibernation but reloading them after hibernation gives me this:https://paste.pics/76672cd740f07d8842a966c89d7db49c
<hogliux>
The recovery image is not very straight forward. I think it reboots probably something like 20 times and runs a crazy number of .bat scripts to install stuff. It almost looks like your computer is being remote controlled during the process. It all goes so fast though. I'd have no idea which part of the install actually updates the firmware.
<robclark>
hogliux: a shell.efi build I had laying around (maybe >1yr old) had same no-keyboard issues, fwiw.. and the recovery image.. well I don't want to wipe out my linux install, and the whole needing a windows machine to create the recovery image is a bit of a chicken/egg problem. But maybe it is possible to extract the bios update from the recovery image?
<hogliux>
robclark: s/new/knew
<hogliux>
robclark: It's a huge pain! You need to have an account with lenovo and then download a windows only download tool to download the recovery medium. Then I needed 3 attempts for the recovery to actually work. But it did. And I ended up with a different firmware version (can't actually tell if it's newer because I forgot what the firmware version was before - I just new it was different).
<hogliux>
robclark: Also, there are firmware updates available. I by mistake fat-finger nuked my SSD during linux installation and needed to download Lenovo's Windows recovery medium: https://pcsupport.lenovo.com/de/en/solutions/ht103653
<hogliux>
ween the keyboard working and not working. The only thing that may have "unlocked" the keyboard for me is to boot into an efishell. Maybe you need to boot once into efishell to unlock the keyboard somehow.
<hogliux>
robclark: There is something very strange with the internal keyboard on the slim 7x and grub. For me, internal keyboard and grub just suddenly started to work on my Slim 7x. Others seemed to have had the same experience (see comment by kuruczgy here, for example: https://gist.github.com/joske/52be3f1e5d0239706cd5a4252606644b?permalink_comment_id=5162458#gistcomment-5162458). I 100% did not update the firmware (or even boot into windows) bet
<hogliux>
anonymix007[m]: You were right: it had nothing to do with jhovold's kernel or your kernel. I was using 6.11 rc1 kernel with jhovold's branch and yours is on rc6. With rc1 (same firmware) the device doesn't lock up after two minutes when booting into busbox and only loading the keyboard modules. With rc6 it does. Anybody know what exactly causes the screen to go blank in rc6 if you don't load all the necessary modules.
2024-09-07
<anonymix007[m]>
hogliux: do you have all the required firmware and modules in your initramfs?
<hogliux>
anonymix007[m]: Maybe it's the three additional patches that I apply to jhovold's kernel (i.e. see the three pacthes in the kernel section here: https://rentry.co/u33pcakd ). I really want to understand the exact cause of why the screen goes blank after a minute or two if not all modules are loaded.
<hogliux>
anonymix007[m]: I need to figure out what the difference is between the two repos. Right now, I have a grub entry for both jhovold's kernel and your kernel. If I boot into initramfs' busybox from jhovold's kernel the screen stays on. If I boot into busybox with your kernel, the screen blanks after two minutes or so.
<hogliux>
nirik: Also, if I run this little snippet: `I=0; while true; do echo ${I}; I=`expr ${I} + 1`; sleep 1; done`, it continues counting while the laptop is suspended.
<hogliux>
nirik: hmm suspend just doesn't work for me - something always immedietely wakes the laptop up again. I think during suspend only the keyboard should wake the device, but that's clearly not happenung for me. If I just move the mouse or touch the screen the device is back on.
2024-09-06
<anonymix007[m]>
hogliux:
<hogliux>
For anyone who has the Yoga Slim 7x, I created a very brief write-up on how I got things working here: https://rentry.co/u33pcakd I hope it's usefule to someone.
2024-09-03
<hogliux>
Still very hard though!
<hogliux>
Yes the Dell XPS 13 also returned the battery info with asl. The battery info method would call EC write/read methods also implented in ASL. But if you reverse engineered that ASL, it was clear that it just followed the spec that I linked above. That made reverse engineering much easier.
<hogliux>
Yes exaclty. For x86 dell XPS 13 EC I once reverse engineered the EC write/read methods were all implemented in asl. But if you know what you are looking for you can identify those asl methods.
<hogliux>
llow the spec and should be easy to identify.
<hogliux>
anonymix007[m]: Thanks for your answer. I've added slimbus, slim-qcom-ctrl, slim-qcom-ngd-ctrl kernel modules, but linux still finds no devices under /sys/bus/slimbus/devices. I need to check windows on how exactly the bluetooth module is connected...
2024-09-02
<hogliux>
Does anybody have more details on how BT is connected on x1e80100 laptops? Is it part of the ath12k module or part of the SoC? Is it connected via some internal bus? I'll have a look at the ACPI tables and see if I spot anything there.
<hogliux>
travmurav[m]: Thank you for your answer. I'm learning so mucn.
<travmurav[m]>
hogliux: because most of the actual platform definition is not in acpi but in the PEP driver. Getting that to work in linux would be possible but /a lot/ of work, while DT support for qcom platforms in linux is pretty mature already thanks to mobile socs
<hogliux>
jhovold: I have a really general question: why doesn't booting with ACPI actually work? All the interaction with the EC is encoded into the ACPI tables which we can dump from Windows. I think Arm is pushing in that direction with their "Arm Base System" specification. And I think grub can load custom ACPI tables from disk.
<hogliux>
kuruczgy: It should really work also during kernel compilation
<hogliux>
ransom=random
<hogliux>
Not sure why. Seems a bit ransom. There seems to be kind of race condition somewhere.
<hogliux>
But then sometimes, it doesn't
<hogliux>
Yeah for me as well
<hogliux>
I think it's a bit hit&miss currently
<hogliux>
Maybe during my lunch break it never really went into suspend
<hogliux>
Instead of compiling the kernel, you can also just run something like this: I=0; while true; do echo ${I}; I=`expr ${I} + 1`; sleep 1; done
<hogliux>
Not sure what woke it. There was no "mhi mhi0: Requested to power ON" message.
<hogliux>
But sleep is still intermittant: I tried compiling the kernel again over lunch break while suspended. The computer's screen went blank while I was packing things together, but when I came back the screen was on adn the kernel had finished compiling.
<hogliux>
But looking at the IRC history here, I think I don't have all the firmware load patches for ath12k that you do
<hogliux>
kuruczgyt: I only see the "Requested to power ON" message when I have ath12k driver loaded
<kuruczgy>
hogliux: Interesting find. If I try to sleep during kernel compilation it refuses, the screen goes black for a second and then comes back, `/sys/power/state` reports "Device or resource busy", and I also see the "mhi mhi0: Requested to power ON" message.
<steev>
hogliux: the led pulsing is something from the EC and we don't have that yet
<hogliux>
JosDehaes[m]: you should try unloading ath12k before suspending. At least in my kernel compilation test, I can see that it actually pausing compilation. Keyboard light still stays on though and the power indicator also does not pulse.
<hogliux>
JensGlathe[m]: that seems to be it. If I `rmmod ath12k` before suspending then it does seem to suspend.
2024-09-01
<JosDehaes[m]>
hogliux: Yes it's probably not really asleep. I put my machine into suspend at 75% in the evening and in the morning there was only 35% left. Seems a bit much even if the machine is not yet going in lowest power state
<JensGlathe[m]>
hogliux: hmm MHI is Modem Host Interface, ath11k / ath12k drivers use it to download some firmware afaiu. Otherwise MHI is intervowen with PCIe (which is the physical layer or something). But, when the WiFi drivers act up on Suspend (which appears to be an issue) this would sound logical.
<hogliux>
In the kernel logs I see "kernel: mhi mhi0: Requested to power ON". Is this maybe a hint on what's causing the machine to wake up? It's very generic as I think alsmost everyhing is connected to the MHI.
<hogliux>
kuruczgy[m]: Can you true this experiment as well?
<hogliux>
kuruczgy[m]: JosDehaes[m]: I'm pretty sure my machine is not sleeping due to the following test: try starting a clean kernel compilation just before sleeping. Then let the machine "sleep" for 20 minutes or so. After 20 minutes "wake-up" the machine. Not only has the kernel finished compiling for me, but I clearly hear the fans spin up while the laptop is "asleep".
2024-08-30
<hogliux>
So gpio is wired up but the hall sensor is disabled
<hogliux>
Maybe it needs to be enabled by ec somehow
<hogliux>
Then doing ````while true; do gpioget gpiochip0 92; sleep 1; done``` would never detect it
<hogliux>
i'm wondering if it's edge triggered and immeditely goes back to the original value
<hogliux>
OK
<hogliux>
So maybe my one liner is incorrect
<hogliux>
And that didn't work
<hogliux>
also I tried the same ```while true; do cp /sys/kernel/debug/gpio ${I}; echo ${I}; I=`expr ${I} + 1`; sleep 5; done``` with the power button on the side
<hogliux>
oled stays on
<hogliux>
Yup: gpio92 : in high func0 2mA no pull
<hogliux>
But it didn't go back when I opened the lid again
<hogliux>
I only got a change on gpiochip7 gpio 7
<hogliux>
And then check the changes with diff
<hogliux>
Which creates a copy of all the gpios every five seconds
<hogliux>
Hmm I tried the following: while true; do cp /sys/kernel/debug/gpio ${I}; echo ${I}; I=`expr ${I} + 1`; sleep 5; done
<hogliux>
but gpiochip0 is not connected to the pmic
<hogliux>
gpiochip0 is the only one that has 92 gpios
<hogliux>
I tried `while true; do gpioget gpiochip0 92; sleep 1; done`: it doesn't change when I close the lid
<hogliux>
It was really painful
<hogliux>
A few years back I reverse engineered a tiny section to get battery information working correctly on an old Dell laptop
<hogliux>
In gnome, I can control what it should do when I press it.
<hogliux>
kuruzgy: the power button is detected as a regular input on my machine: for it's at /sys/class/input/input7
<hogliux>
Strange, I can't get the lenovo to sleep at all anymore. It just instantly wakes again without me pusing any buttons. It definitely worked this morning.
<hogliux>
OK I was wrong again about the cntvct register. I misread the arm reference manual. Not sure if it's paused or not during suspend.
<hogliux>
Is there an RTC that llinux can use? I don't think so because I always see the wrong incorrect time in boot messages in early boot (just like on a rasp pi). Only when systemd-timesyncd runs does it update to the correct time. But if the network is the only source for linux to figure out how much time actually elapsed in sleep, I wouldn't expect anything to continue counting during sleep. This is really odd.
<hogliux>
No all the cntvct timers stop during suspend. I'm just reading the arm reference manual.
<hogliux>
So wouldn't really help here
<hogliux>
Actually, I take that back what I just said: cntvct **does** actually stop counting during suspend
<hogliux>
Maybe I just need to look at the ACPI tables again and see how the lid switch is actually routed
<hogliux>
?
<hogliux>
Interestingly, linux does detect the power button press on the side. Is the lid switch even in the dtb currently.
<hogliux>
I think I'll get hibernation working soon. Just need to figure out which module is causing the issue.
<hogliux>
Yeah don't care much about sound/webcam either. I also actually prefer hibernation over suspend.
<hogliux>
kuruczgy[m]: OK that's strange. So you could alternatively just use arm64's cntvct register. You can convert that to nanos via the cntfrq_el0 and then the result will be identical to CLOCK_MONOTONIC_RAW. The register continues counting in sleep
<kuruczgy[m]>
hogliux: Regarding sound and webcam: sound is not working, have not tried webcam yet.
<hogliux>
And did you have any luck with the webcam?
<hogliux>
Also do you know where I can get X1E80100-LENOVO-Yoga-Slim7x-tplg.bin from to get sound working?
<hogliux>
I think I need to unload some modules to make hibernation work. Because it does work if I hibernate early in the boot process when only the initramfs modules had loaded (basically just keyboard and nvme)
<hogliux>
Also when I wake-up from hibernation, it loads the state from swap succesfully, but then hard-reboots just after 100% restore
<hogliux>
Is it because there is no RTC clock and it needs to sync the time first so it thinks the wake-up was right away?
<hogliux>
Both show "Aug 30 11:30:26" but I waited at least 5 minutes before I pushed any button
<hogliux>
Hmm if I look at my kernel messages https://pastebin.com/cBsBYs1N and the point it goes to sleep according to the logs (i put in a bunch of ============= where I think that is), no time went by between sleep and wake-up
<hogliux>
> Yes, I was thinking the same, but from all I can tell, the clock just stops, the machine really does go to sleep.
<hogliux>
Ahh interesting that could really be
<hogliux>
I basically like a human computer following your nix scripts to the dot, but then used debootstrap to install Ubuntu instead of nix
<hogliux>
kuruczgy[m]: I basically just followed your nix scripts manually to get the right kernel version (with patches) and to build the correct initrd.gz. It also helped figure out that I needed pd-mapper for the battery indicator.
<hogliux>
When I try to suspend I see `psci: CPU1 killed (polled 4 ms)` kernel messages how it's stoping all the CPUs, but immiedetely resumes them again 'Enabling non-boot CPUs ...'. It seems like it never tells the hardware to actually go to sleep. It's strange. I don't see any obvious errors. From the logs, it looks like I immiedetely woke up the machine again.
<kuruczgy[m]>
hogliux: Yes, that's also my repo, I think I already posted it here a couple times.
<hogliux>
Yeah suspend/resume doesn't work for me. Also hibernation doesn't work
<kuruczgy[m]>
hogliux: Glad to hear that some of my ramblings here about my experiences helped :D
<hogliux>
Oh yes, brightness control and battery indicator is also working great for me!
<hogliux>
work!!!
<hogliux>
Hi everyone here. I created an IRC account today specifically to thank everyone on here (but specifically kuruczgy and jhovold) for doing such great work in bringing linux to the Snapdragon Elite X. I bought a new Lenovo Yoga Slim 7x and it's now running Ubuntu 22.04 almost flawlessly!! USB, GPU acceleration, trackpad, touchpad, keyboard, WiFi everything is working super good. Thank you so much for all your