02:06 <steev> bamse: do you happen to know/remember what fixed https://www.spinics.net/lists/linux-arm-msm/msg83826.html ? for the life of me, i cannot

02:27 <enyalios> gwolf: what problems were you running into, ive been really happy with xorg + i3 or my x13s so far

02:42 <bamse> steev: no :(

02:42 <steev> i want to say we were missing something with the mmu

02:43 <bamse> nah, just looks like the slimbam wasn't present...and we didn't do error handling very nicely

03:52 <Dylanger> bamse: Any idea what kernel config I would use for this HDK8350?

03:53 <Dylanger> https://linaro.github.io/msm/soc/sm8350

03:53 <Dylanger> Looks like pretty much everything is mainline'd

04:09 <bamse> Dylanger: defconfig

04:10 <bamse> Dylanger: should work, and if anything is missing, let's add it

04:10 <travmurav[m]> hm, craftyguy (or anyone else with x13s, or even other devices) what other options does uefi firmware on your devices have that affect "os usage"? I'm thinking stuff like fn row priority, like above, trackpad disable etc

04:11 <travmurav[m]> i.e. on aspire1 there is fn mode - which fn layer (fxx or media) is on top, and it's implemented by setting a property in acpi so obviously doesn't work for dt

04:11 <HdkR> fn row priority and fn and ctrl key swap

04:11 <travmurav[m]> and do those work?

04:11 <HdkR> yea

04:12 <HdkR> wifi disable also works

04:12 <travmurav[m]> mhm cool, I guess that firmware does it on boot time unlike my device

04:12 <HdkR> er wait, I tried wwan disable not wifi disable

04:15 <travmurav[m]> fun, apparently my device allows fn mode and also... numlock mode??? for the keys on the second layer of the tkl?

04:16 <HdkR> Gotta love when you have numlock in the middle of your qwerty keyboard

04:17 <travmurav[m]> but the reason I'm asking is because I was looking into the dtbloader and I'm thinking it would be nice for it to handle those settings with per-device code

04:18 <travmurav[m]> as in, to translate, where needed, acpi props into the dt props, put status=disabled in things etc

04:18 <jenneron[m]> travmurav: we may be able to do more with dtb overlays than efi settings..

04:18 <jenneron[m]> also how does ACPI changes can affect fn keys, since it's an i2c hid device

04:19 <jenneron[m]> i'm not saying it can't, i'm just curious

04:19 <travmurav[m]> provision mac addresses, either with a device specific code or just from the board id

04:20 <travmurav[m]> jenneron: well, this firmware is, of course, dumb. the EC has a "register" for the keyboard mode that has like 3 positions: "always fn", "fn", "media", and the 1 is boot time, then the acpi writes to it from an acpi prop in some touchpad init function

04:21 <jenneron[m]> i see

04:21 <travmurav[m]> so when you set the firmware to a different thing, that property gets changed and the acpi writes a different mode

04:21 <travmurav[m]> jenneron: but re: overlays, my goal is to make sure the firmware setup knobs work properly

04:21 <jenneron[m]> i have a keyboard with backlight support, but i2c hid driver in linux doesn't handle it

04:21 <jenneron[m]> also iirc on galaxy book s some f1-12 keys are just messed up

04:24 <Dylanger> bamse: Cheers

04:25 <travmurav[m]> I guess there are other things I'd like to be able to do on boot, depending on the device, like nuking some stupid uefi reserved memory bits

04:28 <travmurav[m]> and I guess I just don't completely like that the current dtbloader impl requres installing the dtb with a special chid name, I feel like there is not that many devices to just maintain a table of chid(s) -> dtb name (+ optional functions) and let the user/distro just install their dtbs dir into esp

04:29 <travmurav[m]> robclark: as someone who seems to have worked on dtbloader the most, maybe you have any thoughts?

04:34 <Dylanger> I always assumed the defconfig wouldn't work for some reason, but I'll give it a go, I'm guessing it'll generate a massive kernel, I think QC allows for 49MB large kernels, I'll use dracut for initramfs so I can use LUKs + Tang

04:35 <Dylanger> There's an NVMe M.2 somewhere on the thing, looking forward for this to be my new Media Box

04:42 <robclark> travmurav[m]: tbh these days I'm just using kernel cmdline (via sysstemd-boot entries file) to load the dtb from esp... but the dtbloader idea was to present something to distro bootloader and beyond something that looked like EBBR.. the whole using CHID was based having something that could automagicallly figure out what dtb to load.. I guess if distro's want to become more dtb aware/friendly it is not needed and if

04:42 <robclark> dtb fails to become a stable abi it is counterproductive.. I guess it depends on how much you buy into the EBBR concept

04:44 <robclark> for my own personal use, loading kernel version specific dtb is fine.. but it doesn't seem like the most scalable approach long term

04:44 <travmurav[m]> robclark: well, I think it's nice to provide an ebbr-y environment for distros (mostly I'm thinking of iso installers of things like fedora)

