00:01 <Sayatomoki[m]> <mynery[m]> "your live system uses grub" <- but systemd menu only "reboot firmware interface" option and no "efi shell"

00:02 <Sayatomoki[m]> > <@mynery:matrix.org> your live system uses grub

00:02 <Sayatomoki[m]> * but the boot menu only "reboot firmware interface" option and no "efi shell"

00:08 <Sayatomoki[m]> <Sayatomoki[m]> "but systemd menu only "reboot..." <- i think its systemd-boot...

00:47 <steev> blergh, rc2 did that thing where it clamped to 940mhz again

00:48 <steev> oh good, a suspend and resume unsticks it

01:08 <clover[m]> Indeed, the live system is systemd-boot, not grub.

01:09 <clover[m]> That's really weird that you don't have any entries

01:11 <clover[m]> Did you download from.the github release, check the checksum, and flash with the suggested DD command?

01:13 <clover[m]> Or did you possibly build the iso yourself?

01:13 <clover[m]> If you built it yourself, you might have used the wrong config

01:15 <Sayatomoki[m]> i download iso from github release page and checksum valid, but i use windows rufus to write iso

01:15 <clover[m]> Ok I've never used that software. Can you try balena etcher if possible

01:17 <Sayatomoki[m]> i try to use dd command , but livecd cant boot, it just still on bios boot menu.

01:18 <clover[m]> Is dd command even in windows?

01:18 <Sayatomoki[m]> archlinux on other desktop

01:19 <clover[m]> Did you try flipping the usb c?

01:21 <Sayatomoki[m]> no, i didnt try, but i download ubuntu 23.10 official x13s release, it can boot

01:22 <clover[m]> ubuntu live iso might have newer kernel than the arch live iso, that might be why

01:23 <clover[m]> i think on 5.19 it was still sensitive to usb orientation

01:23 <clover[m]> im double checking and reflashing the latest iso

01:27 <steev> it was

01:33 <Sayatomoki[m]> oh, i use rufus's dd mode, it can boot

01:33 <clover[m]> W00t

01:48 <steev> so many people show up in the kali discord with issues after using rufus

01:51 <Sayatomoki[m]> Currently, the regular linux-aarch64 and linux-aarch64-rc kernels don't work, until this is sorted out you can use the ironrobin-x13s repository and install linux-x13s from it.

01:51 <clover[m]> Compared to balena etcher it's downright baroque

01:51 <Sayatomoki[m]> The ironrobin-x13s repo will be missing from the target system's pacman.conf, make sure to edit it and add this if you want to use X13s packages

01:51 <Sayatomoki[m]> seems to kernel 6.9 can work, are they still valid？

01:52 <clover[m]> Saya: I haven't tried. You are welcome to try not sure what version upstream alarm is using these days.

01:53 <steev> if you're using clover's repo to pull in my patched kernel, you're gonna want the firmware package at least, otherwise as noted a little while ago, power usage goes up up up

01:53 <steev> without the qcvss8280.mbn file, something gets stuck (interconnects?) and yeah

02:00 <clover[m]> steev: don't worry x13s-firmware is a package dependency for your kernel package ;)

02:00 <clover[m]> It should get pulled in automagically

06:43 <steev> odd that the aarch64 and aarch64-rc kernels don't work though, anything newer than 6.5 should work with diminished capabilities

06:47 <mynery[m]> can we expect the x13s to just run with mainline eventually?

06:57 <abby> it does already

07:03 <abby> a few things don't work but it's a functional computer on 6.5+

07:16 <jhovold> mynery[m]: see https://github.com/jhovold/linux/wiki/X13s#mainline-feature-support

07:20 <jhovold> there's no reason to run anything but mainline unless if you want to play wth the limited camera and video acceleration support

07:21 <jhovold> or help out with testing -rc kernels

07:23 <mynery[m]> oh, that is actually pretty interesting. so i might try to just throw a nixos on it

07:24 <jhovold> just make sure your kernel is configured properly

07:26 <mynery[m]> i assume this can be done, i have to investigate

