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
<bamse> cool
whiskey9 has quit [Remote host closed the connection]
ellyq_ has quit []
<alexlanzano> Hey guys! I was wondering where we are at with getting the speakers working on the Yoga Slim 7x. I can poke around a bit if it's not already covered
hipboi has joined #aarch64-laptops
<kuruczgy[m]> alexlanzano: Jos Dehaes already got them half working: https://gist.github.com/joske/45386018b6b5cc04d0390dc96ce402af
<kuruczgy[m]> IMO the next big thing would be figuring out how to ensure _safe_ speaker operations. Tbh. I am kinda reluctant to play around with them until we have some story for safety
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<steev> would be cool if we could figure out speakersafetyd stuff
<steev> no idea if the chips in qcom have isense/vsense
<alexlanzano> Yeah speakersafetyd was the first thing I thought of
hipboi has quit [Quit: hipboi]
<steev> unfortunately, getting my hands on specs is damn near impossible. i swear i had a qualcomm account but i can't find it at all
<steev> and trying to sign up with my kali email they seemed to nope out pretty quick
hipboi has joined #aarch64-laptops
krzk has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
krzk has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<alexlanzano> lol, I didnt even know they gave us a chance to look at any specs
krzk has quit [Ping timeout: 480 seconds]
tobhe has joined #aarch64-laptops
<dgilmore> steev: if you need something printed I am happy to print and post to you
krzk has joined #aarch64-laptops
<steev> if you get someone who validates the account that shows a little mercy, you do
<steev> dgilmore: oh spiffy
tobhe_ has quit [Ping timeout: 480 seconds]
<macc24> <steev> "no idea if the chips in qcom..." <- they do
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
jhovold has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
indy has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<abby> successfully got a void live iso to boot on an x13s \o/ https://p.qrm.cat/itworks.jpg
<jhovold> Here's an updated wip branch for the X13s:
<jhovold> Changes include:
<jhovold> - fix pmic gpio debugfs drive strength
<jhovold> - fix gpiolib debugfs separators
<jhovold> Here's an updated wip branch for x1e80100:
<jhovold> Changes include:
<jhovold> - fix pcie interconnects
<jhovold> - fix pmic gpio debugfs drive strength
<jhovold> - fix gpiolib debugfs separators
<jhovold> - update arm scmi fixes to v4
iivanov has quit [Remote host closed the connection]
<kuruczgy[m]> steev: What specs does qcom give access to? I thought the SoC datasheet was under strict NDAs and only accessible to qcom (and maybe linaro) people.
<kuruczgy[m]> Also... aren't the speakers different in every laptop anyway?
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
srinik has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<kalebris> jhovold: not sure how the others are but I have some compile issues on the sc8280xp-6.12 versions, I think it started on rc3, and i think it comes down to this patch: https://lore.kernel.org/all/20241003230734.653717-1-ojeda@kernel.org/. It's also possible that it's a nixos specific something
<kuruczgy[m]> kalebris: Someone else also ran into this: https://github.com/kuruczgy/x1e-nixos-config/issues/32
<kuruczgy[m]> Should be fixed with rc4
<jhovold> kalebris: that's apparently an issue with DRM_PANIC_SCREEN_QR_CODE which depends on rust and isn't enabled in my config
<jhovold> just disable that option again or wait until the fix makes into into mainline
<kalebris> ok, thanks, will do so, thanks
chrisl has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
flokli has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
flokli has joined #aarch64-laptops
hipboi has quit [Quit: hipboi]
hipboi has joined #aarch64-laptops
<kuruczgy[m]> Oh I just updated nixpkgs and the issue is back...
<kuruczgy[m]> I would guess then that this is the culprit: https://github.com/NixOS/nixpkgs/commit/3bf9c88c1d8200f17c69bddb0b7dc047e6dfc6fe
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<jhovold> kuruczgy[m]: could be related, but something also has to select that QR code driver
<kuruczgy[m]> Can confirm that with DRM_PANIC_SCREEN_QR_CODE=n it compiles
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<kalebris> yeah, I just booted up into 6.12.0-rc5 with the same extraconfig added
hipboi has quit [Quit: hipboi]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
srinik has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
martiert_work has quit [Ping timeout: 480 seconds]
jglathe_ has joined #aarch64-laptops
jglathe_ has quit []
<macc24> has anyone seen battery drain issue on slim7x even if it's powered off?
<macc24> left side of the laptop is warm to the touch, heatsink inside is warm too
<bamse> jhovold: pacman -S linux-aarch64-rc
<robclark> macc24: I've not seen it warm to touch, but the power consumption when suspended does still seem higher than it should be
<macc24> mine looks to constantly draw 12-ish watts even idling in windows, and if there's any power source connected it gets warm
<macc24> as in battery connected + laptop off = dead battery after couple of hours
<robclark> it hasn't been _that_ bad for me, but I don't think I could leave it suspended for a day
<jhovold> bamse: nice! always build my own kernels, but good to see arch finally catching up
<kuruczgy[m]> For me its fine, no power drain when powered off. It does indeed stay slightly warm during sleep, but even that is definitely less than 12W.
<steev> kuruczgy[m]: i'm after the codec spec sheet, not the soc
<macc24> does wsa8845 have ANY nonvolatile memory?
<bamse> jhovold: now you can save the environment and not build yourself ;)
<macc24> my right tweeter looks like it has gain set way too high
<bamse> jhovold: same here though, typically have one x13s which runs clean upstream and one that i'm running some frankenstein build on...
<macc24> s/looks/sounds/
alfredo1 has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 is now known as alfredo
<freekurt[m]> @kbingham: is there a list of packages somewhere that one needs to get from debian/ubuntu to get the camera to work on the x13s? this page makes it sound as though the only way to get it to work is to build the software yourself instead of being able to use apt. https://libcamera.org/getting-started.html is that correct?
<KieranBingham[m]> you shouldn't need to build yourself.
<KieranBingham[m]> Are you on ubuntu or debian ?
indy has joined #aarch64-laptops
<freekurt[m]> ubuntu
<KieranBingham[m]> you need libcamera-0.3.2 and pipewire to get the camera working in Firefox.
<freekurt[m]> I can't even get it working in qcam
<KieranBingham[m]> (I think libcamera-0.3.1 might have been enough too I can't recall)
<freekurt[m]> Is it more likely to get it working in firefox?
<KieranBingham[m]> If qcam isn't working - then you have different issue that won't be solved by packages.
<KieranBingham[m]> So lets start there. - no - qcam is sort of the 'basic case'.
<freekurt[m]> Ok!
<KieranBingham[m]> Can you run from a terminal "LIBCAMERA_LOG_LEVELS=*:0 cam --list"
<KieranBingham[m]> If cam isn't packaged (sometimes it's not) we'll just use qcam there with "LIBCAMERA_LOG_LEVELS=*:0 qcam"
<KieranBingham[m]> But what I would want to see is the output from the terminal.
<jhovold> freekurt[m]: do you have these udev rules for the dma_heap permissions?
<freekurt[m]> Yes, I put them in /etc/udev/rules.d/95-libcamera-hack.rules like it said
<freekurt[m]> I am using this kernel: Linux 6.12.0-061200rc3-x1e-generic
<freekurt[m]> Is this maybe a symptom of not having a firmware file somewhere?
<freekurt[m]> Kieran Bingham: sorry, i forgot to @ you on my paste link
<KieranBingham[m]> no firmware files required.
<freekurt[m]> I installed Ubuntu using the official installer ISOs for Oracular, if that helps
<freekurt[m]> s/ISOs/ISO/
chrisl has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
<KieranBingham[m]> freekurt: So - libcamera doesn't see anything! Which means I think we need to check with Ubuntu's kernel - to see if they have the correct device tree and config options.
<KieranBingham[m]> If you're installing direct from an official ubuntu image - then I think it becomes Ubuntu's responsibility as to what is expected to work or not depending on what they ship in that install.
<freekurt[m]> @juergh had suggested previously that I fiddle with qcam's device permissions or run it as root
<freekurt[m]> I think that only worked though when I built libcamera from source instead of using the package manager to install it
<KieranBingham[m]> There's not even messages there to show it tried to probe the cameras.
<freekurt[m]> if you want, i can build it from source again and see if it works. if that is the case, i assume that would suggest there is an issue with the package and not with the ubuntu OS?
<KieranBingham[m]> I think before we look at libcamera - we need to check that your kernel has the required drivers and device tree included.
<freekurt[m]> Oh also I upgraded to Jens Glathe's kernel instead of sticking with Ubuntu's default kernel to see if that would help. That's what I am using now.
<KieranBingham[m]> Can you run "media-ctl -p" and put that into a pastebin please?
<freekurt[m]> It just says 'Failed to enumerate /dev/media0 (-2)'
<zdykstra> abby: just saw that you got void-live working for the x13s ! that's awesome!
<KieranBingham[m]> freekurt: Ok - so no /dev/media0 ... that's definitely the problem to solve. That means no qualcom camss or ov5675 drivers. Definitely something to take up with who ever makes your kernel. (Or device tree)
<JensGlathe[m]> freekurt: Uhuntu‘s default kernel is no bad choice. In mine is an issue with lid closing-might reboot your box. It stays up if you suspend first, at least on HP X14
<freekurt[m]> I'll try "media-ctl -p" again with Ubuntu's default kernel then.
alfredo has quit [Quit: alfredo]
<freekurt[m]> Kieran Bingham: ok, here is my output with Ubuntu's default kernel: https://paste.debian.net/1333824/
<KieranBingham[m]> Much better "1: Internal front camera (/base/soc@0/cci@ac4c000/i2c-bus@1/camera@10)"
<KieranBingham[m]> You have a camera!
<freekurt[m]> Yes, this is good! Haha. Unfortunately it still doesn't seem to be working. :-)
<KieranBingham[m]> The logs say you haven't enabled the permissions correctly to be able to do softisp : [0:01:20.230506855] [3867] ERROR DmaBufAllocator dma_buf_allocator.cpp:116 Could not open any dma-buf provider
<KieranBingham[m]> [0:01:20.230550091] [3867] ERROR SoftwareIsp software_isp.cpp:91 Failed to create DmaBufAllocator object
<KieranBingham[m]> [0:01:20.230559572] [3867] WARN SimplePipeline simple.cpp:532 Failed to create software ISP, disabling software debayering
<freekurt[m]> Ok! How do I enable these permissions? I'm not familiar with that process.
<KieranBingham[m]> 'ls /dev/dma_heap/ -alh' should show a couple of files... "linux,cma" and "system"
<KieranBingham[m]> if you've already done the udev rule - make sure your user is in the 'video' group
<freekurt[m]> I currently have that file in /etc/udev/rules.d/
<freekurt[m]> It says "-rw-r--r-- 1 root root 169 Oct 1 15:42 95-libcamera-hack.rules"
chrisl has quit [Ping timeout: 480 seconds]
<freekurt[m]> crw-rw---- 1 root video 248, 1 Oct 29 11:23 linux,cma
<freekurt[m]> crw-rw---- 1 root video 248, 0 Oct 29 11:23 system
<freekurt[m]> so should I keep 95-libcamera-hack.rules owned by root and put root in the video group?
<freekurt[m]> or is it best to have it be owned by my own user first?
<KieranBingham[m]> I suspect your user isn't in the video group
<KieranBingham[m]> run "groups"
<freekurt[m]> i don't see a video group when I run "groups"
<KieranBingham[m]> Then you indeed don't have permission ...
<freekurt[m]> adm cdrom sudo dip plugdev users lpadmin
<freekurt[m]> gotcha
<KieranBingham[m]> usermod -aG video freekurt
<steev> then log out and back in
<KieranBingham[m]> yup
<freekurt[m]> Kieran Bingham: steev: my camera works now!
<KieranBingham[m]> freekurt: \o/
<freekurt[m]> thanks for all of your help, Kieran Bingham!
<KieranBingham[m]> Have you done the enable in firefox for pipewire cameras too ?
<freekurt[m]> I don't know how to do that, but would like to
<freekurt[m]> is it in the docs?
<tobhe> we should probably add some of this to our device meta package
<tobhe> to improve the out of the box experience
<KieranBingham[m]> tobhe: What's the meta package? Is that a distro specific thing ?
<KieranBingham[m]> But yes - I can't walk every user through all of this individually ...
<tobhe> The Ubuntu installer detects the device you are running on and pulls in a special meta package
<KieranBingham[m]> freekurt: The problme with "is it in the docs" is there is no place to put docs for this that I'm aware of specifically.
<tobhe> that can depend on other packages to pull them in and ship device specific config files
<KieranBingham[m]> tobhe: Do you work at canonical ? Can you get this done ?
<tobhe> yes
<freekurt[m]> tobhe coming in clutch!
<KieranBingham[m]> Excellent ;-)
<freekurt[m]> hell yeah!
<KieranBingham[m]> freekurt: Lets cross the finish line though - open firefox - a new tab and go to "about:config"
<freekurt[m]> done
<KieranBingham[m]> accept any risks - and then search for pipewire
<freekurt[m]> got it
<KieranBingham[m]> Set "media.webrtc.camera.allow-pipewire" to true
<freekurt[m]> done
<KieranBingham[m]> And ... then ... cross your fingers and open a video call ... meet.jit.si/x13s-test if you like (but I have no audio)
<KieranBingham[m]> haha - and now my camera is broken ...
<KieranBingham[m]> no video coming though I'm afraid
<freekurt[m]> shoot
<freekurt[m]> oh i think it works now. had to restart firefox
<KieranBingham[m]> working!
<freekurt[m]> thanks so much for all of your help!
<KieranBingham[m]> Now - why is mine broken ;-)
<freekurt[m]> lol
<steev> sometimes after a while, cma starts complaining it can't allocate the memory
<KieranBingham[m]> ouch - that shouldn't be happening.
<steev> 2024-10-25T12:24:38.800995-05:00 finn kernel: cma: number of available pages: 352@9888+96@14240+96@18336+96@22432+96@26528+2144@30624=> 2880 free of 32768 total pages
<steev> 2024-10-25T12:24:38.800981-05:00 finn kernel: cma: __cma_alloc: linux,cma: alloc failed, req-size: 4000 pages, ret: -12
<robclark> does isp not have iommu? I'm pretty sure (the downstream) camera driver in CrOS tree is using iommu
<KieranBingham[m]> robclark: We can't use the ISP ...
<robclark> ahh
<KieranBingham[m]> This is softisp ... - which just needs 'big page' memory - looks like cma is a fallback allocator - but we can /dev/udmabuf too - which is what's default on mine currently - and that's been ok.
<KieranBingham[m]> Well - big page memory is a bad description - we just need something we can pass as a dmabuf handle.
<robclark> if there is no page size / contiguity requirement you could get dmabufs from gpu or venus/iris..
<robclark> is "softisp" not a kernel thing that could export it's own dmabufs?
<KieranBingham[m]> we could get memory from anywhere that gives us a dma buf - but there's no centralised memory allcoator service in linux yet it seems. Ask Laurent - he's very opinionated on what needs to be done - but it seems no one can ever do the work ...
<KieranBingham[m]> softisp is CPU only - no kernel interface ....
<KieranBingham[m]> so we fall back to getting memory from /dev/udmabuf and /dev/dma_heap/*
<steev> we don't set udmabuf in any kernel config i have :(
<KieranBingham[m]> Ideally - we need memory that's suitable for use by the consumer ... which could be an encoder, or a GPU ... and may have specific requirements ... but there's nothign that can (at a system level) make sure memory is allocated suitable for multiple devices like Ion would do in android for instance.
<robclark> so softisp is all userspace?
<KieranBingham[m]> At the moment, I think udmabuf is better as it reduces pressure on contiguous memory requirements... 'but' that memory might not be able to be used by all devices.
<KieranBingham[m]> Yes softisp is (currently) pure userspace. Few of the guys are working on a GPU implementation at the moment.
<robclark> on qc there are iommu's all over the place.. the only constraints are going to be layout/format should be something compatible with iris/gpu/etc
chrisl has joined #aarch64-laptops
<KieranBingham[m]> For current use case into a firefox browser though - the first thing that happens is firefox runs the images through libyuv anyway - I think - so no requiremnt for contiguous buffers for just a webcall in firefox.
<robclark> so requiring cma is a bit sad... udmabuf is I guess better. But maybe if you were going to be passing it to gpu you should allocate from gpu
<robclark> if you are doing sw access then you defn want cached memory (which I guess udmabuf does)
<KieranBingham[m]> yes - we don't 'require' cma ... it's just one way to get some buffers.
fparent has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
<KieranBingham[m]> but ther'es a few mail threads somewhere where distros' are arguing over how we are supposed to get this memory to use .
<steev> KieranBingham[m]: if udmabuf is enabled does libcamera fall back to it if cma allocations fail?
<KieranBingham[m]> Not necessarily if they fail. I think it picks an allocator at startup - and expects to use that.
<robclark> if it is for cpu access, just don't use cma
<robclark> if it is for gpu, maybe we need to revive that gitlab issue about letting gbm allocate yuv
fparent has joined #aarch64-laptops
<KieranBingham[m]> robclark: I'd /love/ to pull you into the conversations if you're willing ;-)
<KieranBingham[m]> I'm sure your name has been brought up on this before ...
<robclark> yeah, that one.. I guess if we have a good reason for it, it might be worth the pain. Although qc is kinda a special/easy case because we always know what video codec it's going to be paired with
chrisl has quit [Ping timeout: 480 seconds]
<KieranBingham[m]> is gbm part of mesa ?
<robclark> yeah (minigbm is not, and has mostly similar api).. iirc someone was making some noises about splitting gbm out into it's own thing
<KieranBingham[m]> so is minigbm a system library we can link in 'general' linux successfully ? or do we just need to replicate what it does in libcamera ? In fact I could have lots of questions - but I'm on vacation this week - so I'm going to hopefully try to remember to look into this again next week instead ;-)
<robclark> minigbm is, I think, a thing you can only count on with a CrOS userspace. It's kinda our gralloc but with an api that looks like gbm
<freekurt[m]> Oh man, thanks for helping me while on vacation, Kieran Bingham!
<KieranBingham[m]> freekurt: No worries - glad it's working!
<freekurt[m]> I added the information you provided to this x13s Ubuntu page so that people can find it in the future. https://discourse.ubuntu.com/t/status-of-ubuntu-support-for-lenovo-thinkpad-x13s/44652/123?u=libredood
chrisl has joined #aarch64-laptops
anarsoul has quit [Quit: ZNC 1.9.1 - https://znc.in]
chrisl has quit [Ping timeout: 480 seconds]
jhovold has quit [Quit: WeeChat 4.3.4]
anarsoul has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
anarsoul has quit [Quit: ZNC 1.9.1 - https://znc.in]
anarsoul has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
gwolf has quit [Ping timeout: 480 seconds]
gwolf has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<konradybcio> macc24 the SL7 idles at about 4-5 watts with sync_state reached and cpufreq patches merged and gpu disabled (very specific i know)
<konradybcio> i have the opposite issue though, where sometimes closing the lid makes the power consumption go to 0 watts..
<JensGlathe[m]> its powering off...? I have the reboot issue (looks to me like it) But only with my kernel, Ubuntu qcom-x1e does it fine - on HP X14
<konradybcio> yeah sometimes it refuses to wake up from sleep.. i can't remember how often though
alfredo has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
whiskey9 has joined #aarch64-laptops
ahf has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
echanude has quit [Ping timeout: 480 seconds]
<craftyguy> is there a way to tell ath11k to stop printing these "msdu_done bit in attention is not set" messages to the kernel log? they completely dominate the log :/
xroumegue has quit [Ping timeout: 480 seconds]
xroumegue has joined #aarch64-laptops