04:46 <robclark> yeah, it really comes down to how dtb aware distro's want to be, vs how much they just want fw to be "EBBR".. either way I think CHID is a reasonable approach to figuring out which dtb to load (because device specific installers isn't going to scale).. whether CHID is done by something in "efi land" or by distro bootloader, I guess I could go either way

04:47 <travmurav[m]> basically what I was thinking of right now was: I want to run code fixups on the dtb on some devices anyway, so dtbloader should know the device -> if it knows the device then it can know the dtb name -> then user can just take `install dtbs` output either out-of-band (via fwupd tracking something? manually?) or copy from whereever distro has it's kernel dtbs without renaming anything

04:48 <robclark> or maybe vendors could double down on dtb and ship complete dtb in fw before devices get to consumers.. but we are still a long way from that ;-)

04:48 <robclark> problem is device is really N devices

04:48 <robclark> OEMs substitute parts

04:49 <travmurav[m]> you mean one of many touchpads etc?

04:49 <robclark> even for the chromebooks we usually have many different variants.. which consumers only recognize as a single thing

04:49 <robclark> yeah, touchpads, panels, etc

04:50 <robclark> for the sc7180 chromebooks that needed external edp bridge, we had at least a couple variants

04:50 <travmurav[m]> well, it's also then handled somewhat reasonably: read however firmware detects which is present and set status="failed-absent" for the other one

04:50 <robclark> I think there were audio codec changes, etc

04:50 <travmurav[m]> as in, if in Linux we assume the same dtb

04:51 <robclark> we have a way of dealing with that with strappings for chromebooks.. in the uefi world in theory CHID should be different (but not sure if we have enough data points on that or not)

04:52 <robclark> IME the SKU is different between the variants

04:52 <travmurav[m]> tbh I'm really aware of this mess from the "phones" world, we maintain a special bootloader for a big bunch of qc phones that detects the specific device and almost always have to set display panel compatible and sometimes do ^^^ for a touchscreen

04:53 <robclark> in theory, if vendors follow the rules, CHID should be enough to do this in a more sane way than "one bootloader per device" that you have in the phone world

04:54 <travmurav[m]> no no no

04:54 <travmurav[m]> I mean our bootloader has a table "not-chid-model-detection-rules"->"device and how to fixup it"

04:54 <robclark> not sure if we have enough data points on that yet.. but it hasn't been disproven yet

04:54 <travmurav[m]> so for WoA efi we have chid which drastically simplifies this

04:55 <travmurav[m]> for qc cros I suppose it's a bit more interesting, but I assume for ebbr-y there would be a different, nicer(?) efi provider that would just give us a dtb whichever way cros firmware detects it

04:56 <robclark> cros is no efi.. but there is a mechanism for depthcharge/coreboot stuff to figure out what dtb to pass the kernel

04:58 <robclark> but cros is also a different situation from WoA... in that the ODMs are working with the firmware providers

04:58 <travmurav[m]> yeah I implied that some next stage efi (u-boot/edk2?) is placed instead of a kernel in the usual place

