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
<d0pefish>
i'm the maintainer of the arch linux arm image for it on github. It boots, it has USB, gpu, wifi, keyboard, but that's about it. No sound, no touchscreen/pen, suspend/resume is buggy, external monitors aren't being detected... lots of things need work
<robclark>
teadaniel[m]: you'll want to copy some fw from the windows partition.. same instructions as for x1e (although maybe a few of the fw files have a slightly different name)
<EdLin>
d0pefish: thanks
<EdLin>
d0pefish: does the non-flex keyboard work? That's what I have, the one with the copilot key and pen storage but no bt or wireless.
<EdLin>
if not, will a typical BT kb work like something from Logitech or only the Flex one documented on your github?
<d0pefish>
I'm not sure, my hope is that it should, AFAIK the flex keyboard is the newest (and therefore least-tested), but it's working, so I guess they haven't changed the surface KB protocol much over the years
<d0pefish>
USB keyboards will be fine, BT should also be fine (I've used a BT mouse in my testing)
<EdLin>
cool. Thanks.
<d0pefish>
BT needs some udev messing to set a MAC address (afaik this isn't unique to the surface; all the X1E machines have this issue) - this is mentioned in the readme I think
<EdLin>
hm, how would I detech which MAC address my mouse has e.g.?
<EdLin>
detect*
<EdLin>
I'm willing to mess with udev, only problem is it has human-edited XML but I'll hold my nose and curse it. lol
<d0pefish>
it's the mac address of the BT host, that needs to be set; not your peripheral - basically you go to Windows, note down the BT MAC, then add a udev script to your system that applies it
<EdLin>
hm
<d0pefish>
it's well documented on the Debian wiki for Thinkpads I think, let me get the link
<d0pefish>
once you do that, the adaptor should come up and the usual BT tools on Linux should work fine
<EdLin>
d0pefish: the only bt tools I've used on Linux are the GNOME and KDE ones, I assume you don't mean those.
<EdLin>
does it have some sort of weird name or will it be easy to find? :)
<EdLin>
let me grep the Arch wiki
<EdLin>
bbl
EdLin has quit [Quit: WeeChat 4.1.1]
EdLin has joined #aarch64-laptops
<EdLin>
I just realized I don't have a spare USB-C flash drive other than my Surface windows recovery drive that works.
<EdLin>
so testing'll have to be later
<EdLin>
I bought a new one from Amazon, I hope it works OK lol
EdLin has quit []
dapsayemolt^ has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
pstef_ has joined #aarch64-laptops
pstef has quit [Ping timeout: 480 seconds]
pstef has joined #aarch64-laptops
pstef_ has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
tobhe has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
teadaniel: RTL9210 based USB to nvme work well, JMicron not so much. For initial bringup with the image you need the windows partition (undecrypted) accessible on the internal nvme, the init script copies the firmwares from there. For further operation, depends. It's handy for some things, but takes space and makes install more challenging. I usually keep them after resizing.
<JensGlathe[m]>
unencrypted*
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<albsen[m]>
Kieran Bingham: boot from ubuntu usb, chroot into fedora and install the old kernel or alternative compile ur own and install that. no need to reinstall
<steev>
JensGlathe[m]: does having dislocker help with the encryption?
<JensGlathe[m]>
No idea. I never took the chance (because newer-ish ntfs versions on Windows after reading a bit on it), always decrypted the disk in Windows as preparation, together with switching off secure boot. Worked all the time.
<KieranBingham[m]>
<albsen[m]> "Kieran Bingham: boot from ubuntu..." <- Aha, so yeah that's a great idea. I tried it last night but some systemd component got unhappy because somehow the /sbin /usr and /lib64 symlinks are all relative. I can't tell if that's something new in fedora, or if it was something about how I mounted before chroot. But now I have an empty grub with no entries because os_prober fails. I also wonder if this is related to
<KieranBingham[m]>
what caused the issue in the first place ... It's always fun jumping out of the frying pan and into the fire :-) will resume later
<teadaniel[m]>
<JensGlathe[m]> "teadaniel: RTL9210 based USB..." <- Thanks for the protip!
<teadaniel[m]>
I got a JMicron arriving tomorrow with a solid return policy. 😅
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
You can get JMicron to work with USB quirk, limit to usb-storage, but even then its not really good.
<JensGlathe[m]>
I prefer the ugreen ones, seem to be solid
jhovold has joined #aarch64-laptops
pstef has quit [Read error: Connection reset by peer]
pstef has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
@teadaniel the boot cmdline option to add is `usb-storage.quirks=152d:a580:u`
<JensGlathe[m]>
You need to replace the device ID with the one you have, though
<JensGlathe[m]>
Not-so fun fact: On WoA these quirks seem to be missing, too, so its also a PITA on Windows when on an aarch64 machine
srinik has joined #aarch64-laptops
svarbanov_ has joined #aarch64-laptops
svarbanov has quit [Read error: Connection reset by peer]
srinik has quit [Ping timeout: 480 seconds]
Treibholz has quit [Quit: WeeChat 3.8]
chrisl has joined #aarch64-laptops
dapsayemolt^ has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
srinik has joined #aarch64-laptops
davidinux has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
SpieringsAE 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
dapsayemolt^ has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<kuruczgy[m]>
Is anyone having issues with slbounce on 6.14? I just discovered that neither 6.14-rc4 nor 6.14-rc2 boot for me in EL2, it just crashes and resets the machine. 6.13 works fine.
chrisl has joined #aarch64-laptops
<farchord>
Yeah when it comes to USB-C hub, you have to be very careful what brand you pick. As Jens Glathe said though, ugreen has been solid for me. And anker, but I do remember anker doing some weird shenanigans 1-2 years ago...
chrisl has quit [Ping timeout: 480 seconds]
davidinux has quit [Read error: Connection reset by peer]
davidinux has joined #aarch64-laptops
davidinux has quit [Quit: WeeChat 4.3.1]
<maz>
kuruczgy[m]: I'm running -rc4 at the moment.
<maz>
kuruczgy[m]: at what point in the boot does it reset?
<kuruczgy[m]>
maz: The last thing I see is "EFI stub: Exiting boot services..."
<maz>
how do you boot? grub? sd-boot?
<maz>
none of these two ever worked reliably for me.
<kuruczgy[m]>
systemd-boot, yes. For me it worked 100% reliably, until 6.14
<maz>
could be a size thing. the FW is incredibly flimsy, and it doesn't take much to push it over the edge.
davidinux has joined #aarch64-laptops
<maz>
you could try to boot the kernel directly from EFI, which has always worked for me.
<maz>
but I'm using the devkit, which may not be representative of the rest of the QC stuff.
<kuruczgy[m]>
Well it's still a good data point. Thanks for the advice, I will try booting directly from an EFI shell later. (I expect it to be a bit involved, having to figure out all the right kernel params and typing that on the slow buggy EFI keyboard...)
<javierm>
kuruczgy[m]: maybe you could increase the output verbosity? My debug options are "earlycon efi=debug debug initcall_debug log_buf_len=16M ignore_loglevel"
<maz>
kuruczgy[m]: make sure you have the DTB loader compiled in and provide the DT as a kernel parameter
<kuruczgy[m]>
maz: Is this a script that can be executed in the EFI shell? How do I do that? (If that saves me from having to type the kernel params out manually that would be very helpful.)
<maz>
this is a script generated from a grub hook, which can be then directly executed.
<maz>
however, it relies on a bunch of other things, such as an ext4 driver to be able to access the kernel and the initramfs from EFI.
<maz>
it's all very hackish, but I haven't had a problem booting since I used that.
<maz>
maybe I should tar-up these things and upload them somewhere for everyone's hilarity.
<Jasper[m]>
Just as an aside, are both of you talking about the same soc? iirc maz mostly uses x1e
<kuruczgy[m]>
maz: So you just type `.\boot\pmg\000-6.14.0-rc4-00065-g1d21a553f1de.nsh` in the EFI shell, and it magically recognizes that this is not a binary EFI executable but a script? Or is it the `.nsh` extension that matters?
<kuruczgy[m]>
Jasper: AFAIK yes, I have the slim 7x
<maz>
kuruczgy[m]: I have no idea. I always use .nsh for EFI scripts, and that worked well enough for me.
<Jasper[m]>
Alright, nice. Just checking since firmware shenanigans have happened before.
<maz>
ah, you also want to use something other than the default shell -- I use the vanilla EDK2 shell.
<kuruczgy[m]>
Well AFAICT there is no "default" EFI shell on this laptop, so I always have to boot into one from the installer USB. (But maybe I should add it to my default boot menu too...)
chrisl has joined #aarch64-laptops
<maz>
interesting. the devkit definitely comes with one, only subtly fscked.
<kuruczgy[m]>
javierm: Thanks, just tried that. Unfortunately no extra messages get printed before the crash.
<kuruczgy[m]>
maz: Unfortunately I can't even boot without slbounce from the EFI shell, it just gets stuck here (see photo above). I copied the params from a working systemd-boot entry. (Not 100% sure how the `initrd=` and `dtb=` options are interpreted, based on your example it seems they are resolved relative to the ESP, and need backslashes?)
<kuruczgy[m]>
(I also confirmed that CONFIG_EFI_ARMSTUB_DTB_LOADER=y)
<maz>
kuruczgy[m]: what you pass as a DTB is highly suspicious...
<maz>
I don't expect the DT loader to be happy with an EFI binary.
<kuruczgy[m]>
Oh wait, I have one idea what could be wrong, that might be the wrong device tree.
<kuruczgy[m]>
If you are referring to the extension, yes, seems like NixOS thinks it's an excellent idea to append an `.efi` extension to every boot file. I am pretty sure it's just the extension though.
JosDehaes[m] has quit [Quit: Bridge terminating on SIGTERM]
unrust[m] has quit []
meroleander[m] has quit [Quit: Bridge terminating on SIGTERM]
freekurt[m] has quit [Quit: Bridge terminating on SIGTERM]
dunc4n has quit [Quit: Bridge terminating on SIGTERM]
nirik has quit [Quit: Bridge terminating on SIGTERM]
mynery[m] has quit [Quit: Bridge terminating on SIGTERM]
owokitty[m] has quit [Quit: Bridge terminating on SIGTERM]
macc24 has quit [Quit: Bridge terminating on SIGTERM]
steveej[m] has quit [Quit: Bridge terminating on SIGTERM]
srinik has joined #aarch64-laptops
konradybcio has quit [Quit: Bridge terminating on SIGTERM]
jenneron[m] has quit []
logan2611 has quit [Quit: Bridge terminating on SIGTERM]
JensGlathe[m] has quit [Quit: Bridge terminating on SIGTERM]
Dylanger has quit [Quit: Bridge terminating on SIGTERM]
Radical[m] has quit [Quit: Bridge terminating on SIGTERM]
WarAd[m] has quit [Quit: Bridge terminating on SIGTERM]
yoyoquake[m] has quit [Quit: Bridge terminating on SIGTERM]
anonymix007[m] has quit [Quit: Bridge terminating on SIGTERM]
Segfault[m] has quit [Quit: Bridge terminating on SIGTERM]
andre4ik3[m] has quit [Quit: Bridge terminating on SIGTERM]
dreamson[m] has quit []
Hugo[m] has quit [Quit: Bridge terminating on SIGTERM]
Sayatomoki[m] has quit [Quit: Bridge terminating on SIGTERM]
nar001[m] has quit [Quit: Bridge terminating on SIGTERM]
Sukiru[m] has quit [Quit: Bridge terminating on SIGTERM]
QiuWenboAwaytilltheendofChines has quit []
noisycoil[m] has quit []
Biggy[m] has quit [Read error: Connection reset by peer]
reedhhw[m] has quit []
bumble[m] has quit [Write error: connection closed]
pengyu[m] has quit [Read error: Connection reset by peer]
Treibholz[m] has quit [Read error: Connection reset by peer]
chenxuecong[m] has quit [Remote host closed the connection]
LiangQi[m] has quit [Remote host closed the connection]
vickdu31[m] has quit [Remote host closed the connection]
teadaniel[m] has quit [Read error: Connection reset by peer]
Jasper[m] has quit [Remote host closed the connection]
M31415jd[m] has quit [Write error: connection closed]
ahoneybun[m] has quit [Write error: connection closed]
mehdidjait[m] has quit [Remote host closed the connection]
kuruczgy[m] has quit [Remote host closed the connection]
Tony[m]1 has quit [Remote host closed the connection]
albsen[m] has quit [Remote host closed the connection]
wapitiii[m] has quit [Remote host closed the connection]
wiley[m] has quit [Remote host closed the connection]
Nios34[m] has quit [Remote host closed the connection]
matrix7125[m] has quit [Remote host closed the connection]
TheBITLINK[m] has quit [Write error: connection closed]
obbardc has quit [Write error: connection closed]
ppd[m] has quit [Remote host closed the connection]
chronicuser21[m] has quit [Remote host closed the connection]
saladman[m] has quit [Write error: connection closed]
pdchen[m] has quit [Write error: connection closed]
sporos11[m] has quit [Remote host closed the connection]
travmurav[m] has quit [Write error: connection closed]
Eighth_Doctor has quit [Write error: connection closed]
farchord has quit [Write error: connection closed]
smoorgborg[m] has quit [Remote host closed the connection]
clover[m] has quit [Remote host closed the connection]
amstan has quit [Write error: connection closed]
marclaporte[m] has quit [Remote host closed the connection]
joel[m]12 has quit [Remote host closed the connection]
initard[m] has quit [Remote host closed the connection]
\[m] has quit [Remote host closed the connection]
ke7cfn[m] has quit [Remote host closed the connection]
socratitties[m] has quit [Remote host closed the connection]
z3ntu has quit [Remote host closed the connection]
tinagammelgaard[m] has quit [Remote host closed the connection]
KieranBingham[m] has quit [Remote host closed the connection]
aidful[m] has quit [Remote host closed the connection]
trompetentoni[m] has quit [Remote host closed the connection]
richli255[m] has quit [Remote host closed the connection]
<maz>
kuruczgy: but also it is an overlay. you really want the base thing.
<kuruczgy>
maz: Yes, indeed, that was the overlayed device tree for EL2, that was the issue. With the non-overlayed device tree it boots fine without slbounce.
<kuruczgy>
Unfortunately the overlayed device tree does not boot with slbounce, it gets stuck after "Exiting boot services..."
srinik has quit [Remote host closed the connection]
srinik has joined #aarch64-laptops
<SpieringsAE>
can multiple nodes in a devicetree use the same gpio? I am writing some bindings, and there is one gpio connected to multiple devices.
<travmurav[m]>
yes-ish-ish but the driver needs special support for that
<travmurav[m]>
i.e. I think fixed regulators do that
<SpieringsAE>
well driver implementation is waaaaay out, so no worries about that so far
<SpieringsAE>
just about devicetree definition
<travmurav[m]>
whats the gpio?
<SpieringsAE>
the idea is a synchronization line between multiple nodes
<travmurav[m]>
uh
<SpieringsAE>
it can be pinged to synchronize the counters or something
<SpieringsAE>
but there isn't actually an implementation yet
srinik has quit [Ping timeout: 480 seconds]
<travmurav[m]>
what's the gpio is connected to
<SpieringsAE>
multiple microcontrollers
<travmurav[m]>
oh, like shared reset signal?
<SpieringsAE>
that do IO stuff
<SpieringsAE>
yes but not really hard reset
<SpieringsAE>
its to potentially enable time sensitive IO between multiple microcontrollers
<travmurav[m]>
I guess if you're writing your own code on both sides then you can allow it yeah
<SpieringsAE>
banger
<travmurav[m]>
normally linux won't allow you to reuse gpios in multiple driver instances but sounds like you'd have to have some singleton in the code anyway (or make sure it's safe to race same gpio from two kernel objects)
<SpieringsAE>
I doubt the linux side will ever actually do anything with this pin, but we hooked it up for a what if situation
<travmurav[m]>
I guess depending on your application, your userspace software could discover it from the DT xD
<SpieringsAE>
linux is too wobbly to be the sync master, and I don't really see what it would do in response to a sync pulse
<SpieringsAE>
we hope to eventually run an engine with our controller, injectors, coils and such
<SpieringsAE>
I like the FIX ME comment ^
<SpieringsAE>
wonder how long that has been there
<travmurav[m]>
7 years
<travmurav[m]>
apparently xD
<SpieringsAE>
4.20 lol
SpieringsAE has quit [Quit: SpieringsAE]
<broonie>
The fixme comment is only needed since gpiod was introduced and started trying to force exclusivity of requests.
<craftyguy>
kuruczgy: did you figure out how to get slbounce working on 6.14?
<craftyguy>
s/on/with/
<kuruczgy>
craftyguy: nope, as I said above it's not booting from the EFI shell either. Is it the same issue for you, working with 6.13, but not with 6.14?
JensGlathe[m] has joined #aarch64-laptops
<JensGlathe[m]>
<SpieringsAE> "can multiple nodes in a devicetr..." <- no. Should give errors "GPIO is already in use by..."
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
Jasper[m] has joined #aarch64-laptops
dcavalca has joined #aarch64-laptops
sobek[m] has joined #aarch64-laptops
konradybcio has joined #aarch64-laptops
neobrain[m] has joined #aarch64-laptops
z3ntu has joined #aarch64-laptops
albsen[m] has joined #aarch64-laptops
Eighth_Doctor has joined #aarch64-laptops
KieranBingham[m] has joined #aarch64-laptops
teadaniel[m] has joined #aarch64-laptops
stefan-schmidt has joined #aarch64-laptops
kuruczgy[m] has joined #aarch64-laptops
farchord has joined #aarch64-laptops
noisycoil[m] has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
JensGlathe: I guess that only happens when multiple driver call devm_gpio_get or whatever on it? Which is not the case here
davidinux has quit [Quit: WeeChat 4.3.1]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<craftyguy>
kuruczgy: I haven't tried yet, was just curious if you solved it so I could avoid having to debug it too heh
<craftyguy>
I think the dtbo that I have for slbounce is pretty old, I need to look up how to build a new one for the latest kernel. I assume it's required/recommended to keep this fairly up to date(?)
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
SpieringsAE: yes, I assumed the "normal" case
dapsayemolt^ has quit [Remote host closed the connection]
<HdkR>
I have to say, the most annoying feature of the Yoga is the weekly EC breaking. So it powers off, EC then resets, charges, and then I need to physically power it back on
<HdkR>
powers off because it runs out of battery*
<anthony25>
What do you mean?
<HdkR>
Exactly as I said. Every so often as it is idling, it stops charging, then empties the battery, and turns off. The act of it turning off seems to reset the EC so it then charges again, but doesn't automatically turn back on
<anthony25>
oh ok
<anthony25>
I power off mine due to the high power drain in suspend, I didn't see this problem
<HdkR>
I remote in to the thing since I don't use it as a main PC. So I can't just shove it in to a corner because of this
<anthony25>
and do you see any logs when it "breaks"?
sre has joined #aarch64-laptops
<maz>
kuruczgy: I don't use any overlay, mostly because this machine isn't usable for me without EL2.
<HdkR>
anthony25: I haven't really been watching kernel logs
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
srinik has quit [Ping timeout: 480 seconds]
icecream95 has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
todi has quit [Remote host closed the connection]
<minecrell>
kuruczgy: if you’re using Johan‘s tree, make sure you disable the new sbsa watchdog in x1e80100.dtsi when booting in EL2, it will crash otherwise
chrisl has quit [Ping timeout: 480 seconds]
<minecrell>
If you’re using Johan‘s tree and maz isn’t that would explain it, since the watchdog patch was only just applied upstream
<kuruczgy[m]>
Re slim 7x EC: I have never had such an EC breakage either. But I try not to charge it too much (above 80 or 90%), and never leave it plugged in for prolonged periods, and also turn it off often due to the high suspend power draw.
<kuruczgy[m]>
minecrell: Actually I just compiled Johan's wip/x1e80100-6.14-rc4 branch manually, and it seems to work fine with EL2. So I guess maz's theory about kernel image size and buggy firmware looks more promising now.
<kuruczgy[m]>
My working 6.13 image is 32571904 bytes, the non-working 6.14-rc4 is 32625152 bytes, and my working 6.14-rc4 is 17900032 bytes (significantly less, due to not having a bunch of extra stuff enabled that the distro package normally enables).
<kuruczgy[m]>
But if you say that it should 100% crash with the watchdog enabled I guess that's another mystery to look into...
<HdkR>
I can believe I don't use the laptop like a real human
<kuruczgy[m]>
Yep, you are probably using it more like a CI runner, which is kind of a bummer for FEX if that does not work reliably...
hexdump01 has quit []
hexdump0815 has joined #aarch64-laptops
<minecrell>
kuruczgy: Can you paste the dmesg from the successful boot? Does it have „ Initialized with %ds timeout @ %u Hz, action=%d.%s“ from the watchdog?
<HdkR>
kuruczgy[m]: Luckily I use faster machines for CI than X1E
<HdkR>
But yea, I throw unit tests at it all the time because it supports more features than most other devices today.
<kuruczgy[m]>
But `/sys/firmware/devicetree/base/soc@0/watchdog@1c840000` exists
<minecrell>
kuruczgy: do you have CONFIG_ARM_SBSA_WATCHDOG enabled in this new kernel?
<kuruczgy[m]>
minecrell: Nope, I have it unset in the working kernel, while I have it `=y` in the non-working one. That indeed seems very sus if you say it prevents EL2 booting, let me test it...
chrisl has joined #aarch64-laptops
<kuruczgy[m]>
Bingo, setting that prevents EL2 booting.
chrisl has quit [Ping timeout: 480 seconds]
jhovold has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
weirdtreething_ has joined #aarch64-laptops
weirdtreething has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
weirdtreething_ is now known as weirdtreething
<kuruczgy[m]>
minecrell: Setting `status = "disabled";` on the `/soc@0/watchdog@1c840000` node in the dt overlay fixes the issue. Thank you very much for the help.
<kuruczgy[m]>
I guess this is something that should be upstreamed to the slbounce repo? (Unless there is some different preferred solution.)
frontin has quit [Ping timeout: 480 seconds]
<kuruczgy[m]>
maz: Just to confirm, I assume you have CONFIG_ARM_SBSA_WATCHDOG unset? (Or does the watchdog work differently on the devkit?)
<kuruczgy[m]>
Ping craftyguy (also maybe travmurav in case you miss it on github)
frontin has joined #aarch64-laptops
frontin has quit [Ping timeout: 480 seconds]
<craftyguy>
oh wow, nice find
frontin has joined #aarch64-laptops
jglathe_x13s has joined #aarch64-laptops
jglathe_x13s has quit [Remote host closed the connection]
<kuruczgy[m]>
Also I was complaining yesterday about dp altmode link training errors being worse on -rc4, but today it seems to be working well. I guess I was just having an unlucky day with the local EM conditions...
chrisl has joined #aarch64-laptops
Ian[m] has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
Pop-OS is getting somewhere, got my X13s installation reactivated with the latest upgrades. Looking nice
dapsyl^ has joined #aarch64-laptops
ypwn_ has joined #aarch64-laptops
ypwn has quit [Read error: Connection reset by peer]