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
shoragan has joined #aarch64-laptops
shoragan has quit [Read error: Connection reset by peer]
shoragan has joined #aarch64-laptops
aly has joined #aarch64-laptops
aly has quit [Remote host closed the connection]
paddymahoney has quit [Ping timeout: 480 seconds]
paddymahoney has joined #aarch64-laptops
paddymahoney has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> Branch based on jhovold 's branch, plus WDK and HP X14 stuff
<JensGlathe[m]> also [this one](https://patchwork.kernel.org/project/bluetooth/patch/20241003-bt-nvm-firmware-v1-1-79028931214f@oldschoolsolutions.biz/), getting good bt range/quality on all tested devices
<JensGlathe[m]> fw file should be in the initramfs
<MrCatfood[m]> is it gen70500_sqe.fw ?
<MrCatfood[m]> <JensGlathe[m]> "hmm [looks okay](https://github..." <- i will recompile my kernel from this, is there a specific config I should use or use the default?
<JensGlathe[m]> it is usually 3 files, gen70500_gmu.bin and gen70500_sqe.fw, and the specific qcdxkmsuc8380.mbn. The first two are loeded by the driver from qcom/, for the zap shader fw the path is in the dts.
<JensGlathe[m]> re config: depends a little on the system you run. My config is basically ubuntu reduced to qcom platform. It should work with defconfig, though.
<MrCatfood[m]> thank you, it clarified some things for me, I will give it another go
sri has joined #aarch64-laptops
<macc24> <JensGlathe[m]> "fw file should be in the..." <- why?
<macc24> msm driver tries to re-load the firmware anyway and with msm compiled into kernel and firmware files on the usual /lib/firmware it works just fine
<JensGlathe[m]> if msm is not loaded as module? In my config it is loaded as module.
<JensGlathe[m]> I will try it out, my impression until now was, gpu fw files better be available early
srinik has joined #aarch64-laptops
ema has quit [Quit: leaving]
ema has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
<SpieringsAE> MrCatfood[m]: this is the kernel I used on my asus https://github.com/anonymix007/linux-x1e/tree/wip/x1e80100-6.12-rc1
<SpieringsAE> If you are using Arch linux arm you can use this as an extra repository to pull the kernel etc from https://github.com/anonymix007/x1e-alarm/releases/tag/packages
<macc24> <JensGlathe[m]> "I will try it out, my impression..." <- i mean... i always built msm right into the kernel and just put all firmware files as normal onto the hard drive, and it worked just fine on sc7180 and x1e80100
<JensGlathe[m]> You do boot from SSD, right
<macc24> yes
<JensGlathe[m]> Another world when you boot from USB type-c apparently
<travmurav[m]> afaik just need the adsp firmware for usb
<travmurav[m]> gpu firmware only if your splash is 3d accelerated /s
<macc24> it works fine without usb - just don't load the firmware later on because it would re-enumerate all usb devices
<JensGlathe[m]> yep
<JensGlathe[m]> I will try and only put adsp into initramfs, lets see
<macc24> why do you put firmware into your initramfs
<travmurav[m]> you can get the thing to not loose the rootfs on usb if your initramfs reloads the adsp (and restarts usb power) before the said rootfs is mounted
<JensGlathe[m]> adsp only "works", but cdsp will not be loaded later
<JensGlathe[m]> the rest apparently will be loaded later
<travmurav[m]> I think you can manually kick cdsp via sysfs but also is it even used by anything yet?
<JensGlathe[m]> no idea
<anonymix007[m]> travmurav: AFAIK CDSP is the only remoteproc that can run unsigned hexagon binaries, so it can be used to i.e. offload audio processing from the CPU. One would need to recompile the libraries for hexagon and it should work.
<travmurav[m]> well I mean it's not actually used
<travmurav[m]> but also eh double copying audio between cdsp and adsp sounds sad
<travmurav[m]> I guess might be possible to zerocopy buffers but still eh
<travmurav[m]> and then you can't do compressed playback I guess
<travmurav[m]> (I guess not like one would care on laptops)
srinik has quit [Ping timeout: 480 seconds]
srinik has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
srinik has joined #aarch64-laptops
kalebris_ has joined #aarch64-laptops
kalebris has quit [Read error: Connection reset by peer]
kalebris_ is now known as kalebris
<erebion[m]> I've installed Debian on my X13s, which just arrived. When booting up I get about 300 ms of systemd messages, then the screen turns black. I've got no idea what's going on as I cannot see anything and also have not yet set up SSH. Any ideas what's wrong?
<travmurav[m]> is it exactly 30s after boot? :D
<erebion[m]> Let me count
<erebion[m]> You mean after pressing the power button or after the kernel loads?
<travmurav[m]> after the kernel loads
<erebion[m]> it's 8 seconds
<travmurav[m]> mhm
<travmurav[m]> does the screen blink between that?
<erebion[m]> What do you mean?
<travmurav[m]> if no, then my guess would be that msm (gpu driver) loads but there are some dependencies missing
<erebion[m]> Probably, I have not yet successfully booted up to look at what's missing
<travmurav[m]> there would be a moment where kernel kills uefi framebuffer and tries to start the gpu driver
<travmurav[m]> which would look like the display turning off for a moment then back on
<erebion[m]> If that is just milliseconds, then yes
<travmurav[m]> so I guess display dying is that exact moment but something goes wrong
<travmurav[m]> oh
<travmurav[m]> then not sure
<erebion[m]> Though I boot like this: ` linux /vmlinuz-6.10.11-arm64 dts=/boot/efi/sc8280xp-lenovo-thinkpad-x13s.dtb arm64.nopauth clk_ignore_unused pd_ignore_unused rd.driver.blacklist=msm 3 --- quiet`
<erebion[m]> That should disable it, right?
<travmurav[m]> what if you don't disable it?
<erebion[m]> same
<erebion[m]> Actually, I don't even get the systemd messages, but it's still black and I don't get anything
<erebion[m]> <travmurav[m]> "there would be a moment where..." <- Can I stay in framebuffer somehow, get a shell and look at dmesg, add the missing firmware and then reboot and done..?
<travmurav[m]> erebion 🏳️‍🌈♾: you need to make sure msm is not loaded at least, then I think what you have (clk and pd ignored, maybe also regulator_ignore_unused) should suffice to keep display alive
<travmurav[m]> I'm not sure if rd.* is some initramfs implementation thingie tbh
<MrCatfood[m]> <SpieringsAE> "Mr.Catfood: this is the kernel I..." <- I compiled it, and used your firmware with my dump from windows and its not working,... (full message at <https://matrix.org/oftc/media/v1/media/download/Ac6KnJbHTrAxM4KSh1nLdj4vMY2-VoA3OlqYFG_hOmVYEY6now5VPVPXQk2VA3o1mrYqxZ0wtHRQud9a2FjevkFCeSWbWrhwAG1hdHJpeC5vcmcvQ1NlYUJ3cU90ZGxXV3ZRSkpBZ1FjSnND>)
<travmurav[m]> the path looks wrong somehow
<SpieringsAE> are you where did you put your firmware and did you also use the dtb from that kernel?
<SpieringsAE> look at the firmware path in the dts
<SpieringsAE> should be like /lib/firmware/qcom/x1e80100/ASUSTeK/vivobook-s15/firmwarefile.mbn
<robclark> so if it is trying to load qcom/x1e80100/qcdxkmsuc8380.mbn then the dts isn't giving the correct path
<SpieringsAE> yep
<robclark> maybe someone could send a patch to list to add the correct path for vivobook? IIRC that is still missing
<SpieringsAE> yeah I dont have a vivobook anymore rip, maybe MrCatfood can help with that
<MrCatfood[m]> i'm happy to help, i want to learn these lower level stuff of the os
<MrCatfood[m]> btw they are missing, i tought the make file in the firmware repo copies them
<SpieringsAE> I believe there are 2 sysfs files you need to read out, but cant quite remember which ones
<zdykstra> lenovo has a 40% off "sale" going on right now, it brings the T14s Gen 6 down to a more reasonable price.
<travmurav[m]> shame the firmware is a total mess
<SpieringsAE> robclark: wasnt there a script somewhere that gets those values when grabbing the firmware
<kalebris> erebion[m]: there's a ubuntu installer for the x13s, maybe can use that to bootstrap debian or at least be able to check the diffs in kernel params etc.
<erebion[m]> I've already bootstrapped that using the Debian installer, I just need to figure out why the screen is just dark,
<robclark> SpieringsAE: I think macc24 had some script to copy things to the right locations based on reading dmi fields from sysfs.. which seemed like a reasonable thing to follow
<travmurav[m]> hm maybe some kernel modules are missing form the initramfs so it dies before being able to boot fully? I guess the installer itself worked fine?
<erebion[m]> Yes, installer worked fine with the same cmdline
<MrCatfood[m]> wait what the formating missing the last line
<travmurav[m]> erebion 🏳️‍🌈♾: I'd try booting back into the installer, assuming it has live mode, then dump the initramfs to check what modues it includes and compare to lsmod of the correctly running installer
<robclark> firmware-name should be something different.. the "unsigned" fw won't work
<SpieringsAE> you need the correct branch, master branch is old
SpieringsAE has quit [Quit: Leaving]
<MrCatfood[m]> SpieringsAE: i'm using this branch, but in /boot/dtbs/6.12.0-rc1-g548e097ab1de/qcom/x1e80100-asus-vivobook-s15.dtb its different
<erebion[m]> Also, graphical rescue mode of Debian boots fine, I just noticed
<travmurav[m]> ugh so like just the normal boot path is broken?
<erebion[m]> Yeah... Firmware is there, but the Debian installer did not include them in initramfs when installing.
<travmurav[m]> ugh but the rescue mode is initramfs only I guess?
<travmurav[m]> so does it die when it mounts rootfs then...
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
<macc24> <robclark> "SpieringsAE: I think macc24..." <- yeah it's at https://github.com/Maccraft123/Cadmium/blob/master/baseboard/x1e80100-woa/postinstall, gonna need to update it to check for the actual firmware paths from devicetree
<robclark> but that does sound like a reasonable convention for dts to follow
<MrCatfood[m]> soo, i copied from build folder the dtb and now it boots, and it loads but I'm back at square one with the blinking screen
<travmurav[m]> ugh it says loaded so it's fine?
<travmurav[m]> it just tried to load on module boot first, then waited 34 seconds until rootfs with the file appeared
<robclark> so blinking screen could mean userspace problem, like trying to start g-s with too-old mesa
<robclark> you could try booting single user mode and see if anything ended up in the journal from the previous boot
<travmurav[m]> > x server
<robclark> ok.. yeah, then at least the kernel is working ;-)
<robclark> I'd check what mesa version you have... you need at least 24.2.0
<robclark> maybe glamor is badly behaved if it can't find a supported gl driver
<robclark> macc24: maybe you are already aware, sometimes I see `[ +2.039749] yoga-slim7x-ec 4-0076: Unhandled EC IRQ reason: 54` (jfyi)
<MrCatfood[m]> driverInfo = Mesa 24.0.9-0ubuntu0.1 (LLVM 17.0.6)
<robclark> yeah, defn too old
<robclark> that would be your problem
paddymahoney has joined #aarch64-laptops
* travmurav[m] remembers accidentally figuring out that one of those undocumented events happen when he presses f8 which ended up accounting to (non existent on the device) keyboard backlight
<travmurav[m]> that is, on aspire1, and there was an unused connector on the mainboard that actually was powered/unpowered according to the state
paddymahoney has quit [Ping timeout: 480 seconds]
<erebion[m]> Alright... It's just the LUKS key prompt that is invisible now, but I managed to boot up on the X13s. For some reason the screen is just black when unlocking.
bumble[m] has joined #aarch64-laptops
<bumble[m]> x13s is my all time favorite
paddymahoney has joined #aarch64-laptops
paddymahoney has quit [Ping timeout: 480 seconds]
<macc24> <robclark> "macc24: maybe you are already..." <- that's just thermistor temperature going over a threshold or something like that
<robclark> ahh, could be.. I saw it when doing something that had cpu's and gpu spooled up
<travmurav[m]> macc24: perhaps worth silencing known events then?
<macc24> that might need proper handling in the future, as the dsdt changes thermal trip points
<macc24> travmurav[m]: *shrugs*
<travmurav[m]> I did it like this for known but useless ones
<robclark> just need it to trigger some udev event or similar so compositor can red-shift the display as the temp goes up :-P
<travmurav[m]> speaking of redshift...
<travmurav[m]> do we still not have uis/compositors have $different_thing implemented? :(
<travmurav[m]> or is it perhaps just gnome/mutter thing?
<travmurav[m]> I guess if it's fan/thermal handling via the ec, might want to tap into the cooling devices stuff
<travmurav[m]> so thermal governer or whoever manages that stuff can kick the fan into high gear
<travmurav[m]> when it reaches the active cooling trip point
<robclark> I guess temp coming from EC is a skin sensor
<macc24> travmurav[m]: it's done automatically anyway
<macc24> it's just... dsdt does stuff on that event and i don't know if i need to do it too or not
<travmurav[m]> ah so I guess it has external sensor to control the fan? fun
<robclark> re: "night-light" type things.. I'd need to check. The dpu isn't as stripped down as the 7c things so it might have more than just CTM
<travmurav[m]> I guess it could still be nicer if the thermal governer and whatever magic schedulers now do for thermal capacity (at least I feel they do?) could also control the fan to keep it quieter but well
<travmurav[m]> I guess first need the platform being useable
<robclark> travmurav[m]: I expect there are both tsens sensors on the soc (ie. to keep the soc from melting) and external skin sensors (to avoid lap-burning)
<macc24> there's a lot of sensors listed in dts files
<travmurav[m]> robclark: ah I guess I will be sad with my 7c then? xD
<macc24> and in dsdt
<travmurav[m]> well obviously tsens is there but I mean right now there are two non-cooperating systems: kernel that uses tsens to throttle down the soc passively and ec that uses skin sensor(?) to actively cool
<robclark> yeah, nothing really missing from sw standpoint on sc7180, the things that are missing are hw (and/or userspace support for doing things differently when hw isn't there, depending on your PoV)
<steev> erebion[m]: are you following https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s ? it mentions some needed changes to do at the end of the install
<travmurav[m]> robclark: right i see, sad
<robclark> userspace could ofc do it on the gpu.. that is what CrOS does as fallback, so I'd still consider it a "compositor bug"
<travmurav[m]> at least nowdays gnome politely tells you that "your driver doesn't support this, sorry" xD
<erebion[m]> X13s: Debian does not know the battery percentage. Is that implemented or still missing?
<travmurav[m]> is protection-domain-mapper service running?
<erebion[m]> @steev Nope, I just trial and errored my way to a working system, lol
<steev> oh, rip
<steev> because all the questions i've seen are answered there. you're probably missing a few packages
<steev> firmware-qcom-soc protection-domain-mapper qrtr-tools acpi
<steev> you need those packages
<erebion[m]> But I see robclark is quoted there on how to get battery percentage, thanks :D
<travmurav[m]> > leds_qcom_lpg
<travmurav[m]> lol that would explain why display dies I guess
<travmurav[m]> if you don't have the backlight driver in your initramfs
<robclark> travmurav[m]: correct them, that the _hardware_ doesn't support that (which I'd guess is pretty common on lower end arm things, like is it something that rpi supports?)
<travmurav[m]> yeah I guess
<erebion[m]> I read somewhere that the MAC address is not yet implemented and the kernel generates one on each boot. Has that changed? Not seeing anything about that in dmesg.
<bamse> erebion[m]: that is correct still...
<bamse> erebion[m]: for wifi...bt you need to specify one...
<steev> there are things in the wifi for that too :)
<steev> wiki*
* travmurav[m] has wrote a funny thing in his dtbloader that sets the macs in dt to stable-random ones
<travmurav[m]> idk if this can be applied to pcie wifi cards
<travmurav[m]> the local-mac-address prop that is
<erebion[m]> What wiki?
<travmurav[m]> didn't get my hands to figuring out how to i2c in uefi still though
<erebion[m]> Well, that's specific to Debian
<steev> udev rules are not specific to debian
paddymahoney has joined #aarch64-laptops
<steev> i'm kind of lost though because you said you installed debian on it
srinik has quit [Ping timeout: 480 seconds]
<erebion[m]> Yeah. And now I would like to know what the current state of the MAC addresses is.
<erebion[m]> The kernel reporting the MAC address definitely is not specific to Debian, that much I am sure of.
<erebion[m]> Also, does audio require any firmware?
<erebion[m]> alsa-ucm-conf is recent enough, but I don't have sound
<erebion[m]> And alsamixer says things such as:
<erebion[m]> ALSA lib confmisc.c:855:(parse_card) cannot find card '0'
<erebion[m]> Oh whatever, I'll just install ALL firmware
<erebion[m]> apt install firmware-* should solve that hopefully
<JensGlathe[m]> there is a topology file that needs to be loaded, specified in the dtb
<erebion[m]> You mean firmware-name = "qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn";?
<JensGlathe[m]> no, this one: [ 10.511214] qcom-apm gprsvc:service:2:1: Loaded FW: qcom/sc8280xp/SC8280XP-LENOVO-X13S-tplg.bin
<erebion[m]> Huh
<erebion[m]> Does not seem to be packaged for Debian, where can I get that file?
paddymahoney has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> jglathe@x13s-jg:~$ apt-file search SC8280XP-LENOVO-X13S-tplg.bin
<JensGlathe[m]> linux-firmware: /lib/firmware/qcom/sc8280xp/SC8280XP-LENOVO-X13S-tplg.bin.zst
<erebion[m]> Couldn't find it on packages.debian.org, I did search with the filename you mentioned and not .zst added
<JensGlathe[m]> I know debian has made some changes re fw packaging, but Ubuntu does mirror this I assume
<erebion[m]> Will try that, thanks
paddymahoney has joined #aarch64-laptops
cyrinux has quit []
cyrinux has joined #aarch64-laptops
Son_Goku has joined #aarch64-laptops
pundir has joined #aarch64-laptops
<steev> that should be a symlink to the audioreach-tplg.bin in qcom/sc8280xp/LENOVO/21BX
<steev> okay looks like the firmware package doesn't create that symlink
<steev> the audioreach-tplg.bin firmware file is in firmware-qcom-soc though
<steev> zst just means his firmware is compressed
<steev> oh wait, yes it is, i had a typo when i searched
<steev> firmware-qcom-soc: /usr/lib/firmware/qcom/sc8280xp/SC8280XP-LENOVO-X13S-tplg.bin
<steev> JensGlathe[m]: afaik, ubuntu packages up all of the firmware as one, whereas debian splits them out into... split packages
<JensGlathe[m]> yes I was confronted by this some time ago, but can't really remember
<JensGlathe[m]> had something to do with free and non-free
<steev> yeah, and now debian has the non-free-firmware component, so users can enable non-free-firmware without enabling non-free software
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #aarch64-laptops
<hexdump0815> robclark: travmurav[m]: lots of cheap and older arm systems (for sure mt8183 in kukui chromebooks, rk3399 but many more too) support color calibration the old style (i think its done via changing gamma curves?) - only qcom seems to stand out here :)
<erebion[m]> steev Not exactly, Debian has a meta package for those that want all of them
<erebion[m]> Also no bluetooth audio
<erebion[m]> No audio at all
<steev> You have to reboot after installing the firmware, if you haven’t.
<steev> Bluetooth audio doesn’t rely on that firmware though
<steev> I wrote the Bluetooth support because back then the audio driver didn’t exist and I wanted audio
<erebion[m]> I have
<erebion[m]> What's requried for bluetooth audio?
<steev> Can you paste dmesg output?
<macc24> so the debug uart on slim 7x is on the same uart as on crd - and the uefi is probably quite talkative, though my cables aren't reliable enough to make out anything more than couple of lines of linux output
<erebion[m]> Of what in dmesg exactly?
<erebion[m]> Those are all errors, very few
<macc24> also, the EC is not on the io board :/
<steev> and pd-mapper is running?
<steev> and do you have anything in /sys/kernel/debug/devices_deferred ?
<erebion[m]> What is pd-mapper? I cannot find anything like that on this system
<steev> it should be the service that was installed when you installed the protection-domain-mapper package
<erebion[m]> 3210000.soundwireqcom-soundwire: unable to get iface clock
<erebion[m]> three times with different numbers
<erebion[m]> soundsnd-sc8280xp: WCD Playback: error getting cpu dai name
<erebion[m]> 33c0000.pinctrlqcom-sc8280xp-lpass-lpi-pinctrl: Failed to get clk 'core'
<erebion[m]> 3240000.codecplatform: wait for supplier /soc@0/pinctrl@33c0000/wsa-swr-default-state
<erebion[m]> and that four times with different numbers
<erebion[m]> Oh and two of those are txmacro and rxmacro instead of codec
<steev> i would first install the protection-domain-mapper service, and make sure pd-mapper service is started
<steev> package*
<steev> i would also make sure (i don't see it in the wiki) that you copy whatever the current kernel you have's dtb onto the efi partition, something like `sudo cp /usr/lib/linux-image-$(uname -r)/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb /boot/efi`
<steev> but audio won't start if the remote procs aren't running, and the remote procs won't start until you have the pd-mapper service running and have the firmware in place so it knows what to load (this should be only required until 6.11 comes out when pd-mapper moves into the kernel)
<macc24> isn't 6.11 out already?
<steev> as a debian package
<erebion[m]> I've already added the DTB
<erebion[m]> That was the first thing I did, already when booting the installer
<steev> did anything change when you started pd-mapper?
paddymahoney has quit [Ping timeout: 480 seconds]
paddymahoney has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
<erebion[m]> Will reboot in a couple of minutes, I've got something running I don't want to interrupt
<erebion[m]> Then I'll know
<konradybcio> does systemd-boot work ootb on 64gb t14s? steev
<steev> I have no idea, I don’t have one yet
<konradybcio> oh.. who had one then? hdkr?
<erebion[m]> It works on the X13s, by the way. Just set it up. :)
<HdkR> I don't know what systemd-boot is, and I still don't have mine setup because of the OLED problems
<MrCatfood[m]> finally gpu works now on my vivobook
<MrCatfood[m]> but on 6.12 squashfs is not working properly
<kuruczgy[m]> macc24: Hope you are taking pictures. (Both of the probing setup, e.g. where the best probe points are on the board, and of the boards themselves in general.)
alfredo has quit [Quit: alfredo]
<macc24> <kuruczgy[m]> "macc24: Hope you are taking..." <- i mean... you just take off the ssd and there's the uart, clearly labeled with nice 2.54 pads for a pin header
<macc24> they're next to the edge of the board and under the ssd(not much space) so i didn't bother with soldering and just used test probes that latch onto stuff
<kuruczgy[m]> they are thru hole?
<macc24> yes
<macc24> a plain goldpin header will work
<kuruczgy[m]> ok 2.54 thru hole indeed seems easy to connect something to
<macc24> unless you want an ssd lol
<kuruczgy[m]> :D
<erebion[m]> pd-mapper has not made the difference :/
<steev> erebion[m]: can you show the output of systemctl status pd-mapper ?
<erebion[m]> It has no output
<steev> so it just says Started pd-mapper...
<erebion[m]> Loaded: loaded (/usr/lib/systemd/system/pd-mapper.service; enabled; preset: enabled)
<erebion[m]> Active: inactive (dead)
<steev> should be Active: active (running)
<steev> and you have firmware-qcom-soc installed too?
<erebion[m]> systemctl start pd-mapper.service
<erebion[m]> Failed to start pd-mapper.service: Unit qrtr-ns.service not found.
<erebion[m]> It's installed, yes
<steev> interesting
<steev> can you install qrtr-tools that should give that service (and it's frustrating that it relies on that service)
<erebion[m]> Just did
<steev> and then restart pd-mapper
<erebion[m]> Log only says that it started
<steev> that's good
<steev> alsaucm listcards
<erebion[m]> Audio is there now! :D
<steev> ayy :)
<steev> it was the remote procs not being up :D
<erebion[m]> Maybe I should finally get an account on the Debian wiki and add that there
<steev> but... that still doesn't explain bluetooth audio not working, and that may be down to some libspa package(s) missing
<erebion[m]> Thanks for the help
<erebion[m]> I install a libspa plugin package, but have not tried yet
<steev> it absolutely should work though as my testing of the bluetooth driver was with a pair of airpods and a bluetooth speaker
<erebion[m]> "br-connection-profile unavailable" is what blueman says when connecting to headphones
<erebion[m]> It then immediately drops the connection
<erebion[m]> [Bose 700]# Failed to connect: org.bluez.Error.Failed br-connection-profile-unavailable
<steev> oh, try setting `ControllerMode = bredr` in /etc/bluetooth/main.conf and restarting the bluetooth service
<erebion[m]> Also, Audio is still unusable... It's just stuttering so much that I cannot listen to a song
<steev> do you have pulseaudio or pipewire installed?
<erebion[m]> That just then gives me input/outpur error
<erebion[m]> Pipewire
<steev> https://github.com/jhovold/linux/wiki/X13s#audio try that command that johan gives for pipewire
<erebion[m]> [bluetooth]# Failed to connect: org.bluez.Error.Failed Input/output error
<steev> interesting
jhovold has quit [Ping timeout: 480 seconds]
<steev> okay back that change out but i'm not sure what would be causing it
<erebion[m]> Setting it to "le" works
<steev> i have this set up for my pipewire setup
<erebion[m]> Though now I am connected but I still cannot use Bluetooth audio
<erebion[m]> Had to install libasound2-plugin-bluez to have Blueman allow enabling audio, but still cannot set audio to Bliuetooth, usimg for example Pavucontrol
ahoneybun[m] has joined #aarch64-laptops
<ahoneybun[m]> Has anyone seen a live disk of NixOS booting on the X13s yet?
<steev> i think there are a couple people here doing nixos on the x13s
<ahoneybun[m]> Mm I've never been able to get to the installer on it from any ISO.
<erebion[m]> One of those solved Bluetooth: gstreamer1.0-pipewire libpipewire-0.3-dev libspa-0.2-dev libspa-0.2-jack pipewire-audio-client-libraries pipewire-tests
<erebion[m]> But I'm not gonna uninstall them and reinsrall
<erebion[m]> ...and reinstall them one by one to find out
<erebion[m]> (so annoying when I accidentally hit enter while typing a sentence....)
chrisl has quit [Read error: Connection reset by peer]
chrisl has joined #aarch64-laptops
<erebion[m]> I just found out that enrolling my own Platfork Key does in fact not brick the X13s, but I also did not get Secure Boot working.
<erebion[m]> I get the systemd-boot menu, then it just says "Security Violation". That's it. Just that.
chrisl has quit [Read error: Connection reset by peer]
chrisl has joined #aarch64-laptops
<erebion[m]> Noticed this when looking at the journal: fb0: Framebuffer is not in virtual address space
<erebion[m]> Does that looks like it is connected to the screen being dark while I unlock LUKS?