04:58 <travmurav[m]> so it's a different set of problems, probably easier yeah :D

05:01 <travmurav[m]> robclark: well in the end what I wanted to ask is whether you think putting an array of chid-device mappings into the dtbloader has some shortcomings

05:01 <robclark> anyways, the theory is that CHID gives something more standardized than needing to know which random gpio's or whatever you need to look at to figure out "wtf am I running on"

05:02 <robclark> array of chid -> whoami seems sane.. that is kind the approach that dtbloader took

05:02 <robclark> I guess we'll see over time how many special-case hacks we need

05:02 <travmurav[m]> yeah I just want to move it from the dtb filename into the dtbloader itself since I really do want to have device-specific code there

05:02 <robclark> but chid is a somewhat established thing in other spaces like fwupd

05:03 <travmurav[m]> robclark: I suppose dtbloader is nowdays somewhat abandoned?

05:03 <Dylanger> <robclark> "cros is no efi.. but there is..." <- It's pretty nice/easy to use

05:04 <robclark> yeah, doesn't seem to be that much use of it currently... but long term, idk.. right know there is mostly one device (x13s) but if you think the the future I guess/hope there will be a lot more

05:05 <robclark> Dylanger: sure, u-boot for the subset of things that have u-boot support.. but unless you are signing up to implement u-boot support for everything, that doesn't really count

05:05 <travmurav[m]> well I more care about my 7c thingie :P but yes I'm exploring "retrofitting ebbr" for a generic case for past/future WoA

05:06 <travmurav[m]> robclark: btw do you remember why dtbloader was converted into an application instead of a driver?

05:06 <Dylanger> U-Boot support on aarch64 chromebooks would be awesome

05:07 <Dylanger> Not sure why Google had to use something different

05:07 <robclark> I think if retrofitting ebbr is the goal. dtbloader is a good approach.. and defn I think it would be ok to add device awareness to dtbloader.. since it is supposed to be the "hacky thing that makes things appear sane to distro"

05:08 <robclark> travmurav[m]: re app vs driver, check my commit msg.. I think/assume I put reasoning there

05:08 <robclark> Dylanger: for CrOS needs there are pretty good reasons to _not_ have the extensibility of uefi

05:09 <robclark> uefi root kits are a thing

05:09 <Dylanger> Fair

05:09 <travmurav[m]> robclark: it was sadly not helpful to answer "why"

05:09 <travmurav[m]> It only says how to use it via boot order and that it will always boot grub later

05:10 <robclark> travmurav[m]: hmm, I'll look at it again tomorrow and see if I can remember why.. iirc it was because I thought it would be easier for distro's to install that way

05:10 <robclark> but not a thing I'm hard-committed to

05:10 <travmurav[m]> ah I see

05:11 <robclark> ie, whatever works for distro's is fine as far as I care

05:11 <travmurav[m]> yeah I'm just thinking it, in opposite, makes it complicated to make the "retrofit" "seamless"

05:12 <robclark> yeah, I'd kinda like distro's to just get together and decide how they want linux on WoA things to work.. and then we can make dtbloader or grub or whatever do that

05:12 <travmurav[m]> robclark: I think I will play with dtbloader in the future and see if I can make something nice

05:13 <robclark> cool

05:13 <travmurav[m]> I guess another interesting question would be if there is a way to do proper secure-boot in that case - that is, verify the dtb file was not tampered, but I guess that's a bridge far far ahead...

05:17 <robclark> yeah

05:18 <robclark> fwiw, one of the things I was thinking about at the time I was playing with chid was.. and this depends on kernel/dtb discipline to maintain "latest/greatest dtb is always compat with older kernels" was to use fwupd to distribute dtb so that dtb would basically just be a fw update

05:19 <robclark> all fwupd would have to do is learn to drop the dtb's in the esp

05:19 <travmurav[m]> robclark: yeah I also kinda think that dtb should be "out-of-band firmware"

