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
freekurt[m] has joined #aarch64-laptops
<freekurt[m]>
So the unofficial Signal Desktop app is doing the same strange visual stuff that Chromium was doing. What is the reason for this again?
kalebris has quit [Remote host closed the connection]
kalebris has joined #aarch64-laptops
<zdykstra>
Nice!
<alexVinarskis[m]>
I discovered that fixing blurry electron apps (happens when on wayland+fractional scaling) also fixes this recent visual bug, tested with Vivaldi and Vscode. Run executable with extra args --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland.
<tobhe[m]>
so that suggests it is an xwayland only issue?
icecream95 has joined #aarch64-laptops
<icecream95>
Not related to xwayland, but rather that Chromium defaults to using GLES with Wayland
<tobhe[m]>
ah makes sense
<icecream95>
Well using a different rendering API depending on the windowing system is behaviour that doesn't make sense...
<HdkR>
Chromium doesn't always make decisions that make sense :D
nashpa has quit []
dliviu has joined #aarch64-laptops
ravikant_ has quit [Ping timeout: 480 seconds]
<anthony25>
how different is the T14s EC from the slim 7x' one?
<bylaws>
It's a different ec
<bylaws>
It has the slim 7x one also
<bylaws>
Both are used for different things
<bylaws>
(albeit I'm not sure what the 7x one does, it's definitely present tho)
<anthony25>
<bylaws> It has the slim 7x one also << what do you mean?
<bylaws>
It has two ECs
<anthony25>
I'm asking because I'm using the EC driver that mac wrote, but it's not upstreamed, and I was wondering if the t14s and slim 7x drivers could use a common ground
<icecream95>
wow, enabling "Prefer colour accuracy" in the KDE display settings quite significantly changes the look for the Vivobook OLED. There's also a "sRGB Colour Intensity" slider now, but even at the minimum setting I find the display far too saturated... I usually use a shader hack to set the saturation to just 50%
<maz>
has anyone ever looked at the Neo 50q thing? it seems you can actually buy it...
bryanodonoghue has quit [Excess Flood]
bryanodonoghue has joined #aarch64-laptops
<Jasper[m]>
It's on my list of potential buys, but I have a car repair coming up that may be a bit gnarly
<maz>
Jasper[m]: yeah, similar "hack" budget issues. if only I knew for sure a serial console was accessible on it, I'd pull the trigger.
<Jasper[m]>
Looks more interesting of a proposition than the WDK2023 though. Same RAM, quicker SoC, more PCIe and storage.
<Jasper[m]>
Sad they never put the 10 or 12-core socs into anything, but the illfated devkit
<Jasper[m]>
Geekom also never released anything
<jdb[m]>
More PCIe? What do you mean?
<Jasper[m]>
Double m.2 slot and wifi is on a separate card
<jdb[m]>
Interesting, I hadn't realized they would put a double m.2 slot
<Jasper[m]>
There's also the cursed optional port system, can use VGA on these if you want
abelvesa is now known as Guest25525
abelvesa has joined #aarch64-laptops
HdkR has quit [Remote host closed the connection]
<\[m]>
maz if from lenovo or whatever, you can send it back in 2 weeks easily
<\[m]>
I've done so for the thinkbook just now, very smooth and also completely normal, if the product is not up to par to expectation imo
<maz>
\[m]: I'm not sure cracking it open is part of that guarantee...
<Jasper[m]>
Is in the EU
<maz>
I wish I still was in the EU...
paulk has quit [Ping timeout: 480 seconds]
<\[m]>
uuuh indeed from private entities, that's confirmed to not quite be appreciated 😆
<\[m]>
but e.g. at bluelink, within the return period they did offer to just take of a small % and I could return and they'd sell it in the outlet section
<\[m]>
so there's some play there too
<\[m]>
I'm not sure if a law changed that now we can "void warranty" or whatnot but damn it's a relief that it seems to be in part?
<Jasper[m]>
Oh wait, disassembly? Yeah that might be a slightly different story
<maz>
that's the thing: if I get this device, I'll start by probing the test points looking fro a UART. if I don't find it, the box is of no use to me...
<maz>
on the devkit, it was just a matter of plugging a uUSB cable on the PCB. still voiding the warranty, but hey... ;-)
<zdykstra>
The Neo 50q looks fantastic, damn.
paulk has joined #aarch64-laptops
<krzk>
That's the same chassis as their previous ultra compact pcs, they have ithem for some years
<krzk>
Just remember this might warm a lot...
<Jasper[m]>
krzk: Shouldn't be too bad with these. They only ship with the lower tier purwa 8 cores "Snapdragon X"
<zdykstra>
I have a bunch of their 7th and 8th Gen Intel Tiny PCs, they're stellar. 2x m.2 and a sata port - or even a pcie slot for a small card!
<Jasper[m]>
Yep same, got 3, need to get rid of the 7th gen one
<\[m]>
I guess the heathing is because you'd probably want to compile on these instead of your own laptop and honestly
<\[m]>
I don;'t want to do it anymore lol I can almost burn myself
<\[m]>
but I think thermal throttling might be finnicky for any of the "models"
<\[m]>
or you use them as small workstations?
<krzk>
indeed, the problem for me is that 32 GB is too small amount for proper workstation or build server
<krzk>
but yeah, for that form factor looks not so bad
<maz>
a build server with only 8 CPUs seems a bit on the small side...
<Jasper[m]>
\[m]: Use mine for a router and another possibly for a LAN rig
<krzk>
maz: if this was x1e80 or 78 with proper cooling then it would not be a problem :)
<krzk>
But yeah, what would be the usecase for it...
<SpieringsAE>
maz: still nice for low cost arm native stuff though, currently I bring my laptop to work everyday to sometimes compile some stuff natively on arm debian. Would be nice to have a box like this at the office instead
<Jasper[m]>
That^ I also don't think there's better acquireable ARM devices that are rackable except for maybe Mac Mini's
<Jasper[m]>
(I meant to point at @krzk's message)
<SpieringsAE>
can just stuff it in a closet somewhere and ssh into it
<SpieringsAE>
though it would probably live on my desk next to the NAS
<\[m]>
I saw that truenas is supporting unoffically arm64 now
<\[m]>
opnsense not yet I believe
<maz>
SpieringsAE: no question about that. this looks similar to some of the mac mini stuff I'm using, given that the M1/M2 line has run its course, and that M4 is not supported, I'm looking for the next "small box" I can use. but UART is pretty mandatory...
<SpieringsAE>
yeah understandable
<krzk>
For similar price you could geet ThinkCentre Neo 50q Gen 5 (Intel i3) with 64 GB RAM, for +200 EUR version with faster Intel 5 210H and 64 GB RAM
<krzk>
So you would really need native arm64 or save electricity bill to choose it :)
<SpieringsAE>
krzk: jeah the native arm thing, makes life easier
<maz>
I've gone native 6 years ago, and I'm not going back to x86...
<SpieringsAE>
definetly not gonna compile on our 4x a53 platform lol
<SpieringsAE>
got a new rk3588 box at home, it can compile some stuff, but kernel level, just too weak
<SpieringsAE>
spent a morning compiling plasma-bigscreen on it this weekend lol
<SpieringsAE>
wouldn't be that big of a deal on its own, but that kde-builder tool also had to compile 98 dependencies
SpieringsAE has quit [Remote host closed the connection]
abelvesa has quit [Remote host closed the connection]
Guest25534 has quit [Remote host closed the connection]
<\[m]>
somehow it feels all their products remain dev boards in a way imo
abelvesa has joined #aarch64-laptops
<JensGlathe[m]>
sort of. Mine was sold very early, before the tariff-o-mania. Bringup was ultrasmooth with debian, and all peripherals worked (what a concept). It developed quite a bunch since, need to finish the build eventually.
<JensGlathe[m]>
Oh and CIX boots up on EL2, yeah
<\[m]>
I have mesa 25.0.7 installed
<\[m]>
Jens Glathe the orion board?
<JensGlathe[m]>
yes
<kalebris>
I see that there is no movement on the 6.17 in the usual repo. Did i miss something? Is the progress here going to slow down considerably?
<Jasper[m]>
If Mark can also look at the x13s that would be cool
<\[m]>
so what is venus / iris
<\[m]>
isn't venus an arm64 cpu codename? and iris is the intel gpu or ?
<\[m]>
baseline is no gpu can be dedicated or somethign?
Lun[m] has joined #aarch64-laptops
<Jasper[m]>
In Qcom context it's the driver/silicon bits that do hardware video acceleration
<Jasper[m]>
In other contexts it's uhhh an Intel GPU brandname and a lady razor brand
<JensGlathe[m]>
radiating reputation all over the place
hightower3 has joined #aarch64-laptops
<anthony25>
<Jasper[m]> In other contexts it's uhhh an Intel GPU brandname and a lady razor brand << it's a sharp codename
<anthony25>
:}
<robclark>
iris and venus are both names of drivers in mesa, as well
<JensGlathe[m]>
... but different?
<robclark>
iris is the intel gallium (rusticl/gl) driver.. venus is a para-virt vk driver
<JensGlathe[m]>
different. I guess the people using these names are in completely different groups otherwise this would be interesting
<Jasper[m]>
I had not thought of the consequences of that
<robclark>
it made things interesting on CrOS since video accel and gpu were part of the same larger team, so meaning of iris or venus was totally context dependent
ravikant_ has quit []
<\[m]>
so no venus drivers (the arm soc gpu) in linux at large? correct?
<JensGlathe[m]>
there are afaik. Like iris
<robclark>
if you are talking about vidc (not gpu) there are v4l2 mem2mem drivers for both iris and venus
<valpackett>
re: high opp mentioned by anthony25 and robclark above, i'm pretty sure the supported-hw 0x03 refers to the X1E-84-100 and -00-1DE. these 2 are listed as having a 4.6 TFLOPS GPU on the qcom website
<robclark>
could be.. I'm not 100% sure of the fuse values vs sku's
<valpackett>
i wonder if "overclocking" the 80-100 would be possible tho xD
lynxy has quit [Remote host closed the connection]
lynxy has joined #aarch64-laptops
<\[m]>
> iris is the intel gallium (rusticl/gl) driver.. venus is a para-virt vk driver
<\[m]>
this stuff?
<\[m]>
I'm confused
HdkR has joined #aarch64-laptops
HdkR has quit [Quit: Changing server]
HdkR has joined #aarch64-laptops
<kuruczgy>
What's the status of camera support on x1e on 6.17-rc* right now, what patches are needed? (As I see ov02c10 is upstream, so I guess devicetree patch, and what else?)
<kuruczgy>
Also, any update on the libcamera issues? (The camera being green and flickery, at least on the slim7x)
kbingham[m] has joined #aarch64-laptops
<kbingham[m]>
Camera being green requires camera tuning. ... which mostly requires being able to manipulate the CCM (Colour Correction Matrix) - which is a really expensive operation in CPU. ... we have a GPU ISP now posted at v2 on the list - and further being developed. Once that's in - colour correction will become more capable using GPU processing.
<kbingham[m]>
For the flicker - it's a known bug ... I have one path to working towards fixing it in progress - but it's been a huge rabbit hole (https://git.uk.ideasonboard.com/kbingham/libcamera/pulls/18) ... a fix in the current AGC algo might also be possible. Locally I just hardcode/fix the gain to stop the flicker.
<sre>
\[m]: there is no venus arm soc gpu. There is a venus video codec, which can be found on Qualcomm SoCs. It has a kernel driver which lives in drivers/media/platform/qcom/venus . Apart from that there is a virtio-gpu driver also named venus. It has nothing to do with the Qualcomm video codec thing.
cyrinux949075 has quit []
<Treibholz[m]>
Kieran Bingham: is it possible, to manually set a fixed gain? Or just in the code? (recompiling on for different different brightness would be annoying...)
<Treibholz[m]>
I can live with being green, but not with flickering :-)
<kbingham[m]>
Unfortunately - the AGC implementation there at the moment doesn't have manual controls I don't think - so it's not possible without recompiling. That's one of the rabbit holes I'm dealing with in my branch - which brings in manual controls correctly.
<kbingham[m]>
Unfortunately I don't get a lot of spare time on it ;-(
cyrinux949075 has joined #aarch64-laptops
pbrobinson_ has joined #aarch64-laptops
<Treibholz[m]>
what I don't understand, is that it only flickers in the browser, not in qcam... (at least on my X13s)
pbrobinson has quit [Read error: Connection reset by peer]
<\[m]>
@sre ok tx it does make more sense except jasper seemed to suggest this venus driver is disabled or whatever? do I need to enable it somehow then?
<\[m]>
lsmod not showing
<\[m]>
it's not coming anytime soon is it 😭
<robclark>
venus is for older hw, iris is for newer.. so for x1* iris is the one you want
<Jasper[m]>
@[\] it's not upstream for something like sc8280xp because there were no devices that could use it. Only recently Lenovo got the firmware merged for the x13s so now it _could_ be tested, but iirc the ML thread is dead.
<Jasper[m]>
(it could be tested before, but us mere mortals generally don't have CRD or MTP devices at home)
<Treibholz[m]>
on my X13s with venus-dec, playing videos with mpv increased the power-usage (and temperature) of the soc, compared to "without venus-dec".
<\[m]>
so that's - 1.5 years later?
<\[m]>
maybe the tuxedo is waiting for this 😆
<anthony25>
valpackett: thanks for the confirmation! I'll remove it and see if it changes anything
<anthony25>
(I'm pretty sure I won't anyway, even if it was indeed adding the new opp, ACD is what made it snappier)
<anthony25>
and I also tried to build hyprland on git, and was impressed to see that it was idling about 700mW lower
<anthony25>
and the average power consumption seemed to be lower as well
<anthony25>
I would like to debug what is causing these stutters in animations when switching to a workspace with certain apps (firefox, thunderbird, brave), I tried to fake an intel GPU in hyprland to see if using their hacks for intel was useful for adreno, but it didn't change anything
<anthony25>
even with their new scheduler that should force triple sync, it doesn't really solve it, and I'm surprised that Gnome with the same fractional scaling doesn't have the problem
<akhilpo>
Anthony, are you saying there are stutters on Hyprland without the IFPC series too?
<anthony25>
akhilpo: yeah I always had them, but with the patch that you helped me to spot it was really worse
<akhilpo>
After you reported that issue, I spent sometime to check it myself. I could install v49 and didn't see any stutter with the limited usecases I tried.
<anthony25>
did you use fractional scaling?
pbrobinson_ has quit []
ypwn_ has quit [Write error: connection closed]
anthony25 has quit [Remote host closed the connection]
dliviu has quit [Write error: connection closed]
hightower2 has quit [Write error: connection closed]
void09 has quit [Write error: connection closed]
kcxt- has quit [Write error: connection closed]
vanner has quit [Write error: connection closed]
rmsilva has quit [Write error: connection closed]
maxboone has quit [Read error: Connection reset by peer]
<akhilpo>
I don't remember exactly. It was a month ago.
<akhilpo>
Probably not.
hightower4 has joined #aarch64-laptops
<akhilpo>
Do you see the stutter only when fractional scaling is used?
pbrobinson has joined #aarch64-laptops
maxboone_ has joined #aarch64-laptops
nashpa has joined #aarch64-laptops
kcxt_ has joined #aarch64-laptops
anthony25_ has joined #aarch64-laptops
rmsilva- has joined #aarch64-laptops
<anthony25_>
(sorry, netsplit, I maybe missed an answer)
ypwn__ has joined #aarch64-laptops
void09_ has joined #aarch64-laptops
anthony25_ is now known as anthony25
juergh has quit [Ping timeout: 480 seconds]
<anthony25>
and I'm still using the IFPC series, it works well (just without patches 12 and 17)
juergh has joined #aarch64-laptops
<akhilpo>
I was asking if you see the stutters only when the fractional scaling is used?
maxboone_ is now known as maxboone
vanner has joined #aarch64-laptops
<anthony25>
I testing again after asking, I wasn't sure, and no
<anthony25>
they might be worse with fractional scaling
<akhilpo>
Could you check hyprland v49 too to see if it is a regression in v50 with the new tripple buffering support and all?
<anthony25>
sure, let me try
<anthony25>
I disable their new scheduler, it's still experimental, so it doesn't have triple buffering
Caterpillar2 has joined #aarch64-laptops
hightower3 has quit [Ping timeout: 480 seconds]
<anthony25>
akhilpo: same thing on v0.49
<akhilpo>
without fractional scaling too?
hightower2 has joined #aarch64-laptops
<anthony25>
yes, with and without
<anthony25>
if there's a process that uses enough CPU for it to not be in low frequency, then the animation doesn't stutter
<akhilpo>
Oh. It was butter smooth for me. I wonder if the display resolution/refresh rate has anything to do with this. My device has 2880x1800 @ 120hz
<akhilpo>
Yeah. thats pausible.
<anthony25>
I also tried to go back to a default config, default animations, but it's the same
<anthony25>
it's even more obvious with the default animations
<akhilpo>
Any chance you tested with tripple buffering? That is more GPU dcvs friendly.
<kalebris>
this maybe a stupid question but is there a lot of difference between jhovold's 6.16 source and linus's 6.16 kernel? Is the difference only slightly ahead of the curve in the rc front or there are are still things waiting to be merged once it's released?
<akhilpo>
All other compositors I tested (gnome, kwin, sway) had some form of trippler buffering support.
<anthony25>
akhilpo: I did, but I don't know if their implementation is bad yet or if it's something else, because it slows down the animation but the framedrops are so bad that it doesn't really help
hightower2 has quit [Ping timeout: 480 seconds]
<akhilpo>
I remember Johan's tree had some additional patches for CpuFreq improvement. I am not sure if they are available now in Linus's tree now. It is good idea to check Johan's tree + Johans' defconfig too.
<akhilpo>
I have a few things on my plate ATM at work. After a few days, I can share you a few ftraces offline which will help to understand this scenario.
<anthony25>
that's super nice, thanks a lot!
<anthony25>
I was running on johan's tree before, and had the same problem
<akhilpo>
:(
<anthony25>
(I was using it until 6.16)
<akhilpo>
Super strange device you have right there. ;-)
<anthony25>
I tried to record my screen to you with OBS but it uses CPU and therefore hides the problem :D
kcxt_ is now known as kcxt
<akhilpo>
Yeah. But a video won't help me to understand the root cause anyway.
hightower2 has joined #aarch64-laptops
abelvesa has quit [Remote host closed the connection]
abelvesa has joined #aarch64-laptops
hightower3 has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
<anthony25>
haha maybe, and I tried right now with ubuntu on 6.17 from the concept ppa, using the hyprland config by default (on v0.49.0), and I get even more stutters. But having certains apps opened and switching to them make it worse (firefox for example)
<anthony25>
anyway, let me know if you have some time one day to help me debugging that properly, I don't know how to tackle that, honestly (probably looking at the opengl trace?)
hightower3 has quit [Ping timeout: 480 seconds]
hightower2 has joined #aarch64-laptops
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
hightower3 has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
hightower3 has quit [Ping timeout: 480 seconds]
Caterpillar2 has quit [Ping timeout: 480 seconds]
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
icecream95 has joined #aarch64-laptops
<icecream95>
\[m]: vlc is decoding directly to WC memory, simulating Oryon having 0MB of cache per core cluster rather than 12MB
<icecream95>
Try MESA_EXTENSION_OVERRIDE=-GL_ARB_buffer_storage to workaround it
<valpackett>
wow that's cursed
mbuhl has quit [Remote host closed the connection]
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
mbuhl has joined #aarch64-laptops
agl has quit []
agl has joined #aarch64-laptops
<HdkR>
icecream95: They're doing readback from it even?
hightower2 has joined #aarch64-laptops
<HdkR>
For just a memcpy in to it as a destination I would expect it to be fine, buf they really shouldn't be doing readback from GPU buffers.