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
chrisl has quit [Ping timeout: 480 seconds]
shoragan has quit [Read error: Connection reset by peer]
shoragan has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
shoragan has quit []
shoragan has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<clover[m]>
13 inches is such a great form factor
<clover[m]>
I think the x13s is a bit more than 13 maybe like 13.3 inches?
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<angeloverlain[m]>
<JensGlathe[m]> "anthony25: This one I guess..." <- I thought you also had a tree ?
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<JensGlathe[m]>
Yes, mine was based on Johan's. Currently (*) on sgerhold's which was based on Johan's. When I start doing 6.17rc, it will be the mentioned one plus.
<SpieringsAE>
same, now I just have the regular kernel plus whatever I find interesting for the asus vivobook in particular. Though I hope that when I get these latest display things merged I can just start running mainline
<SpieringsAE>
ayy video clock controller just got fully applied
<SpieringsAE>
Hmm, x plus or elite? I've not really had any usb issues with the kernels that I've built, I've not had it overheat yet, but given the fans barely spin it is not entirely unlikely to happen
<SpieringsAE>
yeah the function keys are weird, somebody here made a bpf program to get more of them working, didn't try that out yet
<SpieringsAE>
keyboard rgb is very likely part of the embedded controller so yeah...
<SpieringsAE>
Can't really say I notice anything weird about low brightness, but I am very bad at judging that sort of stuff
SpieringsAE has quit []
SpieringsAE has joined #aarch64-laptops
<angeryboi[m]>
X elite
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
Ariadne has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
<jdb[m]>
I've had this issue of adb working on one USB port but not on the other one, on the X13s
icecream95 has joined #aarch64-laptops
<jdb[m]>
With the 6.16 kernel from Debian Experimental, I've also discovered that I need to unplug and replug my dock to get the external screen detected on cold boot (X13s too)
<icecream95>
angeryboi[m]: Yep, I've noticed the display weirdness, and so mostly keep it at maximum brightness, using a shader to adjust apparent brightness (this also reduces 240Hz flicker)
<jdb[m]>
And if I unplug the external screen when the device is in sleep mode, opening the lid wakes the device but it still believes that the external screen is here -> it's tricky to fix when you've set the primary as the external one :-) Hopefully I'm running Xorg so I could type a randr command
<icecream95>
The display also seems a bit weird in Windows, so in some games it is really hard to see anything...
Ariadne has joined #aarch64-laptops
Ariadne has quit [Remote host closed the connection]
<jdb[m]>
So there are still a few wonky issues with the USB ports
Ariadne has joined #aarch64-laptops
<angeryboi[m]>
My biggest issue from the list is inability to charge the laptop, other issues are more or less manageable
<angeryboi[m]>
(Maybe a dedicated charge port is not so bad, huh)
<icecream95>
For charging issues, do you have adsp firmware copied over from Windows?
chrisl has quit [Ping timeout: 480 seconds]
<icecream95>
For the display, it also seems that the red channel has a different response time to green and blue at low brightness, and very dark but not true black backgrounds are not uniform across the display, which are both a bit distracting, but I assumed that it might just be inherent to OLED
<angeryboi[m]>
icecream95: I ran the firmware utility for firmware, so I assume so.
harrisonvanderbyl has joined #aarch64-laptops
ravikant_ has joined #aarch64-laptops
<harrisonvanderbyl>
Yay, got the UFS working on the sp12, can now actually ditch the USB drive now ahhah, now I think the only thing left is the audio, ubc-hdmi, and fixing a couple odd gpios
<icecream95>
angeryboi[m]: huh. dmesg output might be useful
chrisl has joined #aarch64-laptops
<angeryboi[m]>
If dmesg still has logs for firmware tool at this point
<JensGlathe[m]>
harrisonvanderbyl nice
<JensGlathe[m]>
The 2 weeks are almost over now
<JensGlathe[m]>
And UFS, although not used often, is good to have working example
<harrisonvanderbyl>
Yeah, luckily found some working snippets from the magicbook dts, there's at least 3 devices that would benefit from the UFS node
<jdb[m]>
harrisonvanderbyl: very nice indeed! Did you have to include non-mainstream patches or was it a matter of enabling UFS in your devicetree?
<harrisonvanderbyl>
No extra upstream, just a matter of porting some devicetree stuff and wasting time not understanding how things work
<harrisonvanderbyl>
Actually hmm
<harrisonvanderbyl>
I am based of JensGlathe kernel
<harrisonvanderbyl>
And I did end up enabling qcomufs in the config
<jdb[m]>
angeryboi: no need for the firmware tool log, just the regular log will tell if the adsp firmware Is properly loaded on boot or missing from its expected location on the filesystem
chrisl has quit [Ping timeout: 480 seconds]
<jdb[m]>
I remember I had to add a script on boot to enable its proper activation btw
<harrisonvanderbyl>
Asap and cdsp and purwa need a patch to work on some devices that's not on mainstream
<harrisonvanderbyl>
I think
<harrisonvanderbyl>
It's in Jen's repo tho
chrisl has joined #aarch64-laptops
<jdb[m]>
You can try one of these 2 manual commands:
<angeryboi[m]>
I couldn't execute either of these commands as I need to setup root account, but idk what changed as charging works now, I checked dmesg and adsp seems to start properly, maybe it's a different issue. Could be something to do with sleep and/or overheating.
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
Re weird brightness issues: There is a [regression](https://github.com/jglathe/linux_ms_dev_kit/issues/46) due to a T14s hack for OLED that needs to be removed. 6.16-el2-jg-2 is the first of my kernels that has it removed.
longptr has quit [Ping timeout: 480 seconds]
longptr has joined #aarch64-laptops
<jdb[m]>
Great if charging works!
chrisl has joined #aarch64-laptops
<angeryboi[m]>
Also, I know why the laptop might overheat
<angeryboi[m]>
If OS goes to sleep while charging, fans will stop spinning
<angeryboi[m]>
And considering keyboard rgb doesn't turn off either, it could be some weird state the laptop ends up in
harrisonvanderbyl has quit [Quit: Connection closed for inactivity]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
KREYREN_oftc has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
ravikant_ has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
ravikant_ has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<erebion_muc>
Anyone else having issues with the X13s with key presses occasionally not being recognised for a a couple seconds and the mouse (touchpad/trackpoint) sometimes not being able to click anythng for maybe a minute and then just working again..?
chrisl has quit [Ping timeout: 480 seconds]
<erebion_muc>
I often have to press enter around 20 times before it reacts
<erebion_muc>
And the 3rd keyboard layer with Alt Gr has stopped working
<erebion_muc>
6.12.38+deb13-arm64
<erebion_muc>
Debian Issue or Kernel Issue?
chrisl has joined #aarch64-laptops
<jdb[m]>
Not so far for me. However I've moved on to more recent kernel versions from Experimental, 6.15 for a while and now 6.16 for a few days
<krzk>
erebion_muc: that's quite old kernel, so first advice is try to reproduce it on something recent
chrisl has quit [Ping timeout: 480 seconds]
<glu>
speaking of x13s, did suspend/resume support improve recently?
<JensGlathe[m]>
Working fine for me for a long time now. Only thing out of line is WWAN having issues after suspend
Kelsar has joined #aarch64-laptops
<erebion_muc>
Update: I had a stuck backspace key -.-
chrisl has joined #aarch64-laptops
<erebion_muc>
So if anyone else has issues with keys, try removing and re-attaching them...
<glu>
but what about it not entering lower power states? last time i tried it worked (with flaws) but it would drain battery overnight still
craftyguy has quit [Read error: No route to host]
craftyguy has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
xeliteCJF has joined #aarch64-laptops
<tobhe[m]>
This is more likely not related to power states but individual power consumers not being turned off before "sleeping"
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
harrisonvanderbyl has joined #aarch64-laptops
<harrisonvanderbyl>
I found it doesn't detect charging if the glink USBs are set to "host", but if you set to "dual" then it can switch to allow charging (at least on sp12)
<JensGlathe[m]>
what
<harrisonvanderbyl>
In the device tree, in the section where the glink defines the USB section, where it has "role=X" if role is set to host, then it doesn't detect USBC charging, and just runs out of charge when plugged in, but if I change that to "dual" it detects that it is plugged in and charges
<JensGlathe[m]>
yeah I know, but there's a power-role and data-role
<harrisonvanderbyl>
i wonder how power-on-demand chargers get the voltage data from the device
<harrisonvanderbyl>
I moved all my stuff to the UFS, no more USB sticking out the side anymore :)
<harrisonvanderbyl>
I'll put through a pr for the UFS node
xeliteCJF has quit [Read error: Connection reset by peer]
paulk has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<bamse>
harrisonvanderbyl: in usb type-c you have a couple of wires where power-delivery (PD) messages are exchanged between the involved parties...
<bamse>
harrisonvanderbyl: they are used to establish who's sink and who's source, for data and for power independently
<bamse>
harrisonvanderbyl: in that process the source discloses what power levels are supported and the sink request a particular level - and can change that later if needed
<harrisonvanderbyl>
Would setting the data mode for the charger port as "host" in the DTS prevent that from taking place?
SpieringsAE has quit [Quit: SpieringsAE]
<harrisonvanderbyl>
Or is it just more that having the incorrect setting prevents a driver or two from booting correctly
<bamse>
setting the data mode shouldn't affect that, as you can have power and data go in different direction...
<bamse>
so i wonder if role=host tells the software that both data and power should be host/source?
<bamse>
without looking at the code, that would be my expectation
<clover[m]>
Got my archiso to boot today on the wdk2023!
<Jasper[m]>
Awesome stuff!
<Jasper[m]>
I still need to try and get some stuff running on mine
chrisl has quit [Ping timeout: 480 seconds]
<anthony25>
JensGlathe[m]: thanks for recommending the Linaro's branch, it works great!
<clover[m]>
Still a few things to iron out but should have a archiso release with including a new iso for volterra in the next day or so
chrisl has joined #aarch64-laptops
ravikant_ has quit []
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<bamse>
anthony25: is there anything in that branch that you actually need compared to v6.17-rc1 (well, there's a bug in the firmware loader there...but -rc2 should be good)
<anthony25>
Actually all the firmware bins are loading fine
<bamse>
anthony25: pacman -S linux-aarch64 or linux-aarch64-rc should work fine btw, that's what i run on my sc8280xp and x1 devices
<anthony25>
Oh wow ok, I'll try 6.16 when it'll ship on Tumbleweed
chrisl has quit [Ping timeout: 480 seconds]
harrisonvanderbyl has quit [Quit: Connection closed for inactivity]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<anthony25>
bamse: and to answer your question, there is the iris hw decoding that I'm applying on this branch
<anthony25>
and the EC driver for the slim 7x
<anthony25>
even if, about the hw video decoding, iirc someone here was saying that ffmpeg needs a patch to actually use it?
chrisl has joined #aarch64-laptops
<bamse>
anthony25: you're right, that's missing, and there might be some useful (sometimes critical) bugfixes carried there...
<bamse>
anthony25: last time i dabbled in venus/iris it needed to much userspace work to be something that was useful to me, but that's something that should change over time...as would the upstream enablement for the hardware
chrisl has quit [Ping timeout: 480 seconds]
<anthony25>
But overall it works pretty great, I could really switch from jhovold's branch to linaro's without seeing any regression
<anthony25>
So thanks a lot!
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<clover[m]>
Latest archiso release is OUT! We are now supporting a new device! (WDK 2023):
<clover[m]>
Big shoutout to jens glathe; his work with the ubuntu images made this possible for me
<krzk>
bamse: "is there anything in that branch that you actually " heh, I would start with the UEFI fix from Johan :).
<tobhe[m]>
yeah the UEFI fix was a game changer on my T14s. Totally unreliable without it
<krzk>
bamse: the other things is, as mentioned by anthony25, camera support (bod has also GPU ISP work coming)
<krzk>
bamse: also ongoing no-clk-ignore-unused work from Abel and several other commits from lists or from next
<krzk>
but running next daily is quite a risk... and collecting patches from list to rc7 - that's what the branch is doing :)
<bamse>
krzk: the uefi fix is certainly someone you want if you're on the t14s
<bamse>
krzk: but i would much rather see people run the upstream kernel, than random downstream trees - even if your random tree is well defined and maintained
<bamse>
krzk: i was under the impression that we got the camera stuff upstream, perhaps we're still missing some pieces? and the gpu isp should be a userspace affair
chrisl has joined #aarch64-laptops
<krzk>
bamse: It's not a random downstream tree, but something between mainline and next. The same as Johan's tree was and it was working great. You know there is a paradox of speed of kernel... is way too slow, patches are taking ages, but also way too fast to be reliable and to actually use it daily. :)
<krzk>
So if you want recent X1E work you would need to use next and that brings quite big risks for daily drivers (like me)
<krzk>
camera and ISP is missing a lot, slowly getting there but isn't even in the next now :/
<krzk>
and "why" is not in the next is different story :/
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<bamse>
krzk: but no-clk-ignore-unused isn't inbetween next and mainline, is it? (did i miss progress on this upstream?)
<krzk>
bamse: pieces of that, which are also on that branch, are in next, so counts here.
<bamse>
okay nice
<bamse>
and i agree with you, that next isn't for "users"
<krzk>
all the important patches - except some defconfig stuff - are from lists or next. Maybe that clock fix is not yet in next at current time, but could be anyday, because it is a reasonable fix which got reviewed.
<bamse>
okay, nice
reng_ has quit [Quit: Thanks!]
reng has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<angeryboi[m]>
Was gonna install element on laptop, but had to use fractal, because element doesn't render properly, anyone else have gpu rendering issues in apps, specifically electron/chromium?
<Jasper[m]>
Yes! ANGLE bug add --use-angle=gles when starting CEF and Chromium related things
chrisl has quit [Ping timeout: 480 seconds]
<angeryboi[m]>
I will say though, charging Asus vivobook s15 on linux makes it get waaayyyy hotter than on windows
<angeryboi[m]>
and fans are spinning
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<angeryboi[m]>
<angeryboi[m]> "I will say though, charging Asus..." <- nevermind, it was 2 uninstalled instances of element using my cpu heavily...
<angeryboi[m]>
CPU was at 76c, and already has dropped to 45c as of writting
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
\[m] has joined #aarch64-laptops
<\[m]>
Jasper angeryboi I thought it was an env var FORCE_GL_VENDER=notfreedreno
<clover[m]>
i forget how grub automatically finds the devicetree, does anyone know? it seems to work perfectly on x13s but on wdk2023 i have to explicitly add devicetree sc8280xp-microsoft-blackrock.dtb
<tobhe[m]>
flash kernel installs an update hook, whenever the kernel gets updated flash-kernel looks at /proc/device-tree/model, matches that against the db and then finds the new dtb to install on /boot
chrisl has joined #aarch64-laptops
<tobhe[m]>
that's what's being used on Ubuntu and probably Debian
<tobhe[m]>
for now
<tobhe[m]>
grub on Ubuntu in update-grub scans /boot for vmlinuz, initrd and dtb and creates a matching entry
<tobhe[m]>
I think Debian might be missing the dtb part
<tobhe[m]>
unfortunately grub is quite fragmented so basically every distro ships a different fork with varying support of commands/features
<clover[m]>
its weird cause in my grub.cfg i don't see any explicit dtb
<clover[m]>
im using arch on both machines
<tobhe[m]>
are you using dtlbloader?
<tobhe[m]>
s/dtlbloader/dtbloader/
<abby>
are you using the dtb-in-esp feature of the x13s?
<clover[m]>
just grub-mkconfig
<clover[m]>
oh yeah. i forgot about that
<clover[m]>
so x13s has a fancy feature wdk2023 doesnt have
<tobhe[m]>
heh then the answer is probably: it doesn't
<tobhe[m]>
both would also make it possible to build a single image that works on both devices
<\[m]>
robclark I don´t set the --use-angle=gles though and it works
chrisl has joined #aarch64-laptops
<robclark>
so it possibly depends on a combo of skia + angle + chromium version.. either skipping angle (since, why do we really need a gles on gl layer?) or overriding the vendor string so skia doesn't use the problematic code path in angle fixes/avoids the issue
<nirik>
--ozone-platform=wayland also seems to avoid it here... (obviously running a wayland session)
chrisl has quit [Ping timeout: 480 seconds]
<robclark>
hmm, interesting
<clover[m]>
the easiest fix is to add this line to /etc/grub.d/40_custom
<tobhe[m]>
keep in mind you might also want to update /boot/sc8280xp-microsoft-blackrock.dtb on kernel updates (not sure where it is installed by default in your case)
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
longptr has quit [Quit: Konversation terminated!]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<steev>
bamse: did you ever hear back about the firmware fix for 64GB?
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
harrisonvanderbyl has quit [Quit: Connection closed for inactivity]