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)
<steev>
based on the amount of "i've got covid so if we hung out, please test yourself!" i've seen after defcon... i think i'll wait a bit
<steev>
bamse: what's the second battery that gets reported ?
<steev>
on the c630, sorry, enter too fast
<hutchinson70[m]>
Hello, Are you interested in making $1,500 plus additional $500 for diligence and hardwork in two weeks (legit) by sparing just 15/30 minutes of your time every 48hrs without no start up fee ? If yes get back to me for more details
hutchinson70[m] has quit [autokilled: This host violated network policy. Mail support@oftc.net if you feel this is in error. (2022-08-17 01:26:50)]
billytoken[m] has quit [autokilled: Possible spambot. Mail support@oftc.net if you think this is in error. (2022-08-17 01:40:10)]
<bamse>
steev: don't know, what does sysfs say about whos implementing it?
<steev>
just says its one of the hid devices
<steev>
hid-0018:04F3:279F.0002-battery
<bamse>
right, there's one of the i2c-hid devices which present a battery...but i don't think it gives you anything useful(?)
<steev>
correct, but it presents first, so everything that just "reads" batteries, reads that one and says 0%
<bamse>
how uterly useless
<steev>
i need to look into waybar as well, because it's saying that the yoga-c630-battery doesn't exist
<steev>
oh
<steev>
it's the "stylus" that doesn't exist
<bamse>
ohh, you don't have a stylus?
<steev>
neither of my c630 came with one, that i'm aware of
<bamse>
one of mine actually did..but i don't think i've ever even tried it
<bamse>
not sure what you're supposed to do about this problem though
<bamse>
remember xfce going bonkers on me when my dualshock battery ran out as i was testing bluetooth a few years ago ;)
<steev>
suppose i could locally just get rid of i2c-5
<bamse>
isn't it one of the i2c-hid devices that you actually need?
<steev>
i2c is hid@10 which seems to only be the stylus
<steev>
i guess that's the touch screen
<steev>
i disable that in my sway config anyway
<bamse>
in i3status you specify which battery it should look at, or specifically use "__first__"
<bamse>
are the others more automagical?
<steev>
waybar will choose first if you don't specify, which gets that stylus one... when i specify "yoga-c630-battery" since that's what it shows up as under /sys/class/power_supply... it just says no battery named yoga-c630-battery... i wonder if i have to use what is in model_name, which shows up as... PABAS0241231
<steev>
no, that doesn't work either
<steev>
hm
<steev>
i wonder if i can just tell it to use upower
<steev>
ah
<steev>
waybar looks for capacity
<steev>
that shows up under the stylus "battery" but not the yoga-c630-battery
<steev>
isn't there for the x13s either, but i haven't tried sway/waybar over there
<leezu>
ndec: I'm trying ffmpeg h264_v4l2m2m hardware encode with the latest nightly ffmpeg on sc7180 but can't get it to work. Encoding a video (~/Downloads/ffmpeg -i input.mp4 -f h264 -c:v h264_v4l2m2m -an -sn output.mp4 -video_size 1280x740 -v 9 -loglevel 99) fails with "Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect
<leezu>
parameters such as bit_rate, rate, width or height" (https://termbin.com/49fi) after printing "Encoder requires nv12 pixel format." (I'm not sure why nv12 is chosen even though I'm asking for h264). v4l2-ctl --all for the Qualcomm Venus video encoder mentions both H264 and NV12 (https://termbin.com/1qpb). Do you have any idea what's going on?
<travmurav[m]>
steev: Thanks for making the MR!
<steev>
travmurav[m]: :) thanks for the pointer
SallyAhaj_ has joined #aarch64-laptops
SallyAhaj has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
clararussell[m] has quit [autokilled: This host violated network policy and has been banned. Mail support@oftc.net if you think this is in error. (2022-08-17 04:47:49)]
<qzed>
seems to be an issue on some touch panels... although I don't know how your stylus normally reports battery
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<leezu>
ndec: I expected ffmpeg to decode the input file into a format acceptable by the hw encoder, but I see that's not how it works. Thank you for clarifying. Creating a nv12 rawvideo file (ffmpeg -i input.mp4 -t 10 -c:v rawvideo -pix_fmt nv12 output.yuv) and using that as input avoids the error. But software encode of that rawvideo file to h264 takes around 10 seconds on 8 cores,
<leezu>
whereas the hw encode (~/Downloads/ffmpeg -f rawvideo -pix_fmt nv12 -s:v 1280x740 -i output.yuv -c:v h264_v4l2m2m -an -sn output.mp4 -v 9 -loglevel 99) hangs without error (https://termbin.com/t388k) Is that expected?
<bamse>
steev: i suspect 0x81 is "battery information is updated", but it's not clear to me...
<bamse>
steev: and i wasn't sure how to handle the late CHARGE vs ENERGY detection, was hoping that i wouldn't have to register the power supply that late
<qzed>
bamse: 0x81 is a standard ACPI code for "static battery info changed"
<qzed>
there's also 0x80 for "dynamic battery info changed"
<bamse>
qzed: wonderful, thanks!
<qzed>
"10.2.1 Battery Events" in ACPI spec
<qzed>
acpi essentially differentiates between static info (_BIX/_BIF), like "full capacity", and dynamic info (_BST), like current capacity / current rate
hexdump0815 has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
<ndec>
leezu: you might have found a bug :)
<ndec>
i will pass your command and log to stan (I don't see him around here). we haven't used ffmpeg in many years.. so i am not sure what's going on here.
<ndec>
leezu: does the decoder work (using m2m)?
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<leezu>
ndec: The decoder (ffmpeg -c:v h264_v4l2m2m -i input.mp4 -t 10 -c:v rawvideo -pix_fmt nv12 output_hwdec.yuv) does not hang but mentions "capture: driver decode error" and "corrupt decoded frame in stream 0" https://termbin.com/j8he Those errors disappear when increasing the time to decode from 10 seconds to 100 seconds. But in both cases, ffmpeg uses 100% cpu on 8 cores, so
<leezu>
there seems to be further issues with the hw decoder
<leezu>
Is stan in another channel? Or should I start an email thread?
<ndec>
i don't see him anywhere right now.. i sent him an email, he might be away these days.
Votes78 has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
<leezu>
ndec: In fact cpu usage of hwdec is higher than without hwdec.. "ffplay -codec:v h264_v4l2m2m input.mp4" vs "ffplay -codec:v h264 input.mp4"
hexdump0815 has quit [Ping timeout: 480 seconds]
<ndec>
leezu: but is hwdec working? because if it doesn't work, it's not a valid comparison.
<leezu>
Maybe it errors out and falls back to a different software implementation
<leezu>
[h264_v4l2m2m @ 0x75581bcc00] Using device /dev/video0
<ndec>
it's also typically not straight forward to have a full pipeline which avoid un-needed frame copies..
<leezu>
[h264_v4l2m2m @ 0x75581bcc00] driver 'qcom-venus' on card 'Qualcomm Venus video decoder' in mplane mode
<leezu>
ndec: Is there another way to verify if the hw decoder is really used? It's possible the h264_v4l2m2m pipeline in ffmpeg is badly optimized and uses 3 times the cpu as h264 while still using the hw decoder..
<ndec>
leezu: yes, you can check /proc/interrupts for a quick test, if the venus interrupts increase at least it tells you something is going on between the CPU and Venus :)
<leezu>
Great. CPU0 Venus interrupts increase by around 50 per second
<leezu>
While running ffplay h264_v4l2m2m
hexdump0815 has quit [Ping timeout: 480 seconds]
Votes78 has joined #aarch64-laptops
<leezu>
ndec: Do you know if these v4l2m2m decoders in ffmpeg have dmabuf support? This would enable the integration into firefox
<steev>
still not sure how to get it into stable, but they agreed it was a good idea
<bamse>
steev: nice!
<bamse>
yeah, it would certainly be nice to get that backported...
Lucanis0 has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
Lucanis has joined #aarch64-laptops
flowriser has joined #aarch64-laptops
flowriser has quit []
Lucanis0 has quit [Ping timeout: 480 seconds]
Votes78 has quit [Ping timeout: 480 seconds]
Votes78 has joined #aarch64-laptops
<clover[m]>
arch doesn't have that problem
<steev>
i could submit it to debian too, that isn't an issue, however... there's the fact that iirc, stable kernel is considered 5.10 and it doesn't have the USB type in it
<clover[m]>
lots of ?'s so i hope you guys can help me fill it out
hexdump0815 has joined #aarch64-laptops
<steev>
oh good deal, sorry, i keep trying to come up with free time for my thinkpad-x13s repo and failing :(
flowriser has joined #aarch64-laptops
<clover[m]>
system suspend (s2idle) is supported as of 5.19 or still only in linux-x13s?
<szclsya[m]>
probably not in linux-x13s, it's been pretty old by now
<szclsya[m]>
not sure which branch I should use now? seems that anderson's branch have some nice battery status bring ups
<clover[m]>
what about USB-PD charging? do we have that or is that included in firmware repo or still requires manual steps?
<steev>
i'll be pushing 6.0-rc1 soon
<szclsya[m]>
neat
<steev>
which, yes, s2idle, usbc dp, and battery. no idea what usb-pd is
<HdkR>
USB Power delivery
<steev>
yes, but i mean, what does it do in terms of the thinkpad
<HdkR>
Going in or out? Which one matters more for a user? :P
<steev>
well they said usb pd charging, so i'm assuming they mean does battery charging work? but that has been working for a while
<clover[m]>
i thought it worked with a caveat like you have to install firmware manually
<steev>
well, yes, you need the firmware, you'll always need the firmware
<steev>
the firmware is in linux-firmware now, at least
<steev>
but before i push i want to move the firmware paths in the dts
<clover[m]>
and i guess that means USB3 is supported because we have DP Alt Mode?
<szclsya[m]>
steev: probably still need to stick to your firmware repo for now, as alarm doesn't have the latest linux-firmware
<steev>
isn't there a linux-firmware-git package?
<szclsya[m]>
it is in the aur, but seems even older
<szclsya[m]>
guess time to write my own pkgbuild
<steev>
i would assumg the -git package would just... install git?
<clover[m]>
-git just means it follows main git branch of whatever package
<szclsya[m]>
linux-firmware-git specifically still hardcodes a version
<clover[m]>
weird, that doesn't seem right
Votes78 has joined #aarch64-laptops
_Votes78 has quit [Ping timeout: 480 seconds]
<steev>
travmurav[m]: do you happen to know what mutter would do if it has usb defined, but the kernel doesn’t know about it?
<steev>
Also the mutter devs replied and apparently I can just try to cherry-pick them onto it from the web interface, so that’s cool
<jenneron[m]>
qzed: thank you, disabling pmic@a and pmic@2 does the trick
<jenneron[m]>
also, your usb-mp patchset gives working keyboard and touchpad on samsung galaxy book s
megatradeusa[m] has joined #aarch64-laptops
<steev>
oh nice
<qzed>
nice
<clover[m]>
nicee
<steev>
qzed: hurry up and clean that up and get it sent to the list :P
<qzed>
oh, I haven't really tried to clean it up at all yet... I thought bamse mentioned someone else was working on the multi-phy stuff necessary for that
<steev>
oh
<bamse>
qzed: yeah, there was activity from some of the qualcomm engineers in the dwc3 driver a while ago
<bamse>
qzed: unfortunately i've not kept up with the development of that
<clover[m]>
can someone with an x13s do lsusb and see if they find something like "3.0 root hub"
<steev>
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
<steev>
steev@x13s:~/kernel/torvalds$ lsusb
<steev>
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
<steev>
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
<steev>
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
<steev>
(this is on -next-20220817 though - but should work on 5.19 and 6.0-rc1 too)
<steev>
i'm mostly on next because the nglru stuff tracks next :(
<clover[m]>
excellent thanks - updating my wiki page
<steev>
ideally we'd throw all this into the aarch64-laptops repos somewhere, i think
<clover[m]>
ah sorry :(
<steev>
no no, don't at all be sorry
<steev>
you're putting in work, i'm just saying it would be nice to get it into aarch64-laptops somewhere sometime
<clover[m]>
im down to put in a merge request to those repos, im not really sure where it would go either
<steev>
what i was trying to do here in my steev/thinkpad-x13s repo, was apparently you can just clone steev/thinkpad-x13s.wiki to get the wiki pages? something like that
<steev>
clover[m]: i MAY or may not have tagged it correctly
<steev>
i dunno wtf happened
<steev>
the branch isn't there, the tag and commits are though
<HdkR>
I'll need to nab that latest firmware repo :D
<steev>
or just move the files you have
<HdkR>
Little bit of both
<steev>
they *should* be the same hash as what we're using
<clover[m]>
Leo do you know what to do?
<steev>
for people who have the firmware already, should also be able to just sudo mkdir -p /lib/firmware/qcom/LENOVO && sudo ln -s /lib/firmware/qcom/sc8280xp /lib/firmware/qcom/LENOVO/21BX
<steev>
ideally though, get the firmware from upstream now :)
<bamse>
steev: do i have a patch fixing that?
<steev>
bamse: i am about to submit it to the ml yeah
<bamse>
steev: cool, thanks
<szclsya[m]>
I'll just copy pkgbuild from linux-firmware and use the latest commit, ideally removing some unnecessary firmwares too
<szclsya[m]>
arch user removing bloat (TM)
<steev>
<90s voice> you've got mail
pierro78 has quit [Remote host closed the connection]