07:28 <mynery[m]> also, the kernel config thing is probably what makes it necessary th boot live images tweaked for the device, i assume?

07:29 <jhovold> right, it's that, but also the dtb and kernel parameters

07:31 <jhovold> and the qualcomm usb hardware is quirky and resets when loading the fw

07:32 <jhovold> and then there's the pd-mapper daemon

07:32 <jhovold> but that should be about it

07:32 <abby> qrtr daemon too, right?

07:33 <jhovold> it's not strictly needed, just needs to be installed to satisfy a systemd service dep, it's not actually used

07:33 <jhovold> moved into the kernel some years ago

07:33 <mynery[m]> gotcha. have to think about how to do this, but i assume, worst case i can just install nix on top of ubuntu or something

07:34 <jhovold> all of the above can be handled, I have a custom arch installation usb stick I've set up myself here

07:34 <abby> which systemd service? on void we have no such dependency so i could remove that from my setup

07:34 <jhovold> just don't include the usb fw, and make sure to flip the usb-connector if the device isn't detected

07:35 <jhovold> good enough for me, but such issues would need to be solved by the distros

07:35 <jhovold> abby: see https://github.com/linux-msm/pd-mapper/blob/master/pd-mapper.service.in

07:36 <jhovold> Requires=qrtr-ns.service

07:36 <abby> hm i see

07:38 <jhovold> (usb fw as in fw for the adsp which handles usb-c orientation detection)

07:41 <travmurav[m]> maybe need to drop the dependency upstream since pretty much everyone would have qrtr-ns in the kernel by this point?

07:42 <jhovold> yeah, it may be time for that (bamse?)

07:56 <jhovold> Here's an updated wip branch for the X13s:

07:56 <jhovold> - https://github.com/jhovold/linux/tree/wip/sc8280xp-6.10-rc2

07:56 <jhovold> Known issues:

07:56 <jhovold> - hard reset on DP disconnect (6.10-rc1 regression)

07:57 <jhovold> craftyguy: you can use that x1e80100 wip branch on the X13s as well, but here's a dedicated sc8280xp branch ^

07:59 <steev> jhovold: with rc2 do you see the x1c cores clamp to 940mhz?

07:59 <steev> by which i mean, scaling_max_freq reports 940800

08:00 <steev> it's not super often but i've seen it twice

08:04 <jhovold> steev: no, there's no such issue here with my wip branches

08:05 <jhovold> and in my setup, perhaps your userspace is confused? unless you're carrying some broken patches...

08:07 <jhovold> konradybcio added some new thermal parameters in 6.10-rc1, they made need some further work to be useful, but they should not matter unless switching thermal governor

08:07 <jhovold> but that's the only change that comes to mind

08:08 <jhovold> might possibly be confusing user space, though, so try reverting that change and see if it helps

09:53 <alx___> for everyone who read about my ongoing touchpad issues, I now replaced the entire touchpad and the issue is gone. Turned out that the front click part was sort of super flat after removing it. It had literally no movement anymore. That seems to cause the phantom click and hold I was experiencing. Interesting enough these are not an continuous issue which caused fault positive or negatives in debugging.

09:53 <alx___> sad that the touchpad is already broken after 3 months thought

10:19 <sskras> heya channel

10:20 <sskras> what convertible chromebooks would you recommend, please?

10:21 <jenneron[m]> sskras: https://wiki.postmarketos.org/wiki/Devices#Convertible_laptops

10:30 <sskras> ty

10:38 <jenneron[m]> sskras: mt8183 and qcom 7c ones are recommended

10:38 <jenneron[m]> if not x86

10:41 <sskras> thanks. What about mt8186g? I see Asus Chromebook Cm14 Flip sold in the local market

10:43 <sskras> PCmag mentions sluggish performance: https://uk.pcmag.com/laptops/148311/asus-chromebook-cm14-flip

10:44 <jenneron[m]> sskras: i don't know if there are any distributions supporting these well

10:44 <jenneron[m]> if it's not a problem for you you can go for it

