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
Mathew has quit [Quit: Leaving]
mcbridematt has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
LoganLeland[m] has joined #aarch64-laptops
<LoganLeland[m]>
any links for t14s?
iivanov has quit [Ping timeout: 480 seconds]
bluerise_ has joined #aarch64-laptops
bluerise has quit [Ping timeout: 480 seconds]
<TSIN[m]>
any images for vivobook s15
iivanov has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
iivanov has quit [Ping timeout: 480 seconds]
<steev>
i have heard there are, but i do not know where they are
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
<Nios34[m]>
I tried to find the GPIO of power key but failed. However, I saw there are two gpio inputs alternating over time. What could it be?
<Nios34[m]>
Samsung Galaxy Book Go
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov has quit []
<steev>
is the fingerprint reader also on the power button?
<Nios34[m]>
Samsung Galaxy Book Go does have fingerprint reader and pwrkey is on pmic. That two gpios seem interesting but I don't have any clue what are they
<Nios34[m]>
and they are not lid either
iivanov has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
kalebris_ has joined #aarch64-laptops
kalebris has quit [Ping timeout: 480 seconds]
kalebris_ is now known as kalebris
alfredo has quit [Ping timeout: 480 seconds]
<travmurav[m]>
William Goodspeed
<travmurav[m]>
I'd guess the power button is either on pmic resin pin or on the EC which then passes it to resin
<Nios34[m]>
Yeah, the power button is on pon
<travmurav[m]>
On aspire1 it's on ec but ec never passes it over, even in windows...
<travmurav[m]>
Yeah pon sounds righ
<Nios34[m]>
bruh, that sucks
<travmurav[m]>
It's still likely it goes via ec but at least it works lol
<travmurav[m]>
On gbgo that is
<Nios34[m]>
My Samsung Galaxy Book Go doesn't charge... Any directions?
<Nios34[m]>
(On Linux)
<travmurav[m]>
But doe ls in windows and in uefi?
<Nios34[m]>
Yeah
<Nios34[m]>
So I worked out the backlight enable-gpio, lid gpio and power button and the battery is going to drain lol
<travmurav[m]>
I guess there is a chance that they did a funny and connected the charger directly to the soc i2c
<travmurav[m]>
But usually it's fully EC controlled I believe
<travmurav[m]>
So like EC does fully offline charger control and only tells us the status
<Nios34[m]>
Is the glink battery thing existing on sc7180?
<travmurav[m]>
No
<travmurav[m]>
At least I don't think so, it's not used on aspire1 for example
<travmurav[m]>
I think it's used if you use qcoms chargers with pmics
<travmurav[m]>
But I believe 7c is simpler so there is a more conventional charger
<Nios34[m]>
travmurav[m]: You mean pm6150?
<travmurav[m]>
William Goodspeed: you could probably check if it's "acpi battery" in windows
<travmurav[m]>
Nios34[m]: Yes it's a pmic but it's a phone pmic so I doubt it even can handle huge batteries
<Nios34[m]>
ah... I don't have Windows but I do have a copy of dsdt from GitHub (That got merged recently, yeah... after 2 years)
<travmurav[m]>
I guess that could also work, don't remember battery id from the back of my head
<Nios34[m]>
I just let GPT read it for me. But that barely worked
<travmurav[m]>
But most likely would have to reverse engineer the dsdt code
<Nios34[m]>
I do have a backup of all the drivers from Binbows tho
<travmurav[m]>
I.e. if it's similar to aspire1 you could probably read battery from some pseudo-register with "i2ctransfer" tool in linux
<travmurav[m]>
And then it's not too hard to add a driver
<Nios34[m]>
And there isn't a driver ends with 7180 lol
<Nios34[m]>
Probably they thought 850 is similar or something
<Nios34[m]>
<travmurav[m]> "Yes it's a pmic but it's a phone..." <- It seems book go can only be charged at around 20W max. It works with any phone charger. Even my friends think that's a power bank with a screen and a "mega phone". 🤣
<travmurav[m]>
Fun
<travmurav[m]>
I guess in this case they /could/ use it...
<travmurav[m]>
Then you need to look at phones with 720g I guess
<travmurav[m]>
I guess dunno if those have battmgr mess already or not yet
<jhovold>
kuruczgy[m]: there is no bugtracker entry for the broken in-kernel pd-mapper, just the thread were I reported this for now
<Nios34[m]>
btw, I tired to boot mpss with modem on 7180 but that failed 🤔
<Nios34[m]>
remoteproc: -22 (Invalid Argument I guess)
<jhovold>
even if bamse merged the patch for 6.12, we have a few a few to try to sort it out before it becomes a mainline regression
<travmurav[m]>
William Goodspeed: is the blob from your windows install backup?
<jhovold>
a few weeks*
<Nios34[m]>
Yep
<travmurav[m]>
Is it normal or _nm?
<Nios34[m]>
It's _BTU, the big one.
<travmurav[m]>
And how much memory do you give it?
<Nios34[m]>
96 MiB
<travmurav[m]>
Hm is it from the ini files in the driver?
<Nios34[m]>
It's from DriverStore, sits next to the _nm one
<travmurav[m]>
Sounds a bit small to me somehow
<travmurav[m]>
No I mean the size
<travmurav[m]>
Of reserved memory region
<Nios34[m]>
Hum, lemme try give it more
<travmurav[m]>
I'd expect over 100
<travmurav[m]>
For the modem os
<Nios34[m]>
It's around 60M. So I guess just give it 128M maybe better?
<travmurav[m]>
Depends how much bss is there and if it expects to allocate more I guess
<travmurav[m]>
I think the pil driver had the size and alignment in the ini file
<Nios34[m]>
a bit sucks, don't know if it's locational
<travmurav[m]>
William Goodspeed: oh actually
<travmurav[m]>
Do you have 2g where you are?
<travmurav[m]>
Or 3g I guess
<Nios34[m]>
Probably not. 2g is deprecated and nolonger in service here
<travmurav[m]>
I think it may only be able to call/sms on 2g/3g
<travmurav[m]>
I guess umts is 3g
<travmurav[m]>
So the laptop can't 2g at all
<Nios34[m]>
Does acer aspire have modem
<travmurav[m]>
Not my sku sadly
<travmurav[m]>
But there is a sku with modem
<Nios34[m]>
btw, does it get readings from pmic rtc?
<travmurav[m]>
travmurav[m]: I think the volte support is still wip and idk about sms over lte at all
<travmurav[m]>
Since on 2g 3g they're dedicated service and on 4g there is only data
<Nios34[m]>
Enabling pmic rtc gives a weird time and can't set rtc
<travmurav[m]>
William Goodspeed: rtc set is blocked by tz
<travmurav[m]>
Time is epoch start + pmic uptime
<Nios34[m]>
travmurav[m]: That explains... 3G is also closed by my ISP
<travmurav[m]>
So I guess still have a chance for the glorious calls without sound xD
<Nios34[m]>
Hum, so no rtc?
<travmurav[m]>
Well you need to store the offset
<travmurav[m]>
so like it will tick properly but you need to add a correct const to it
<travmurav[m]>
In pmos we have swclock-offset for that
<travmurav[m]>
I believe windows saves offset in a efivar
<travmurav[m]>
William Goodspeed: so could probably enable the efivar driver (will be read only) and wire rtc up to use that, iirc the efivar thing was added to the rtc driver at some pint
<Nios34[m]>
that's complicated. I will live with NTP for now
<Nios34[m]>
What about other peripherals like webcam and speaker 🤔
<travmurav[m]>
William Goodspeed: looks very USB to me
<travmurav[m]>
This ribbon cable won't run csi for sure
<travmurav[m]>
So probably some power gpio needs to be tied up or something like that
<travmurav[m]>
This is probably USB, power and dmic clk/dat
<travmurav[m]>
Would account for all 6 wires
alfredo has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
<Segfault[m]>
hmm, my venus troubles with the x13s continue lol
<Segfault[m]>
on 6.11-rc3 using the patches from jhovold's 6.11-rc1 tree if i try to play back a video using gstreamer and v4l2m2m i get this error in the kernel log `video_cc_mvs0_clk status stuck at 'off'` and gstreamer errors out
<jhovold>
Segfault[m]: I've seen something like that as well with 6.11, likely yet another regression
<jhovold>
I think someone else reported this here a few weeks ago
<Segfault[m]>
fun
<Segfault[m]>
for whatever reason ffmpeg still causes a hard reset, i'm not even sure how it could do that since it works fine on like rpi's and stuff
<jhovold>
yeah, I believe we reported the reset to konradybcio years ago by now
<jhovold>
but that was just with some unsupported format, or are you seeing it more generlly now?
<Segfault[m]>
if i just decode in ffmpeg i get a bunch of errors about invalid output, presumably because of the regression, but it doesn't reset
<Segfault[m]>
i seem to only be getting the reset if i try to use encoding in ffmpeg
<jhovold>
according to my notes, the (previous) hard reset only happened when transcoding with 'format=nv12'
<Segfault[m]>
yeah that seems to be it, although that's the only config i can actually test encoding with at the moment
martiert_ has quit [Quit: WeeChat 4.3.5]
<jhovold>
so known old issue, and noone is currently working on upstreaming venus support for the x13s
<Segfault[m]>
that's a shame
<jhovold>
perhaps you can try to reproduce it on some platforms that's already supported upstream
<Segfault[m]>
did getting the remoteprocs working with slbounce ever go anywhere?
<jhovold>
no, i don't think so
<travmurav[m]>
I haven't looked into it since the last time and I believe no one else even attempted anything
<Segfault[m]>
i tried venus on an sc7180 chromebook but that's totally borked in a different way, it doesn't hard reset but it seems to never send any frames
<travmurav[m]>
(last time == boot fsm reported the core has booted but hexagon never fetched any ram)
<travmurav[m]>
venus is not qdsp though so it actually can be booted in el2
<travmurav[m]>
I have it working on 7c
<travmurav[m]>
fwiw I think I had venus working fine on decode
<travmurav[m]>
at least it definitely works to decode hevc in moonlight
<travmurav[m]>
(and actually provides measurable benefit in cpu usage and power usage)
<jhovold>
works fine here too on sc8280xp / x13s, except for the format Segfault is trying to use
<jhovold>
and whatever regression was introduced in 6.11
<jhovold>
probably just need to block that format somehow
<jhovold>
or just don't try to use it ;)
<Segfault[m]>
what format are you using? if i don't set one it just complains that it needs to be nv12
<jhovold>
I've only done some basic testing, but playback works fine
<Segfault[m]>
oh yeah i had playback working at least in gstreamer before the regression
<Segfault[m]>
i don't recall whether it worked in ffmpeg but i assume it should
iivanov has quit [Remote host closed the connection]
<Segfault[m]>
travmuravdid you have it working on a 7c chromebook or windows machine?
<travmurav[m]>
Segfault: I only have a woa laptop
<jenneron[m]>
<Segfault[m]> "i tried venus on an sc7180..." <- venus worked for me on 6.1 at least
<travmurav[m]>
but if you mean venus, venus in el2 == venus on cros I'd say
<travmurav[m]>
though there shouldn't be much difference
<Segfault[m]>
that's probably why, i can't remember where i read it but apparently venus on the sc7180 chromebooks specifically doesn't work properly
<Segfault[m]>
i'd check again just to make sure but i broke the install on my tablet and haven't gotten around to fixing it yet lol
martiert_ has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
weirdtreething_ has joined #aarch64-laptops
weirdtreething has quit [Ping timeout: 480 seconds]
weirdtreething_ is now known as weirdtreething
hexdump01 has quit []
hexdump0815 has joined #aarch64-laptops
<hexdump0815>
nios34: travmurav[m]: i still have your backlight gpio changes in mind - problem right now is that i have no time to work on imagebuilder right now due to real life topics
<hexdump0815>
nios34: travmurav[m]: it looks like things are getting better end of the year
<hexdump0815>
nios34: do you have your current dts/work somewhere online? if not, could you please put it somewhere online on some git, so that i can pull it into the imagebuilder once i find some time
alfredo has joined #aarch64-laptops
<jenneron[m]>
Segfault: do you mean encoding or decoding?
<jenneron[m]>
i tested sc7180 chromebook decoding during packaging of moonlight-qt to alpine
<Nios34[m]>
<hexdump0815> "nios34: do you have your current..." <- Sure, I will make a pastebin later ;-)
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
<Segfault[m]>
ok i got the tablet going again, decoding on the sc7180 does seem to work fine after all, just encoding in ffmpeg hangs forever
* travmurav[m]
has never ever seen venus encoding working
alfredo1 has joined #aarch64-laptops
alfredo1 has quit []
alfredo has quit [Ping timeout: 480 seconds]
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
<Segfault[m]>
tbh i wouldn't be surprised if the issue was the same on both socs and the sc7180 just isn't rebooting because it's in el2
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]