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
<travmurav[m]> But need to find what to read obv
<Nios34[m]> qcbattminiclass850.inf_arm64_e4faeead58dc45ab
<Nios34[m]> probably this
<travmurav[m]> No
<Nios34[m]> but I have no idea what this is
<travmurav[m]> 850 is wrong soc
<travmurav[m]> And as I said I think it's just generic acpi
<travmurav[m]> So the "driver" is in dsdt code
<Nios34[m]> But It's... from Windows
<Nios34[m]> Other drivers are 7180 but this one is 850
<Nios34[m]> like how
<travmurav[m]> Otherwise it'd be "samsung" not "qc" I guess
<travmurav[m]> Well or I guess they did something very funny, samsung could of all companies I guess
<travmurav[m]> They actually knoflw a thing or two about designing around qcom things, their phone divisions sure does at least
<travmurav[m]> But I'd look at acpi first
<Nios34[m]> treexy.com says it's Qualcomm PMIC Battery Miniclass Device battery drivers: https://treexy.com/products/driver-fusion/database/batteries/qualcomm/pmic-battery-miniclass-device/
<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
<travmurav[m]> In windows
<Nios34[m]> lemme check
<Nios34[m]> There are: modemr.jsn modemuw.jsn qcmpss7180_BTU.mbn qcmpss7180_nm.mbn qcsubsys_ext_mpss7180.cat qcsubsys_ext_mpss7180.inf qdsp6m_BTU.qdb RAMS.bin
<travmurav[m]> Inside some inf file iirc
<travmurav[m]> William Goodspeed: also have you tried the nm one?
<Nios34[m]> Yeah, nm one works fine. I want to get the modem working.
<travmurav[m]> Ah cool
<Nios34[m]> ipa already boots so
<travmurav[m]> I guess you have wifi then?
<Nios34[m]> Yeah, I have wifi
<Nios34[m]> * have wifi (if booting `_nm`)
<travmurav[m]> Apparently someone just asked about it heh https://github.com/hexdump0815/imagebuilder/issues/136#issuecomment-2303926462
<Nios34[m]> Probably missed a firmware or something?
<travmurav[m]> But if wifi one boots I'd guess it's just something simple like ram size if it einvals
<Nios34[m]> WiFi works fine. My backlight thingy hasn't go into imagebuilder sadly.
<travmurav[m]> Someone should send that thing upstream :p
<Jasper[m]> that would be grimler :^)
<Nios34[m]> <Nios34[m]> "It's around 60M. So I guess just..." <- bruh, -22 with 128M
<Nios34[m]> Is the memory region address sensitive to the hardware?
<travmurav[m]> Sometimes
<travmurav[m]> But I think nowadays no
<travmurav[m]> Ad long as it aligned
<travmurav[m]> William Goodspeed: I think you can readelf the mbn to see if load address is 000
<Nios34[m]> travmurav[m]: I'm not sure: https://paste.debian.net/1327188/
<travmurav[m]> Uh
<travmurav[m]> And nm is 000?
<travmurav[m]> Or same?
<travmurav[m]> But I guess this might indeed be non-relocatable so ytneed to load it at 8600...
<Nios34[m]> I don't know how to interprete this tho
<travmurav[m]> Ugh weird
paddymahoney has joined #aarch64-laptops
<travmurav[m]> Hm
<travmurav[m]> William Goodspeed: it's over 140MiB
<travmurav[m]> at least 0x8c02000 bytes
<travmurav[m]> >>> -0x86000000 + 0x8ec02000... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/kGVzMYIPkKepqsPsaSDPYErQ>)
<travmurav[m]> (End of last section minus load address)
<Nios34[m]> lemme try make a space that dits
<Nios34[m]> s/dits/Fits/
<Nios34[m]> oh... I knew something
<Nios34[m]> It's mpss up and ModemManager detacted it
<travmurav[m]> Nice
<travmurav[m]> Oh so mm detected it as qcom-soc type?
<Nios34[m]> Yes
<travmurav[m]> I guess they enabled it in enable-all now, cool, it was excluded when we added it
<travmurav[m]> Nice
<Nios34[m]> ports: qrtr0 (qmi), rmnet_ipa0 (net)
<travmurav[m]> William Goodspeed: you can try sending an sms now I think
<Nios34[m]> firmware is so bloated. I gave it 0xa000000
<travmurav[m]> Oh I guess if you already setup ipa that could work too
<travmurav[m]> William Goodspeed: it was 80mib 10 years ago
<travmurav[m]> I told you 96 was too small xD
<travmurav[m]> William Goodspeed: but you will want to find the real size in the windows later to not waste ram
<travmurav[m]> William Goodspeed: also just in case but a friendly reminder that output of mmcli and friends may contain your phone number and imei
<travmurav[m]> travmurav[m]: I hope gnome-sms thing is packaged in what you're using xD
* travmurav[m] also wonders if calls would work
<travmurav[m]> Obviously without call sound like in the good old days
<Nios34[m]> travmurav[m]: also, but I need to figure out how to get it conneted
<travmurav[m]> Connected?
<Nios34[m]> I still remember --simple-connect or whatever
<travmurav[m]> I think it's just network manager button in ui nowdays
<travmurav[m]> And it does the magic
<Nios34[m]> oh it's already connected it looks like
<travmurav[m]> As long as mmcli -m any says it's good
<Nios34[m]> It's registered and packet service state attached
<Nios34[m]> rmnet_ipa0 is DOWN tho
<travmurav[m]> Do you have it in i.e. gnome settings?
<travmurav[m]> I think it should expose an ui to connect
<Nios34[m]> I'm running i3 so no gnome :-/
<travmurav[m]> Ah sad
<travmurav[m]> I guess simple connect stuff it is then xD
<Nios34[m]> Hum, does ipa need an IP
<travmurav[m]> May have to set it from what MM tells you, yes
<travmurav[m]> If network manager doesnt
<travmurav[m]> As in, network provided ip and gateway
<Nios34[m]> In mm, there is no ip in the bearer
<travmurav[m]> Maybe didn't connect?
<travmurav[m]> Does status say registered or connected?
<Nios34[m]> but it shows connected: yes
<travmurav[m]> Maybe something about apn too?
<Nios34[m]> Maybe I can try to force a route
<Nios34[m]> OK, got another bearer
<Nios34[m]> and qmapmux1.0@rmnet_ipa0 wth
<travmurav[m]> Probably a network iface slice foe that bearer
<travmurav[m]> On old things they just did 10 ifaces
* travmurav[m] 's qcom modem knowledge is stuck at 10yo platforms
<Nios34[m]> Tried to make a phone call: Couldn't create call: QMI protocol error (48): 'InvalidArgument'
<travmurav[m]> Sad
<travmurav[m]> I guess they might very disabled it
<travmurav[m]> * 've
<travmurav[m]> Would've been so fun though xD
<Nios34[m]> Also SMS won't work
<Nios34[m]> reducing the cost I guess
<travmurav[m]> William Goodspeed: nah this chip is same as in phones
<travmurav[m]> So probably just a software lock
<Nios34[m]> It does show a sim-pin2 lock
<Nios34[m]> But I don't think it's really there
<travmurav[m]> I think pin2 is always there
<travmurav[m]> But no one uses pin2 features nowdays at least where I am
<Nios34[m]> Holy shit
<Nios34[m]> It works
<Nios34[m]> Welcome to the Internet ;-)
<Nios34[m]> yep
<travmurav[m]> Data?
<Nios34[m]> that qmapmux0.0 is the actual gateway and there isn't any IP associated with it
<Nios34[m]> probably ipa took over something regarding that?
<travmurav[m]> William Goodspeed: I'd assume nm+mm automatically handled the ip/gateway
<travmurav[m]> But in any case nice
<Nios34[m]> Latency: 91ms Jitter: 31.4 Uplink: 8.75Mbps Downlink: 11.4Mbps
<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]> Is Webcam not USB?
<travmurav[m]> William Goodspeed https://gitlab.com/postmarketOS/swclock-offset
<Nios34[m]> travmurav[m]: No it's not
<Nios34[m]> Maybe it's on a line undefined idk
<travmurav[m]> William Goodspeed: sad I guess it's the fun with mipi camera and swisp then, not someting trivial sadly
<travmurav[m]> unless it's just power missing I guess
<travmurav[m]> and it's actually usb after all xD
<Nios34[m]> travmurav[m]: It has Windows hello so I guess it's not mipi
<travmurav[m]> hm
<travmurav[m]> interesting
<Nios34[m]> Could it be SPI 🤔
<travmurav[m]> but I guess it doesn't appear on usb at all?
<travmurav[m]> nah too slow for a camera
<travmurav[m]> as in for a webcam kind of a camera
<travmurav[m]> unless it's like 144p xD
<Nios34[m]> oh this thing
<travmurav[m]> William Goodspeed: could you remind me the fccid for the gbgo? I think I had it at some point but don't have in my notes
<travmurav[m]> maybe there is something in the teardown photos in fcc db
<Nios34[m]> I think there is a dedicated rtc on book go
<travmurav[m]> in the ec if anywhere I guess
<travmurav[m]> aspire1 also has a battery but I couldn't find how to read the time anywhere
<travmurav[m]> and the acpi seems to use the rtc in the pmic
<Nios34[m]> It's from dsdt, can't tell which EC this is but it's an i2c device
<travmurav[m]> William Goodspeed: that """i2c""" might be spmi for the qcom's pmic
<travmurav[m]> pmap is pmic I think
<travmurav[m]> aspire1 has the same node, it's the pmic rtc I believe
<Nios34[m]> But it looks like Set Real Time also doing an i2c transfer? 🤔
<travmurav[m]> William Goodspeed: can try `allow-set-time;` but it didn't work for me
<travmurav[m]> so might be just writing to nowhere and ignored later
<Nios34[m]> Hum, could one access that i2c bus from i2ctransfer?
<travmurav[m]> if it's pmic it's not i2c but spmi
<travmurav[m]> and qcom just reused the i2c functions because thye exist already
<Nios34[m]> ah
<travmurav[m]> well in any case this seems like something specific to qcom's pmic
<travmurav[m]> maybe it even goes into a software mailbox that saves the offset into said efiar
<travmurav[m]> yes I think it goes into the PEP driver code after a quick look
<travmurav[m]> so it's just fake clock api I guess
<Nios34[m]> Yeah, that address is reserved. So it's not an actual i2c devixe
<Nios34[m]> <travmurav[m]> "William Goodspeed: could you..." <- I don't have the FCC ID 🧐
<travmurav[m]> Sad
<Nios34[m]> panel and webcam are connected by a split cable and to the socket on the board
<travmurav[m]> Is it clear how many wires camera has?
<Nios34[m]> I cracked the panel once so I teared it apart once
<travmurav[m]> I.e. mipi would have 3+ diff pairs
<travmurav[m]> But USB only one pair
<Nios34[m]> travmurav[m]: lemme disassemble it
<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]> `[h264_v4l2m2m @ 0xaaaad9623790] Encoder requires nv12 pixel format.`
<jhovold> and I've verified the reset with nv12
<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]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
Erisa has quit [Quit: The Lounge - https://thelounge.chat]
Erisa has joined #aarch64-laptops
rz_ has quit [Ping timeout: 480 seconds]
alexeymin has quit [Ping timeout: 480 seconds]
jhovold has quit [Ping timeout: 480 seconds]
alexeymin has joined #aarch64-laptops