ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
falk689_ has joined #aarch64-laptops
falk689 has quit [Ping timeout: 480 seconds]
anarchron has joined #aarch64-laptops
<anarchron>
Hey is there any work to get the MIPI webcam on the x13s running on Linux?
<init>
I have a lot of things now working on the x13s thanks to this channel. Still getting heavy scratches and no sound using alsa-ucm-conf-x13s
<init>
i might be missing something
quinine has joined #aarch64-laptops
<quinine>
<init> "I have a lot of things now..." <- You can see if mircophone in bios is open, I checked for a long time, and finally found that the sound must be open mircophone will work.
<init>
interesting, let me check
<init>
humm, "Microphone" seems to be allowed in io port acess in bios
<quinine>
may need to use a new enough kernel and firmware 🤔
<init>
soundcard is detected under aplay -l
<init>
probably just a config location problem
<quinine>
init: does journalctl print soundcard related error logs?
<init>
somewhat yes
<init>
Mar 03 21:41:36 noodly kernel: MultiMedia4 Capture: ASoC: no backend DAIs enabled for MultiMedia4 Capture
<init>
Mar 03 21:41:36 noodly kernel: MultiMedia4 Capture: ASoC: error at dpcm_fe_dai_prepare on MultiMedia4 Capture: -22
<init>
a lot of that during boot
<quinine>
when I disable mircrophone in the bios, these logs are print
<init>
thx for trying to help but it seems unrelated to my hissing problem. I don't even see a soundcard in gnome. best I get is under aplay card 0: SC8280XPLENOVOX [SC8280XP-LENOVO-X13S], device 4: MultiMedia1 Playback (*) []
<quinine>
this may be similar, for some reason mircophone does not work, causes ASoC: error at dpcm_fe_dai_prepare on MultiMedia4 Capture: -22
<init>
that's not my problem.
<quinine>
yes, it may be a another problem. just hope this will give you some idea
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev>
init: if you're getting the MM4 Cap messages still, kernel upgrade
<steev>
i don't think i've ever looked at enabling/disabling the mic in the bios
<anarchron>
Trying to follow the documentation, turns out qcom has their own v4l2 implementation called camss but it doesn’t seem to be in any of the dts files for sc8280xp.
<quinine>
anarchron: I am also looking at this, but I am more care about the video decoder part of venus.
<anarchron>
quinine: Is there vaapi support for adreno?
<anarchron>
Thought the webcam was usb but booted into windows and realised that it’s a mess of different subsystems.
<quinine>
anarchron: Yes, I would like to rewrite libva-v4l2 if it goes well.
<anarchron>
What’s the closest implementation in android space to the sc8280xp?
<anarchron>
Wonder if we can just borrow their stairs
<anarchron>
s/stairs/dtsi /
<quinine>
another topic, i noticed that although mpv can play video sound normally, but video in chromium, firefox still no sound. is this a known issue?
<anarchron>
Chromium and Firefox works for me
<anarchron>
I realised that you needed to install a lot of Bjornn’s user land packages to get it to work
<anarchron>
Sound quality is still bad. Somewhere something is getting over amplified
<quinine>
maybe I'm missing something 🤔
<steev>
maybe you have them muted in whatever audio playback system you're using? can't reproduce here at all. the only one that gets sketchy for me is minecraft
<steev>
and yes, audio quality isn't as polished as windows, but then, it's still being worked on and in flux
<HdkR>
quinine: I am very interested in a libva-v4l2 :D
Mathew is now known as mcbridematt
<quinine>
<steev> "maybe you have them muted in..." <- i mute speaker, but i use headphone. i find that if I use speaker then it works fine.
<quinine>
<HdkR> "quininer: I am very interested..." <- first we need to get venus decoder working 😆
<steev>
you definitely wanna be on the latest alsa ucm and kernel stuffs then, that *should* fix the jack detection
<quinine>
I will start compiling immediately :D
<HdkR>
I await eagerly
<steev>
ardb: fwiw, this is what i have here, for the c630, and while it's... lets say, choppy, audio does play - https://github.com/steev/linux/tree/c630-next-20230303 (and this is my config http://sprunge.us/l8bVts which may or may not be overkill... at some point i really really need to go through both the x13s and c630 kernel configs and meld it all back together)
<steev>
the ucm config probably needs to be updated...
<steev>
fwiw, it's debian, and i'm assuming based on the name you said, you're on arch, but i pushed out the alsa-ucm-conf package i build for bookworm+ systems at https://salsa.debian.org/steev/alsa-ucm-conf (at least, i'm pretty sure bookworm and up will have it)
<steev>
(that messages is for quin
<quinine>
steev: ❤️
<quinine>
but i use arch)
<steev>
yep, i figured based on the name, not sure if the arch users have updated it yet
<quinine>
steev: 😆 I will ask you how you guessed based on name
<steev>
oh, it was actually init who said alsa-ucm-conf-x13s
<steev>
i mixed the two of you up, but it's a pretty safe bet that someone who isn't afraid to get their hands dirty is running arch ;)
<quinine>
:D
<quinine>
I updated kernel and ucm and now it works fine :D
<quinine>
thx all
<ardb>
i use debian
<steev>
ardb: for you all i meant was the kernel that i use, seems to be "okay" and the alsa-ucm-conf package in debian already has c630 ucm configs because it was accepted upstream in 1.2.7
<ardb>
steev: ah ok
<ardb>
thanks for checking
<ardb>
that is what i figured as well, and sound works fine in windows
<steev>
well "okay" it pops quite a bit
<ardb>
for me it is like listening to a geiger counter
<steev>
i have 2 patches from a long time ago (no idea if they're truly needed anymore) from srini, and then krzk's shutdown patches
<steev>
i haven't looked recently, but i think calebccff has a c630 now, and i know he was doing some stuff with it, but looking over patchwork i didn't see anything... and i can't recall off the top of my head where that tree is at, probably somewhere in/on postmarketOS gitlab
<ardb>
the commit log is not as detailed as one might desire
jhovold has quit [Quit: WeeChat 3.7.1]
jhovold has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
<init>
thx steev i'll test the patches
<init>
quite impressed by the progress done in the past 2-3 months
<init>
i mean, arch booted on the first try on a custom kernel :P
<init>
haha
<anarchron>
It’s pretty amazing how far x13s has come. It would be really great if it could get to the same level as Asahi
<Dylanger>
I'd buy one tomorrow if QC didn't squat over EL2/hyp 😥
laine_ has joined #aarch64-laptops
laine has quit [Ping timeout: 480 seconds]
<EricCurtin[m]>
I agree! Spoiler alert put Fedora Asahi is due to release any day now, just waiting on the trademark stuff to be cleared
<EricCurtin[m]>
* I agree! Spoiler alert, Fedora Asahi is due to release any day now, just waiting on the trademark stuff to be cleared
<EricCurtin[m]>
That's one of the neat things about Asahi actually, the hypervisor works perfectly
irctian1 has quit [Remote host closed the connection]
irctian1 has joined #aarch64-laptops
jkm has quit [Quit: leaving]
<robclark>
I'd argue that x13s is quite a bit further ahead than asahi in terms of upstream kernel and distro support.. there are small bits of driver enablement for the specific SoC which haven't landed upstream yet, but all are quite close, and there isn't anything like entire subsystems missing.. (other than virt, but I think a lot of people would be really interested if someone figured out how to make linux support the sibling
<robclark>
vm setup that qcom supports.. plus we already have a really good gpu virt support from qc chromebooks ;-))
<javierm>
robclark: kvm is why I prefer qc chromebooks over the X13s
<robclark>
yeah, and upstream kernel support before devices ship is another nice bonus ;-)
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
<steev>
yeah but asahi has a sweet sweet trademarked name and most other projects are just people contributing to the upstreams :(
<steev>
that must be what we're doing wrong. just contributing upstream instead of coming up with a sweet name and logo
<steev>
and the release parties could be called qeggers
<HdkR>
A bunch of college frat students representing Qualcomm gaming? Carrying kegs(qeg) around?
leezu has joined #aarch64-laptops
<steev>
ye
<robclark>
lol, qegger
<steev>
:D
<calebccff>
Dylanger: urgh literally, their m1n1 bootloader looks amazing and would make development sooooo much nicer, wish we could do the same on QC devices
<calebccff>
steev: ardb: can confirm the same audio issues with PW, we have a nice alsa-ucm fork in sdm845-mainline with useful comments and such that could be used to make better confs for the c630
<calebccff>
various driver changes have slowly broken it i think
<calebccff>
unfortunately other than poking a few things i haven't done any work on c630, most of my time is taken up with the phones
<steev>
calebccff: you're probably right - i was looking at the changes that will be making it in for the x13s confs and yeah, seems much nicer
<calebccff>
there's also weird stuff like how having two different "output devices" (as defined by ucm confs) use the same device number makes alsa/PA *really* unhappy
<calebccff>
kinda defeats the purpose of the fancy adsp/wcd audio routing stuff
<steev>
the msm driver makes mutter unhappy, so that's not unusual. lot of userland assumes you can only do some things
<robclark>
with former disto hat on, custom bootloaders aren't a thing that makes distro's happy
<steev>
current distro hat on, can confirm
<calebccff>
robclark: m1n1 is just first stage hw init i think, and a hypervisor with usb-c debugging support. it runs grub or u-boot or whatever after that
<calebccff>
if we could do this on all the QC phones that would make life so much easier
* calebccff
has flashbacks to integrating android A/B and boot image kernel upgrade support into postmarketOS
<robclark>
ahh, right, the way they trace macosx drivers.. I guess that would be kinda nice if we could do that with windows
<calebccff>
tbf EUD would probably offer some of that functionality
<calebccff>
but alas we only get a driver to turn it on in upstream, no software to actually talk to it
<steev>
i want to learn how to talk to the EC on the thinkpad... i want my blinky leds
<steev>
though... i'd really just settle for proper wifi firmware... doesn't even need to be monitor mode enabled
<EricCurtin[m]>
calebccff: is right its's m1n1 -> u-boot -> grub, u-boot provides the UEFI. I think it's unfair to say Asahi does well because of a sweet name and a logo, it's simply incredible hardware with unlocked firmware
<EricCurtin[m]>
Like I have other Qualcomm, Broadcom and MediaTek devices around the house that run Linux, they are nowhere near my M1 Mac Mini for building and running code. Really accelerates my work
<steev>
they're also quite likely nowhere near the price. but yes, apple's silicon is amazing
<steev>
you don't need to defend it though, seriously, i was just being sarcastic
<steev>
it was more about needing to deal with trademarks and stuff just to release a copy of fedora with asahi patches that made me laugh
<EricCurtin[m]>
Ha, yeah...
<HdkR>
I would love more Snapdragon devices that can compete with the Mac Mini with with price and performance. Going to be a long time until the Microsoft Dev kit can compare :P
<kettenis>
devkit has more memory and storage than the cheapest mac mini
<kettenis>
for the same price
<HdkR>
Indeed, but Mac Mini wins on perf
<kettenis>
true
<HdkR>
A shame but a reality.
<steev>
is windows ever the performance winner?
Lucanis has quit [Quit: Leaving]
Lucanis has joined #aarch64-laptops
<HdkR>
steev: Only when it has proper reclocking support and Linux doesn't :P
<robclark>
HdkR: a7xx and arm ltd stopping being a jerk about nuvia would make things more interesting
<HdkR>
robclark: Yes! Please!
<HdkR>
Nuvia's graphs about their perf/watt are hilarious but they seem to be the only CPU team trying to compete with Apple directly