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)
<bamse> Dylanger: looks correct to me
<bamse> i mean the order of those pieces
<steev> they (manuf) get angry when you do that kinda stuff though and release info on it because it can affect android handsets. someone figured out you could use the odroid c2's bootloader with samsung phones and.... now you have to use a signed bootloader on the odroid c2 :(
<steev> i do wish i could redo the wifi firmware on the c630, mostly because i want monitor mode, and monitor mode makes it *very* angry
<Dylanger> This is where Chromebooks are actually awesome, their current ethos with Chromebooks is open everything, they're designed to be hacked on, the EC is open, firmware, mostly everythinh
<Dylanger> It makes sense for Google to close/require firmware signing for the modem because someone could byte-patch it to do something that brings down public infra
<Dylanger> But, they only closed/required signing for that specific part, and nothing else
<Dylanger> I'm super happy with that
<Dylanger> The Qualcomm 7c Platform is what Qualcomm should be using in all of their devices
<Dylanger> Their "IP" ends up becoming added complexity and attack surface
<Dylanger> SoCs work well when they largely stay out of the way of developers
<robclark> +1
<HdkR> I need bigger SoCs than 7c though :>
<Dylanger> I think it's coming, Dr. Lisa surely has something up her sleeve
<Dylanger> Given her history with ARM too
<HdkR> Still waiting for some Ampere Siryn devices to show up
<steev> the problem is.... their keyboard, give me a real keyboard please
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
pundir has quit [Remote host closed the connection]
pundir has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
iivanov_ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
macc24 has joined #aarch64-laptops
<macc24> hexdump0815: resume is "working" for me, Dylanger uses same kernel and config
<steev> macc24: with rootfs on usb?
steev has quit [Read error: Connection reset by peer]
steev has joined #aarch64-laptops
dianders_ has quit [Remote host closed the connection]
dianders has joined #aarch64-laptops
iivanov has quit []
iivanov has joined #aarch64-laptops
iivanov has quit []
iivanov has joined #aarch64-laptops
minecrell has quit [Quit: :( ]
minecrell has joined #aarch64-laptops
minecrell has quit [Quit: :( ]
minecrell has joined #aarch64-laptops
<macc24> steev: i haven't checked
elder_ has quit [Read error: Connection reset by peer]
robclark has quit [Ping timeout: 480 seconds]
arnd_ has quit [Read error: Connection reset by peer]
robclark has joined #aarch64-laptops
broonie has quit [Ping timeout: 480 seconds]
arnd_ has joined #aarch64-laptops
elder_ has joined #aarch64-laptops
broonie has joined #aarch64-laptops
<robclark> hexdump01: try also plugging in a wakeup capable device (like a keyboard).. I bet that "fixes" the problem with suspend when you have rootfs on usb..
<bamse> suspending with the rootfs on usb stick sounds adventurous
<macc24> i mean
<macc24> the device isn't even powered off on trogdor iirc
<macc24> so it should work???
<macc24> got an essay for tomorrow, can't test anything today tho
<bamse> ahh nice, then it should be fine
<robclark> I thought we wrote a driver for the hub/mux thingy to power it down when there are no wakeup capable usb devices attached to save some power.. maybe we didn't get around to that yet?
<bamse> i thought that it was powering down and the patches that are being worked on would keep it alive
<bamse> or perhaps the hub will keep the stick alive, but we power down the dwc3
<bamse> i.e. we're still lacking those patches
<robclark> hmm, ok.. that could be true? I didn't follow that discussion too closely, but I remember there was some talk about that
<steev> this bluescreen
<bamse> steev: i bet there were curse words in that sentence before it hit the keyboad
<bamse> keyboard*
<steev> maybe a few
<steev> usually it's more cursing myself for not having the skills to figure out what is causing it to actually help
<steev> just need the stars to align so i don't get the bluescreen and also do not get an underflow on the soundwire so i have working video and audio
<bamse> perhaps i've been pulling enough hair over the clock/power issues i'm having on 8cx to actually be of some assistance with the bluescreen soon
<steev> i saw the trion patch earlier :D
<bamse> yeah that's one of them
<robclark> so, these days we should in theory we should get a dpu devcore dump if there is an underflow.. send that to abhinav who could maybe figure out something from that?
<bamse> the other one is that when dispcc probes, we undervolt the plls just for a fraction of a second
<steev> that doesn't sound good
<steev> there we go
<steev> robclark: oh this is soundwire underflow, so audio, not video :D
<steev> srini already knows and is working on it afaik
<robclark> yeah, but blue screen sounds like some sort of underflow.. or at least something that should (hopefully!) trigger a dpu devcore dump
<steev> i really don't wanna look into troubleshooting it until the clocks are in order
<steev> iirc that's what abhinav also thought last time we were looking into it
<robclark> oh, ok
<steev> it's the same issue that started happening often with 5.13 - i did have it happen like, 1 time on 5.12 which surprised me
<steev> and then after those issues are fixed... a proper battery so that waybar stops thinking i'm plugged in all the time and the battery is 100%. not sure what is going on there
<gwolf> steev: Do you get that in the C630?
<steev> gwolf: get what?
<gwolf> Battery measurement is one of the issues I've never suffered with it...
<gwolf> the unqueriable battery
<steev> oh, this is something with the way waybar checks on the battery, afaik, it doesn't use upower
<steev> xfce/gnome do
<gwolf> Oh, right! I wrote a simple script to get that information instead of Waybar's
<steev> i should do that
<steev> but i'd rather have a proper driver so it isn't needed :D
<gwolf> I'll paste it to you later (the laptop is downstairs...)
<gwolf> of course!
<steev> no rush at all
<steev> i know i have plenty of battery time remaining
<gwolf> (-: good thing about aarch64-laptops
<gwolf> FWIW, I haven't yet updated to 5.15... Will try to do it soon™
<steev> i added a patch to upower to somewhat properly recognize when the power is unplugged
<steev> it's still not perfect, but meh
<steev> oh wait, no i didn't
<steev> i forked it but never added it
<steev> gwolf: oh, silly me, i can just force it with '"bat": "some-battery", "adapter": "some-adapter",' in the config
<gwolf> Right, I use those values as well
<gwolf> so... didn't I rewrite _that_ script?
<gwolf> (I rewrote parts of Waybar's functionality to better match my tastes, maybe it wasn't battery)
<steev> that's just built in to waybar, but maybe you did
* gwolf scratches head
<gwolf> will check later (-:
<steev> wouldn't mind seeing what you have
macc24 has quit [Ping timeout: 480 seconds]
<steev> gwolf: also, i'm looking forward to the next waybar release, since apparently it's getting include support, so i can include things per host like i do with sway
<gwolf> steev: Just about to enter my class, so I won't be around much longer...
<steev> enjoy
<gwolf> I don't remember why I didn't use the "main" battery waybar thingy
<gwolf> https://paste.debian.net/1220589 for my battery_status script