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)
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<AlexMarty[m]>
does the battery not charge even with the firmware that you pointed me to?
<steev>
it should, as long as the remoteprocs are going - which kernel are you on?
<AlexMarty[m]>
rc7
<AlexMarty[m]>
compiled myself though
<AlexMarty[m]>
how would I check the remote procs?
<bamse>
AlexMarty[m]: you can check if it works by connecting the charger, if the LED by the power button blinks 3 times you have working charging
<AlexMarty[m]>
ah, well I dont have working chargiing then haha
<bamse>
AlexMarty[m]: and specificaly to check if you have the remoteproc loaded, you can run qrtr-lookup and confirm if you have any services on Node 5
<AlexMarty[m]>
I dont have that command, do I ahve to build it from source? pacman cant find it but I see a github for it
<bamse>
it's a useful debug tool
<bamse>
some of these had made it to archlinuxarm, others hasn't
<AlexMarty[m]>
also I do have working charging I looked at the led on the lid and not the one next to the power button. it flashed 3 times so we good
<steev>
the power button one should blink too
<AlexMarty[m]>
thanks for the help
<AlexMarty[m]>
the power button one did blink the one on the lid di not
<bamse>
steev: you have light in your power button?
<steev>
no, it's next to
<bamse>
or you mean the one next to it
<bamse>
:)
<bamse>
didn't know the one of the lid blinked
<steev>
it doesn't :(
<steev>
i mean, it does, but not for us, yet
<bamse>
ahh
<bamse>
yeah we need some code there
<steev>
iirc it fades in suspend inwindows
<AlexMarty[m]>
thats why I was confused because my t540p flashes
<steev>
unfortunately, we don't have all the x86_64 fancy stuff yet
<travmurav[m]>
How did they even manage to tie a remoteproc and the charger? Does this mean the device wont charge without the OS booted? :/
<AlexMarty[m]>
dang its all good
<bamse>
i wonder if we need to tell it to flash, or if we need to tell the EC that we're suspending and it will flash and do other things automagically
<steev>
it charges without being booted
<travmurav[m]>
But then EC gives it up to the remoteproc or something?
<bamse>
travmurav[m]: charging, battery management and usb pd are implemented in firmware on one of the dsps
<travmurav[m]>
Interesting
<bamse>
travmurav[m]: so to get charging working during boot i think they load some firmware into it...but then expect the OS to take things over after boot
<travmurav[m]>
Just feels weird as I'd assume the thing would need the same behavior when the SoC is not booted... Unless they keep that dsp always on
<AlexMarty[m]>
have you all had the issue of shutting down it just reboots te computer instead of shutting down
<AlexMarty[m]>
like `shutdown now` doesnt shut it down just reboots it
<bamse>
travmurav[m]: i don't think there's any charging unless the soc is running
<bamse>
travmurav[m]: that's typical behavior on any other qualcomm device at least
<travmurav[m]>
This sounds... bad...
<travmurav[m]>
Like a phone, yeah
<bamse>
how so?
<szclsya[m]>
you need some communication to make pd chargers output enough power, and the communication part is in the soc, so it makes sense
<travmurav[m]>
Well, I usually expect a laptop to charge when I plug it in, regardless of its on or off
<bamse>
travmurav[m]: yeah, but on doesn't mean "windows is running"
<travmurav[m]>
for the phone it's fine to load a stub OS to show the charger on screen
<travmurav[m]>
but do they do the same for the laptop>
<travmurav[m]>
?
<bamse>
yes, if you have it powered off and connect the usb cable you get a battery icon for a few seconds and then it "turns off"
<AlexMarty[m]>
there is a charge screen with a battery that pops up when I am charging and off
<szclsya[m]>
to be fair there's a stub OS for charging on x86 laptops too, it's just in the EC
<travmurav[m]>
My 7c acer thing manages stuff with just the EC, but there is a much more simple power stuff
<bamse>
travmurav[m]: well, "booting the soc" doesn't have to be much different from booting your EC
<travmurav[m]>
I guess
<bamse>
but then the requirement guys comes in with the fancy battery icon and you get a whole bunch more stuff
<bamse>
but it's still quite isolated
FizzBuzz has quit []
<szclsya[m]>
eh it's not that bad on the x13s. it's just a bunch of still images
<travmurav[m]>
I wonder, did anyone try to bring up the audio DSP on those 7c 8c platforms?
<travmurav[m]>
I see chromebooks use lpass directly but seems like some lpass clock is protected on my WoA thing
<bamse>
travmurav[m]: yeah...the audio dsp is up and running on 8cx (gen 1-3)...
<bamse>
travmurav[m]: and there's work on the audio drivers on all three generations
<travmurav[m]>
Cool, will need to look at and see if I can apply that to 7c gen1
<bamse>
travmurav[m]: 7c should be fairly straight forward as well, because it's looking a lot like the sm8?50 devices in this regard
<travmurav[m]>
Last time I tried to poke it, I took the audio service stuff from 845 but only reached the point when the cpu core with pulseaudio hangs...
<bamse>
there's a bunch of iommu settings which are platform specific...perhaps that's what you ran into?
<travmurav[m]>
But I don't really understand the audio stuff well so I might've messed up or more likely the 845 machine driver doesn't apply as is
<travmurav[m]>
hm
<travmurav[m]>
I think I tried to compare it with the DT a bit and didn't see much difference
<travmurav[m]>
downstream DT that is
<steev>
AlexMarty[m]: i haven't done "shutdown -now" just "poweroff" and that works here
<steev>
same command line whether i'm on -next or -rc8
<bamse>
interesting, on my pre-production unit we jump to runtime services to attempt to power things off, and that crashes...so we reboot into debug mode
<bamse>
which on a production unit should be seen as a reboot
<bamse>
should manifest itself as...
<szclsya[m]>
yup, on my machine when using shutdown it just reboots
<bamse>
szclsya[m]: try adding efi=noruntime to your kernel command line and see if it works better
<travmurav[m]>
Does it crash with some serror that it goes to the debug mode?
<bamse>
travmurav[m]: no, in my case we jump to efi and never come back
<szclsya[m]>
bamse: so just use this parameter in addition to efi=novamap?
<bamse>
yes
<travmurav[m]>
I think mine was hanging and spamming lots of warnings about tasks on dead cores so I need efi=novamp,noruntime on 7c too
<travmurav[m]>
I just wonder if something is weird on (my?) 7c as I don't remember ever seeing an serror but just weird partial hangs when e.g. one core would die
<steev>
hm
<steev>
are you guys using "my" kernel?
<steev>
i know bamse isn't
<bamse>
travmurav[m]: well, if it just hangs in the efi call, rather than actually trigger an error...i guess you would see that
<szclsya[m]>
bamse: yup, it correctly shuts down now
<szclsya[m]>
thanks for the hint!
<travmurav[m]>
I assumed that it kills other cores, hangs in some loop in the efi but e.g. the timer still runs so the kernel can complain
<steev>
i wonder if it's because i'm using grub, not the bootloader masquerading as an init system
<travmurav[m]>
so I'd see the stack trace with unlabeled calls in the end
<szclsya[m]>
steev: I'm running grub too, and am using your kernel tree
<travmurav[m]>
steev: Maybe you have that patch that breaks the runtime detection thing?
<travmurav[m]>
or was it someone else who suggested it to me
<steev>
travmurav[m]: i thought i might have, but i don't see it
<steev>
oh right, it wasn't max who wrote it, it was shawn
<steev>
no, i still don't have that
<travmurav[m]>
fwiw I use (slightly changed) -rc3 from you and it wasn't there
<travmurav[m]>
I was also wondering, Do the 8c devices use some spi flash for the bootloader chain? (i.e. uefi)
<travmurav[m]>
Acer/Quanta did dirty on me and left everything on the emmc...
<travmurav[m]>
So I have all the 50 partitions to see and a total anxiety seeing the partition manager
<steev>
travmurav[m]: i'm not sure where exactly they are stored however
<steev>
i'm using qzed's qcom tee stuff that has been... quite the conversation starter on the email
<travmurav[m]>
But I suppose theyre not on the ufs/nvme/whatever that would have the EFI and "c:" ?
<HdkR>
I'm mostly just lucky this new apartment was setup for a family load of humans. Instead it's just me, my SO, and my server rack
<HdkR>
:D
<steev>
what makes it worse here is... they're about to paint the outside of my apartment a dark colour.... freaking chicagoans not knowing anything about texas heat
<AlexMarty[m]>
Wait you are Americam? I thought you were outside the US using metric haha
<steev>
i'm the only american on my team
<AlexMarty[m]>
Ah I see.
<steev>
to be honest though
<steev>
i'm absolutely looking up the conversion each time, not doing it in my head
<steev>
fudge
<AlexMarty[m]>
Lol. I feel that.
systwi has quit [Remote host closed the connection]
systwi has joined #aarch64-laptops
systwi_ has joined #aarch64-laptops
systwi has quit [Ping timeout: 480 seconds]
<qzed>
travmurav, steev: As far as I can tell there are two possibilities: a) some (likely QSPI) flash where probably also the firmware (uefi, tzos, whatever) itself is stored (unless there are multiple flashes) or b) some RPMB block on UFS
<qzed>
anything that runs with the current uefisecapp patches is a)
<qzed>
RPMB stuff would need a callback/handler implementation
<hexdump0815>
travmurav[m]: what 7c woa machine are you working on?
<travmurav[m]>
Acer Aspire 1
<travmurav[m]>
7c gen1
<hexdump0815>
how well is it running so far if at all?
<hexdump0815>
which dtb are you using?
<travmurav[m]>
I can (and do) use it for e.g. web browsing and light work, it's pretty good
<travmurav[m]>
I wrote the dt myself
<travmurav[m]>
So far I don't have audio and there are few not-complete things
<travmurav[m]>
e.g. I'm waiting for the usb-c - dp adapter to try bringing up that
<travmurav[m]>
reserved memory is probably not as small as it could be, there are some redundant comments to remove and EC stuff is rather sad
<travmurav[m]>
Only hacked together a small driver akin to the some-battery
<travmurav[m]>
Overall, even with some quirks that I didn't yet figured out, I'm pretty happy using it
<hexdump0815>
interesting - thanks a lot for the info
<hexdump0815>
travmurav[m]: do you have the gpu working?
<travmurav[m]>
Yes
<travmurav[m]>
qzed: I decided to naively run `sudo mmc rpmb read-block /dev/mmcblk1rpmb 0x02 1024 rpmb.raw` and it seems like the dump contains all my efivars in it
<qzed>
did you try the uefisecapp patches by any chance?
<travmurav[m]>
Not yet
<qzed>
okay, so I think they might not work in your situation... I would expect a bunch of warnings to trigger
<travmurav[m]>
My device has only the emmc, not sure if the tz can use it when the OS is booted
<qzed>
yeah, that's kinda the way I expect that to fail: TZ can make callbacks to the kernel and e.g. request RPMB reads, but that's not implemented yet
<qzed>
since I have no idea how to implement that
FizzBuzz has joined #aarch64-laptops
FizzBuzz has quit [Quit: Leaving]
jlinton_ has quit [Ping timeout: 480 seconds]
FizzBuzz has joined #aarch64-laptops
<steev>
bamse: do you happen to know, by chance, what gpio the lid switch is?
<bamse>
steev: isn't your dt saying that?
<steev>
negative
<bamse>
then that got lost in transit :/
<bamse>
i have a patch here somewhere that adds that...let me see if i can find it
<bamse>
thanks for reminding me, had forgotten to rebase that onto the upstream dts...
<steev>
hm, wakes, but doesn't sleep it
<steev>
gotta run an errand rq, will poke after
<bamse>
steev: is that with the patches to survive suspend in pcie and usb?
<steev>
yes
<bamse>
hmm, well i didn't try the patch before sending it...just rebased it from this old branch i had
<bamse>
but on my machine (which i think runs that patch) closing and opening the lid shows up nicely in evtest
<steev>
I’ll run evtestehe. I get back home
<bamse>
no rush, let me know on the list and i'd be happy to merge the patch
<bamse>
or fix it ;)
macc24 has quit []
macc24 has joined #aarch64-laptops
macc24 has quit []
<leezu>
amstan: I removed pipewire to resolve the sound issue. Is there a known issue with pipewire on lazor?
macc24 has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
<amstan>
i don't know, i was just asking you if you had good luck with sound in general and if pipewire was the trick
jhovold has quit [Ping timeout: 480 seconds]
_ has joined #aarch64-laptops
FizzBuzz has quit [Ping timeout: 480 seconds]
<steev>
bamse: closed should be 1 and open should be 0?
<steev>
it does seem to get a 1 when closed and 0 when open, i was just kinda expecting the system to suspend when closing the lid
<steev>
but i think i did the modification to ignore the lid switch to systemd, let me check that
<steev>
yes, i did, silly me
<steev>
clover[m]: if you wanna give it a spin, i tagged it super wack because i was distracted while tagging, so it's lenovo-x13s-5.19-rc8+thinkpad-x13s+suspend
<steev>
clover[m]: if you wanna give it a spin, i tagged it super wack because i was distracted while tagging, so it's lenovo-x13s-5.19-rc8+thinkpad=x13s+suspend
<steev>
bamse: i tested on both the next (upstream dts) and the 5.19 stuff mani's is based on, just to be clear
<leezu>
amstan: in general sound works well and the only issue is the auto-detection of analogue headphone. One needs to manually switch between using the headphone and speakers as the autodetection fails
<clover[m]>
I think there is a way to tell from command line right? cat /sys/mem/sleep or something...
<steev>
clover[m]: i'd modified logind.conf to ignore lid switch when suspend was guaranteed broken :D
<steev>
now its not broken, it's a workaround that upstream is likely happy with
<clover[m]>
mem_sleep should show s2idle[deep] as being selected I think
<steev>
hm, no, just s2idle here
<clover[m]>
Ok so no suspend to RAM yet I guess
<clover[m]>
The strings that may be present in this file are “s2idle”, “shallow” and “deep”. The string “s2idle” always represents suspend-to-idle and, by convention, “shallow” and “deep” represent standby and suspend-to-RAM, respectively.
<steev>
yeah, that probably needs more work for the deep sleep states
<steev>
hm
<bamse>
i was under the impression that we do s2idle only
<bamse>
and possibly hibernation
<bamse>
i.e. to disk...
<bamse>
but that's quite unlikely to actually work today ;)
<leezu>
Is anyone here familiar with Chrome's Ozone graphics stack? Running Chrome with X11 on Lazor, WebGL works. But Chrome fails to start with Ozone Wayland backend. There are several graphics related errors printed during startup https://termbin.com/hb1x mostly in the style of ERROR:gpu_init.cc(486)] Passthrough is not supported, GL is egl, ANGLE is ; ERROR:gbm_wrapper.cc(292)]
<leezu>
Failed to export buffer to dma_buf: No such file or directory (2); ERROR:gbm_pixmap_wayland.cc(75)] Cannot create bo with format= RGBA_8888 and usage=SCANOUT
<steev>
stupid question but are you actually on wayland?
<leezu>
steev: yes
<leezu>
With X11 I was referring to XWayland
<steev>
hm, yeah, it's not working here either, but it definitely used to
<steev>
i'm on 103.0.5060.134
<steev>
i'm pretty sure it's on the chromium side, because the c630 has been fairly stable in terms of GPU
<leezu>
I'm on the same version, but this issue has been there for at least 1 month. Do you have recommendations for the best channel to notify chromium devs of this problem?
<steev>
my experience back when i cared heavily about it... was to file a bug in their bug tracker. the irc channels are generally not filled with the actual devs, just other enthusiasts
<leezu>
OK. Do you have an approximate time in mind for when WebGL worked in Chromium on Wayland with SC7180?
<leezu>
Interesting that the regression was introduced around the same time Debian fell back to Ozone X11
<leezu>
Does hardware video encode/decode work for you steev?
<robclark>
the gpu in sc7180 and sdm850 are the same "sub-generation" of a6xx.. so I'd pretty much expect something broken on one would be broken on the other.. but I guess this isn't actually a gpu driver issue
<steev>
leezu: IN chromium, no, it needs some patches still that are OOT afaik and not yet working
<robclark>
fwiw qc things use v4l2 stateful decoder
<steev>
i recognize the words, but not what they mean together in this context
<robclark>
one has state, the other does not? ;-)
<robclark>
anyways, not sure how much of the chrome v4l2 stack is in common btwn the two
<robclark>
and wouldn't be surprised if lots of it was behind `#ifdef CHROMEOS` or something along those lines
<leezu>
So CrOS does not use v4l2 and the CrOS hardware encode/decode functionality can't be used on mainline linux?
<robclark>
cros most defn uses vl42.. on qc things it is using the v4l2 stateful dec/enc stuff
<steev>
my understanding of reading of the patches in that review were to move the stuff out that doesn't need to be, but on the linux side, there are changes needed to gbm
<steev>
and possibly collabora are working on that?
<robclark>
for a long time there was one small thing that was not upstream, the support for nv12-ubwc.. but I believe that is upstream now (but maybe in a different form that something as ancient as 97 used?? idk)
<robclark>
as far as chrome(ium) on linux, maybe it is an allowlist/denylist thing? I could see chrome(ium) being confused by things that don't have pci-id.. or maybe gpu sandbox issue?
<robclark>
at on point, for modern mesa, I did have to make some gpu sandbox changes.. no idea if that was before or after 97.. 97 was a long time ago already ;-)
<leezu>
With Chromium 97, the only GPU related errors at startup are:
<leezu>
[44179:44179:0730/174942.364802:ERROR:gpu_init.cc(457)] Passthrough is not supported, GL is egl, ANGLE is
<leezu>
[44179:44179:0730/174942.374620:ERROR:sandbox_linux.cc(378)] InitializeSandbox() called with multiple threads in process gpu-process.
<robclark>
should be some cmdline arg to disable gpu sandbox.. that could be worth trying?
<robclark>
hmm
<robclark>
so sandbox change was to start sandbox early, before mesa starts spawning threads
<robclark>
so could be related?
<robclark>
(fwiw, post change it aligned more with what amd/radeonsi was already doing.. if that helps any)
<leezu>
The errors remain with --disable-gpu-sandbox and --no-sandbox. Maybe these are just the wrong flags?
<leezu>
Actually chrome://gpu shows Sandboxed: false even when running without explicit --disable-gpu-sandbox
<robclark>
--disable-gpu-sandbox sounds right
<robclark>
still, the errors sound sandbox related.. or at least like somehow chromium isn't finding a gpu driver
<leezu>
I do see a "WARNING: lavapipe is not a conformant vulkan implementation, testing use only" in the stderr when opening chrome://gpu
<leezu>
But it does also say <Integrated GPU> Vulkan backend - Turnip Adreno (TM) 618
<robclark>
hmm.. finds a driver.. I guess you need some chrome://flags thing to bypass blocklist?
<robclark>
I could believe build config for chromium on linux (as opposed to cros) is opinionated about matching gpu based on pci-id.. thing that arm devices don't have for their gpus
<robclark>
last time I tried, which was not too long ago, it all just worked on fedora... but that might have been carrying over some chrome://flags change I made long ago. idk
<leezu>
Adding --enable-features=VaapiVideoDecoder command line arg does the trick
<leezu>
At least now chrome://gpu says Video Decode: Hardware accelerated
<robclark>
huh.. nothing to do w/ hw video enc/dec involves vaapi on anything arm
<leezu>
Ok, then the chrome://gpu page may be misleading
<leezu>
Is there a corresponding feature name to VaapiVideoDecoder for arm?
<robclark>
not sure.. it would be v4l2 based.. but I could believe that whoever setup build files assumed that it is something that wouldn't exist on linux builds (because x86).. still even sw video decode should be usable on sc7180
<leezu>
It's usable, but the overall performance of Chrome on Debian is worse compared to CrOS on the same device
<robclark>
I guess I'd worry about getting gpu working first.. even then it will probably be worse than cros because gl vs gles
<robclark>
and fact that cros avoids a step in composition by making browser the compositor
<robclark>
still, it should be reasonably close if you have gpu working
<leezu>
With GPU working, do you mean the Vulkan Disabled output?
<leezu>
*GPU not working
<robclark>
I'm not sure why chromium is even looking for vk.. unless maybe webgpu enabled somehow? webgl and normal ui should use gl
<leezu>
It only looks for Vulkan if I browse to chrome://gpu/
<leezu>
Compositing: Hardware accelerated and WebGL2: Hardware accelerated
<leezu>
So I was assuming GPU works now (on Chromium 97 at least)?
<robclark>
sounds like it should be working then?
<robclark>
I guess you can check some webgl thing to be sure
<leezu>
Hm, several of the WebGL conformance tests fail with FAIL Unable to fetch WebGL rendering context for Canvas
<leezu>
The stderr shows "gles2_cmd_decoder.cc(13034)] [.WebGL-0x641f22ea10]GL ERROR :GL_INVALID_OPERATION : glVertexAttribPointer: offset not valid for type"
<leezu>
"gles2_cmd_decoder.cc(12994)] [.WebGL-0x641f22ea10]GL ERROR :GL_INVALID_ENUM : glVertexAttribPointer: type was GL_FIXED"
<leezu>
I seee similar errors when running with Ozone=x11 backend, but the conformance tests pass
<robclark>
hmm, wonder if there is a webgl thing that displays GL_RENDERER? To confirm you are getting hw?
<robclark>
as opposed to some sw fallback
<robclark>
your pastebin implies that chromium is finding the driver.. but idk if that implies that it chooses to use it
<leezu>
That explains why Chromium was quite slow with X11..
<leezu>
But what about the WebGL Conformance tests? Is it expected to have many failures?
<robclark>
I guess some gl vs gles confusion somewhere in chromium?
<robclark>
pretty sure I'd have heard about it by now if there were actual driver issues ;-)
<robclark>
(plus that is all stuff that is shared code btwn all the mesa drivers)
<leezu>
Ok, so the cause may be the related to the overall breakage on Chromium 98+
<robclark>
I guess it is something build config related.. but that is pretty far out of my wheelhouse
<robclark>
if something was broken in chrome(ium) builds for cros, I'd pretty quickly get angry bug reports internally ;-)
<leezu>
Oh, ok. Then I'll take a look at cross compiling chromium. Do you know of a good reference build config for this hardware?
falk689_ has joined #aarch64-laptops
falk689 has quit [Remote host closed the connection]
<robclark>
hmm, the instructions I know of are for building chrome/ium for cros so probably not too relevant :-(
<robclark>
I guess if same thing is working on other distros (arch/fedora/etc) then compare build config? I can check fedora later if you point me at the webgl things that are failing
<leezu>
Possibly there's just one failure that triggers a bug and causes all following to fail
<robclark>
ok.. will give it a try later
<leezu>
I think the first one that failed for me is the vertexattribpointer test
<leezu>
Thank you
<leezu>
robclark: above you mentioned gl vs gles with respect to CrOS and Debian. Do you mean that CrOS uses gl but my system currently only finds the gles?
<steev>
bamse: a reminder... we need mdss stuff in mainline still ;)
<steev>
mainline/next
<bamse>
steev: got a little bit side tracked on the phy pieces, but i've been hacking on it all day :)
<steev>
:D
<bamse>
trying to figure out why the aux channel is functional if i boot with a monitor attached...
<bamse>
only functional...
<robclark>
leezu: cros uses gles exclusively (on x86 and arm things)... chromium built for linux probably uses gl but maybe there is some assumptions in some corners that arm==gles?
<robclark>
the khronos webgl conformance has a bunch of fails on my intel/fedora laptop.. so not sure to what extent it is expected to work, fwiw