10:44 <jenneron[m]> there are also mt8192/mt8195 ones which should be much more performant

10:44 <jenneron[m]> some of them even have nvme

10:44 <jenneron[m]> but the same problem with distributions

10:45 <sskras> actually I intented to run the native Chrome OS

10:45 <sskras> so thanks for your tips :)

10:47 <jenneron[m]> sskras: then mt8192/mt8195 would be the best choice for performance on arm

10:47 <jenneron[m]> for now

10:47 <jenneron[m]> but i believe this room is about linux :P

11:03 <konradybcio> we tolerate chromeos ;)

11:10 <konradybcio> jhovold 6.10-rc1 only has EAS properties, thermal gov stuff is out for now

11:15 <jhovold> konradybcio: yeah, I'm quite aware of that as I was the one confirming it is still not working ;)

11:16 <jhovold> I only mentioned the EAS properties as that is something which could potentially confuse user-space

11:17 <jhovold> but as it only happens with steev's branches and he has a history of including broken experimental stuff, it's really no concern of mine

11:18 <jhovold> (yet)

11:27 <Sayatomoki[m]> how can i fix "error loading \vmlinuz-linux: unsupported"

11:28 <travmurav[m]> is it normally compressed (non zboot) vmlinuz and systemd-boot?

11:28 <Sayatomoki[m]> yes

11:29 <travmurav[m]> sd-boot can't decompress things on it's own sadly

11:30 <travmurav[m]> so probably want to either rebuild your kernel with zboot/compession support and use that or just decompress it manually for now

11:31 <Sayatomoki[m]> x13s-linux package's vmlinuz is compressed?

11:32 <travmurav[m]> ¯\_(ツ)_/¯ but you can check it with `file` I guess

11:32 <travmurav[m]> if it's gzip then sd-boot can't use that, if it's linux/PE then probably some different issue

11:40 <travmurav[m]> yeah the first one sd-boot won't use, but you can probably just gzip -d it

11:42 <Sayatomoki[m]> thx, i fix this, but i am stucking booting

11:51 <jhovold> I've tracked down the DP disconnect regression to the enablement of UCSI in 6.10-rc1, and pushed an effective revert to the rc2 wip branch.

14:32 <clover[m]> its kinda dumb, but i package both compressed vmlinuz-linux because grub can find this and use it automatically, and i ship uncompressed vmlinux because systemd-boot doesn't support compressed kernels

14:32 <clover[m]> so you can use either one depending on your bootloader choice

14:33 <clover[m]> <Sayatomoki[m]> "thx, i fix this, but i am..." <- what are your kernel parameters?

14:36 <Sayatomoki[m]> clover[m]: i had add arm64.nopauth to fix it. thanks for your reply.

14:38 <travmurav[m]> <clover[m]> "its kinda dumb, but i package..." <- I think grub would be fine with zboot compressed image so maybe you can use that for both?

14:39 <travmurav[m]> as in, efi style self decompressing kernel

14:40 <clover[m]> Sayatomoki[m]: enjoy your system! don't see a lot of people using fish

14:43 <clover[m]> travmurav[m]: zboot compressed kernels work with sd-boot?

14:44 <travmurav[m]> clover: yes, zboot is basically an efi decompressor prepended to the usual gzip/whatever kernel, and sd-boot would just call it like a normal efi application (which uncompressed kernel is also one with efi-stub in front)

14:45 <travmurav[m]> we use zboot for devices that use sd-boot in pmOS

14:50 <clover[m]> thanks for the tip, i'll have to check it out

15:33 <Nios34[m]> hexdump0815: Hi! Can you try to merge the book go dt patch and build a new image? I broke my debootstrap installation somehow and It will be very helpful if a new image gets built.

17:37 <steev> alx___: sucks that the touchpad was broken :( but glad you got it fixed! i've had a great pyrenees jump on mine (on accident, he was excited, it was on the couch, he jumped up there) and still nothing

17:45 <\[m]> alx___ you didn't have warranty?