05:19 <robclark> that seems like it could be a reasonably scaleable long term soln

05:22 <robclark> maybe the app vs driver approach was based on what fwupd could install.. idr.. but I was defn think of how we could make this "out of band fw update" from the OS perspective

07:42 <jhovold> steev: nice to see some progress on that mutter crash, sounds like you've been hitting it daily (and falling back to X)?

07:45 <travmurav[m]> <steev> "they're asking for testing; it..." <- fyi it applied on 45.1 fine for me and actually does solve the issue

07:45 <travmurav[m]> (external display crash that is)

07:46 <steev> travmurav[m]: hm, odd... the debian sources *should* be a clean 45.1

07:47 <steev> oh

07:47 <travmurav[m]> (I just plopped 9 patches into the alpine apkbuild for mutter 45.1 expecting to see where it breaks and it worked fine)

07:47 <steev> yeah... it's dry-run that is failing... because patches patch other things

07:47 <steev> i didn't try just going for it anyway :D

07:48 <steev> jhovold: and no... i'm only hitting it with 6.7?

07:49 <steev> ah, i probably have that one patch in 6.6

07:49 <steev> but, i spent all night trying to figure out why the hell we are hitting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035061 and... bleh

07:50 <jhovold> what patch? the mutter crash is a user space issue and i assume you use the same user space with both 6.6 and 6.7?

07:52 <jhovold> iiuc, the mutter wayland compositor crashes on all qcom devices with an external display connected, unless you've patched mutter

07:52 <jhovold> the kernel is not to blame here

07:52 <steev> there was a kernel side patch we had too at one point... and i *thought* i had it in my 6.6 kernel sources, however, i do not seem to

07:54 <steev> weird... my windows machine appears to have locked up - that said, my 6.6.2 does not have that patch, and yet, i can use gnome+wayland on 6.6.2, but rebooting to 6.7.0-rc3 and i cannot

07:54 <travmurav[m]> jhovold: it crashes unless you break msm driver in the kernel in a special way https://github.com/TravMurav/linux/commit/32bdbb4f87972fd40ceb6dc8dd4770fda884dcea

07:54 <steev> yes, that was the commit i used to carry

07:56 <jhovold> travmurav[m]: ah, that rings a bell, thanks for the link

07:57 <steev> but i'm definitely not *now*, and as i said, 6.6.2 works, 6.7.0 does not, i haven't looked deeper but i'll be trying the mutter patch shortly. i know lumag left a comment on it

08:13 <steev> And by shortly, I mean tomorrow, because it’s 2am here

08:14 <steev> And the first build failed unit tests

14:59 <ajhalaney[m]> https://lore.kernel.org/linux-arm-msm/20231129065748.19871-1-quic_sibis@quicinc.com/ hmm, I don't claim to understand SCMI usage very well but I think it is interesting that X1E80100 is using that (afaik other qualcomm platforms don't really)

15:42 <steev> well make them start

15:42 <steev> also, the mutter flaky tests are so annoying

17:45 <clover[m]> i disable tests lol

17:51 <steev> i'm up to 20 builds now :)

17:51 <steev> when it succeeds it errors elsewhere

18:07 <steev> and yeah, i COULD disable tests... and i might if the obsolete directories get to be too much

18:31 <steev> okay, i give up after 22 attempts, overriding the test :D

19:13 <steev> oh my, i think i see why the tests were flaking

19:14 <steev> https://paste.debian.net/1299631/

19:23 <steev> patched mutter, and still can't get gnome+wayland on 6.7.0-rc3, wtf

19:25 <steev> oh ffs

19:26 <steev> our override was back because they bumped the defaults a few times

19:46 <exeat> If a mutter test reliably triggers that issue, it might be helpful for https://gitlab.freedesktop.org/drm/msm/-/issues/33

20:17 <steev> the problem is, i don't know which one is triggering it

20:25 <steev> exeat: i'll add in the info though

20:42 <exeat> steev: nice

20:46 <steev> worst case, it's unhelpful