robclark 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
<steev>
use a symlink
<enyalios>
is there any working video acceleration on the x13s yet? i cant get mpv to play using any video outputs that it doesnt complain are bad performance
<enyalios>
things still play fine i just want to make it whine less
<steev>
should be able to
<steev>
do you have the qvcss firmware file?
<steev>
exeat: next time i push the 6.7 stuff, the firmware name will be back to b8c again
<enyalios>
hmm, i swear i put that one in place but cant seem to find it
<enyalios>
this one right? /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qcvss8280.mbn
<steev>
It’s from the windows partition
<enyalios>
is mine named wrong or did you typo it
<steev>
Yeah
<steev>
I typo, that’s right
<enyalios>
cool, `glxinfo` says that direct rendering is enabled
<enyalios>
but also says `OpenGL vendor string: Mesa` is that correct
<enyalios>
shouldnt it reference the videa card manufacturer or something
<enyalios>
it is not, i assume i should enable it and recompile?
<steev>
yes
<enyalios>
sweet, ill give it a whirl
<steev>
freedreno is the gpu in qualcomm devices
<steev>
because they use adreno (an anagram of radeon)
<enyalios>
lol, clever
<steev>
when amd bought ati, they sold the mobile unit to qualcomm
<steev>
and then robclark was super bored and decided to write an open source gpu driver for it
<steev>
at least, i assume that's why he did it
<steev>
clover[m]: i'm pushing lenovo-x13s-v6.7.0-rc7, new bits are... bringing back the nvm fw boardid generated bt firmware (so it will try to load the .b8c file again, instead of .bin), johan's patch to fix the endianness of the bt mac address (so you need to swap it back in the systemd override), lumag's pd-mapper in kernel stuff (but not enabled/modular because i can't get it to work completely here, he plans to look into it), a patch
<steev>
from the gpu guys that's supposed to fix the frame done timeouts... and the new panel entry for... someone in here, i can't recall whom... hopefully it doesn't bork their system but i can't test it
<steev>
but i also can't submit it til its been tested by someone who has the panel
<steev>
(and the webcam stuff but i think i initially pushed that with rc6?
<steev>
i wanna add konradybcio's pcie stuff to it too, but i haven't yet looked into the few patches in next that the patchsets rely on
<steev>
maybe i'll look at that this weekend
<robclark>
enyalios: make sure you have these three fw's (possibly without .xz) for gpu to work (that is separate from the fw for video dec/enc, that is not part of the gpu):
<enyalios>
i havent restarted X yet because im in the middle of things, i should be able to restart tomorrow
rmsilva- has joined #aarch64-laptops
rmsilva has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<craftyguy>
steev, exeat: using the replacement BT firmware solves the range issue I was having, it seems to be on par with other devices I have now
<craftyguy>
I was trying to get vid. accel working with that vss firmware binary from lenovo's windows driver thing, but I'm not entirely sure how to test it. I think I saw somewhere that Firefox won't be able to use it, and mpv --hwdec=auto complains about vdpau missing. so I'm probably missing something
<HdkR>
craftyguy: The video API that the hardware supports is v4l2, not VAAPI or VDPAU
<HdkR>
So missing vdpau makes sense at least :)
<travmurav[m]>
firefox does v4l2 nowdays but I think there were some issues with that
<Dantheman825[m]>
vdpau is mostly only used by Nvidia, no?
<Dantheman825[m]>
I thought most vendors insisted on VAAPI instead
<HdkR>
There's a wrapper to translate vdpau to vaapi, but yes vdpau is an NVIDIA blob thing
<travmurav[m]>
I think something like ffplay or gstreamer can be convinced to do v4l2 decode
<Dantheman825[m]>
I can get mpv to use v4l2 with an argument, so that works I suppose
<HdkR>
The Info overlay in mpv with I will also show what decoder is being used
<Dantheman825[m]>
yeah, that
<Dantheman825[m]>
* yeah, that's how I was able to differentiate the two videos I had side-by-side
<Dantheman825[m]>
also the one using v4l2 to decode used like a good 10% less CPU
<HdkR>
Anyone got one of the new ARMv9.2 CPUs with a 1Ghz cycle counter that can see how long wfe manages to sleep for?
<craftyguy>
HdkR: ya I know it's not vdpau, but it seems to only be trying that which made me think I might be missing something else
<steev>
HdkR: ask in #debian-arm maybe? i *think* someone in there has access to one (maybe markos)
<steev>
adding in a similar symlink, and rebooting and i get https://paste.debian.net/hidden/fe1e635d/ - headphones is listed as output device, haven't had a chance to test if they work or not, bedtime now
<exeat>
steev: craftyguy: good to hear about BT :)
<exeat>
(And if anyone wants the divert I mentioned, it's just: dpkg-divert --divert /usr/lib/firmware/qca/hpnv21.bin.dist --rename /usr/lib/firmware/qca/hpnv21.bin)
<craftyguy>
ya this is like, at least 10x better in terms of range than before
<craftyguy>
(~1m vs ~10m)
* craftyguy
changes postmarketOS to use that fw by default for the x13s
<exeat>
For hw video decoding with mpv, I think you need "--hwdec=auto --hwdec-codecs=all", or specifically "--hwdec=v4l2m2m-copy"
<craftyguy>
hmm, using that I get "[ffmpeg/video] vp9_v4l2m2m: capture: driver decode error" when decoding VP9
<exeat>
Same here, but it used to immediately segfault (with older mpv/ffmpeg and/or kernel versions)
<craftyguy>
ah ok, has anyone gotten that to work?
<jhovold>
Since I'm apparently not discplined enough to ignore bug reports (including ones sent on christmas day) I ended up working more than I had planned this week. Let's conclude it with an updated wip branch for the X13s:
<jhovold>
- fix bluetooth device address endianess
<steev>
jhovold is becoming an honorary american
<jhovold>
heh, sure feels like it :)
<HdkR>
Can confirm, I never stop working
<jglathe>
Found some oddities in Kconfig while trying to enable WWAN on the X13s. SDX55 was completely hidden. Drivers depended on ARM instead of ARM64:
<jhovold>
jglathe: you don't need those to enable wwan
<jhovold>
those are for running Linux *on* the SDX55 itself
<jglathe>
oh thanks. I read about it re MHI but didn't make the connection
craftyguy has quit [Remote host closed the connection]
<jhovold>
you should be good with something like:
<jhovold>
CONFIG_MHI_BUS_PCI_GENERIC=m
craftyguy has joined #aarch64-laptops
<jhovold>
CONFIG_WWAN=m
<jhovold>
CONFIG_MHI_WWAN_CTRL=m
<jhovold>
CONFIG_MHI_WWAN_MBIM=m
<Jasper[m]>
@jglathe I don't think volterra has a modem right?
<jglathe>
okay I'll check and report.
<jglathe>
@Jasper[m] no it hasn't. But the branch is for both platforms, I have both. And it's a good test to check if my modifications have side effects on the X13s.
<Jasper[m]>
aha
<steev>
jglathe: indeed it is :) and i like to do that with other patches as well; it does catch things sometimes
<jglathe>
@steev: yep. Anybody an idea why USB-C #1 doesn't work with USB-C display (dp altmode)? USB-C #0 does now. That's a difference between volterra and x13s (both work there)
<steev>
that, i don't know, i don't have any usb-c displays to even test that :(
<travmurav[m]>
jglathe: maybe hpd detection doesn't work for the other type-c?
<travmurav[m]>
I guess a fun question to always ask first is "does it supposed to work"/"does it work in windows"? :D
<jglathe>
It does. I have a log showing it. But the negotioation doesn't happen as with #0.
<travmurav[m]>
but I guess it would
<travmurav[m]>
as in, the aux displayport connection fails?
<jglathe>
@travmurav[m]: Yes I checked this before. Truth is, you can't boot with Display on USB-C#1 (loop in EFI BIOS, apparently, but if you connect later, it works on Windows, even with sound.
<travmurav[m]>
hm I guess it's supposed to allow both type-c to work with a display at the same time so there shouldn't be a mux switch...
<travmurav[m]>
jglathe: does it say something like dcpd failed as a single error line?
<jglathe>
Yes, it is supposed to work on both simultaneously. And both have dt description for usb-sbu-mux
<jglathe>
no line for dcpd.
<travmurav[m]>
(not sure if you tried to send me a file but it didn't arrive through the bridge)
<travmurav[m]>
but I'm afraid I have no guesses
<jglathe>
The log has one successful on USB0 (777..) and the unsuccessful one on USB1 (800...)
<travmurav[m]>
right, this was the error I was thinking of with ^^^, the aux lines just don't connect
<travmurav[m]>
(at least I think I had the same error when triggering an hpd with a non-alive display)
<jglathe>
hpd is odd in a way. After finding out which GPIO it was for the minidp, I had to disable it to not get 640x480 res on display resume. with 6.7-rc6 it's working quite well now.
* travmurav[m]
can't find a high-res mainboard photo to even begin guessing things
<travmurav[m]>
jglathe: but I'd suspect that the second mux doesn't switch properly or something like that
<jglathe>
wrote a GPIO detect script, my eyes aren't that good
<jglathe>
will take a look for oddities. Actually having the hw helps a lot :)
<travmurav[m]>
do you remember what surface they took the mainboard from to make the devkit?
<jglathe>
surface pro 9 5G
<jglathe>
but with mods, WWAN is disabled so hard that pcie3 bridge doesn't want to take a clock
<jglathe>
unfortunately, don't have one, and too expensive (or no sufficient excuse to justify *another* device)
<travmurav[m]>
nah I'm just looking for the fccid to find the mainboard photos
<travmurav[m]>
sad fcc photos unhelpful
<steev>
of the x13s? or the voltera?
<travmurav[m]>
of the voltera
<steev>
ah, i remember looking up the x13s, but i can't remember the name anymore
<enyalios>
steev, robclark: video acceleration is now working, recompiled mesa with freedreno and zink support, and xorg-drivers with freedreno, and added my user to the video group
<travmurav[m]>
but apparently ifixit has really really good photos of a spare mobo they sell
<steev>
enyalios: \o/
<enyalios>
now glxinfo reports things properly and mpv doesnt complain, thanks for the help as always
<HdkR>
Weird that it was tied to 3D acceleration
<steev>
yell at nerdboy to fix the wiki if he doesn't mention it
<steev>
it probably wasn't
<steev>
it might have just been not being in the video group
<HdkR>
True
<craftyguy>
enyalios: what params are you running mpv with?
<steev>
fwiw, here on kali (so debian testing) i just do mpv <video> and it shows it's using the gpu
<craftyguy>
ya I see that, but CPU usage from mpv is still like ~50%, which seems a bit... odd?
<steev>
i don't see that
<jglathe>
C3K2043, *hard* to read
<craftyguy>
"VO: [gpu] 1920x1080 yuv420p", and htop shows 50-60% cpu usage for mpv
<enyalios>
and it seems to default to `-vo gpu` now
<travmurav[m]>
jglathe: the problem is that I don't see any switches on that photo...
<enyalios>
yeah ill add all that info to the gentoo wiki page
<craftyguy>
this is with a vp9 video
<enyalios>
yeah im sure cpu usage is very dependant on the codec and bitrate
<enyalios>
my test file is h264, 720x304 and uses about 5% cpu
<craftyguy>
h264 is pretty easy to decode
<craftyguy>
(compared to others, I guess)
<craftyguy>
try h265 or vp9, I'm curious what you see
<enyalios>
lemme see if i have something in those
<craftyguy>
when I say h264 is "easy", I mean I have this dumpy atom tablet that can easily decode h264 on the CPU @ 1080p while barely breaking a sweat
<craftyguy>
if you don't, you could try piping straight from youtube using ytdlp, something like "yt-dlp https://youtube.com/whatever -o - | mpv " (but you might have to set the format in yt-dlp to get something more interesting, since it might just fetch h264)
<HdkR>
That might just be using the GPU for final composition rather than using hardware video decoding
<enyalios>
when i look at the cpu usage at the top of 'top' its quite low
<enyalios>
because its an average of the 8 cores
<enyalios>
but when i look at the mpv process its similar to yours where its ~50%
<Jasper[m]>
Isn't hw decoding limited to h264 rn?
<enyalios>
but thats 50% of one core
<enyalios>
so mine is in line with yours
<craftyguy>
Jasper[m]: I have no idea, but that might explain it :P
<Jasper[m]>
I think I saw something about it in this chat, but you should check just to be sure
<travmurav[m]>
iirc there was something about recompiling ffmpeg to make it allow vp*
<robclark>
enyalios: you should use xf86-video-modesetting, fwiw.. xf86-video-freedreno is deprecated (only used for very old adreno a2xx stuff which had a 2d core.. but probably unless distro patched it, it is too old to load with modern Xorg
<enyalios>
robclark: i believe i am
<enyalios>
[ 161.313] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so
<enyalios>
in ~/.local/share/xorg/Xorg.0.log
Ablu has quit [Read error: Connection reset by peer]
Ablu has joined #aarch64-laptops
krei-se has quit [Ping timeout: 480 seconds]
<HdkR>
Interesting, I don't even get any information from `v4l2-ctl --all` because /dev/video0 doesn't exist
jglathe has quit [Remote host closed the connection]
jglathe has joined #aarch64-laptops
jglathe has quit [Quit: Leaving]
jglathe has joined #aarch64-laptops
<jglathe>
@jhovold: bluetooth patch applied, needed to re-pair my mouse, MAC address is exactly as set (never checked before %) Controller AD:5A:00:F0:FD:8C x13s-jg [default]
<jglathe>
@jhovold: The configs you mentioned for WWAN were already set, mantic shows the modem, accepts the provider (Vodafone), but doesn't show a signal (and the wizard is flickering)
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #aarch64-laptops
krei-se has joined #aarch64-laptops
jglathe has quit [Remote host closed the connection]
jglathe has joined #aarch64-laptops
<craftyguy>
jglathe: ah I was also trying to get wwan working on the x13s last night, basically ended up with the same conclusion as you.. modem is there, signal is 0%. I configured MM to run the fcc unlock thingy, but I can't get any network connection on it
<craftyguy>
it shows profiles for vp9 and others. but I really don't know how to interpret output from that command :D
<jglathe>
is it a good idea to set the bluetooth address via devicetree? Tried it for the x13s, works (you need to add it little-endian though), like local-bd-address = [ 8c fd f0 00 5a ad ];
<jglathe>
would remove one hack for getting bluetooth up on x13s and volterra
<jglathe>
Oh this is big endian. Whatever, desired address
<steev>
jhovold just submitted a patch a couple days ago for it to be little endian, and putting it in the dts would mean everyone would have that address
<steev>
we're still waiting on information on where to get the actual bd addr on the device, it's stored somewhere, we just don't know where or how to access it yet
<jglathe>
I have applied his patch before... The other point is what lets me hesitate, too. But otherwise, the current hack does the same (same host address on all devices).
<jglathe>
Or completely random, like currently in armbian (could be a PITA).
<craftyguy>
in pmOS, it's generated from /etc/machine-id (which is unique and stable)
<craftyguy>
but having a way to get at the real addr would be nice
<HdkR>
craftyguy: Neat, so you at least have v4l2 loading up more than my device. I assume from the output that NV12 and H264 is wired up while it has some controls for other formats but the actual decoding isn't wired up for those.
<HdkR>
But I'm not familiar with v4l2 so complete guessing :D
<craftyguy>
I'm using jhovold's 6.7-rc7 + the latest venus fw from lenovo
<HdkR>
I probably don't have the firmware for venus. I know my kernel config has it enabled at least
<HdkR>
Luckily it doesn't matter for my use case :)
<craftyguy>
I think it would show in dmesg if it loaded
<craftyguy>
"dmesg | grep qcom-venus" or something
<jglathe>
@craftyguy: This sounds like a good workaround to get unique host MACs.