ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
<steev>
clover[m]: snapdragon 850
<steev>
it's an 845 with a few extra opps? i think
<HdkR>
Bigger numbers++
<leezu>
steev: I built 3.38 but it crashes in get_font_gsettings g_settings_get_enum. How did you configure your system to run both 3.38 and 42/43?
<leezu>
trace trap (core dumped) does not contain a key named 'hinting'
<steev>
leezu: i didn't
<steev>
the x13s runs debian stable, the flex and c630 run debian testing
flowriser has joined #aarch64-laptops
<leezu>
OK. Per gentoo, downgrading gnome-settings-daemon should help. I'm just looking for a setup to bisect the bug
<steev>
ah, that makes sense, sorry i wasn't clearer :(
<leezu>
No worries. If you have ideas how to configure mutter to avoid reaching out to gnome-settings-daemon please let me know :D
<steev>
i don't think there is a way to
<steev>
at least, not without patching out all the calls
<steev>
though... i don't know WHY there is
<steev>
it should be doable with just the right schemas
pierro78 has quit [Remote host closed the connection]
hexdump01 has joined #aarch64-laptops
<leezu>
Hm, according to meson.build, it's already optional "gnome_settings_daemon_dep = dependency('gnome-settings-daemon', required: false)"
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev>
oh, i missed the required at the end
<leezu>
But it's unclear how to actually disable it. Do you know that?
<leezu>
Ok, I found a commit between 3.38 and 40 that works with the newer gnome-settings-daemon but does not yet contain the bug
<steev>
oh, that's good!
<steev>
sorry, i was reading the opengl stuff alyssa wrote about
<leezu>
Do you know how to cleanly quit mutter? Alt+F2 causes another segfault which confuses my bisect script..
<steev>
i think you might be able to do -Dgnome-settings-daemon=false for the option?
<steev>
i'm not sure if this is doable, but mutter should follow iccm, so it should exit if another wm claims the session??
<steev>
i was hoping wmctrl might do something, but i'm not sure it can
<steev>
ah, it's X only anyway, i think
flowriser has quit [Remote host closed the connection]
<gwolf>
steev: Well, I don't know the details about Wayland libraries, compositors and stuff... but I understand their architecture is way more different than different WMs under X
<gwolf>
this is, sway and some similar compositors are implemented using wlroots (and many tools such as wdisplay, wf-recorder, wayvnc target wlroots)
<gwolf>
...and GNOME uses a completely different base
<steev>
sounds about right
klardotsh has quit [Read error: Connection reset by peer]
klardotsh has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
klardotsh_ has joined #aarch64-laptops
klardotsh has quit [Read error: No route to host]
klardotsh has joined #aarch64-laptops
klardotsh_ has quit [Ping timeout: 480 seconds]
<steev>
leezu: is it possible to revert that, or is there a bunch of stuff on top
<travmurav[m]>
jenneron: afaiu from uefiplat you would need to look at the regions marked as "Reserv", tho afaict yours have only few interesting ones... Otherwise I'd expect xbl/hyp to be loaded at the usual address that should be defined in the SoC dtsi. Interestingly both for you and for me the "MPSS_EFS" seem to match mainline xbl, tho I'd assume it's the rmtfs region. Maybe xbl unloads? Or it's some dumb mistake/hack from qcom
frytaped is now known as Guest866
frytaped has joined #aarch64-laptops
flowriser has quit [Ping timeout: 480 seconds]
frytaped has quit [Read error: Connection reset by peer]
<clover[m]>
not even the headphone jack works on X13s :\
<steev>
correct, we do not have the dt bindings yet
<clover[m]>
is that something we have to wait on lenovo for?
<steev>
nah, just when srinik finishes up his testing and sends them out
<steev>
i'm assuming it will be dt bindings and alsa ucm configs sent roughly around the same time
<clover[m]>
so its WIP?
<steev>
yes
<steev>
and wip as in, the dev is working on it, and it's not to the point where getting reports of X/Y don't work, will speed up the development ;)
frytaped has joined #aarch64-laptops
<clover[m]>
are these volunteers?
<clover[m]>
or do they get paid for this work
<clover[m]>
are x13s devs working on gamma LUT for night mode?
<steev>
i believe they work for linaro. and no idea about gamma lut
<steev>
i haven't worked at a device vendor in about 10 years, i don't really know about the inner workings anymore (i was around when linaro first started)
<clover[m]>
it works on the windows side but when i set it in gnome settings it doesnt seem to do anything
<steev>
we don't even have gpu yet :)
<travmurav[m]>
I think whatever is used for the redshift is absent on all of qcom SoC's
<travmurav[m]>
that is the interface is not implemented afaiu
<steev>
then it needs to be done in software, like it is in windows, i would think
<szclsya[m]>
but you can still do it in software though, with loss of color space
<travmurav[m]>
tbh I'd love to have the option of at least software based correction, but so far no (wayland) tool I've tried over the years could actually do reshift
<szclsya[m]>
(but if you are using night mode color accuracy shouldn't be a major concern anyway
<travmurav[m]>
In hardware my guess would be that the mdss (mdp/dpu) would be responsible for color correction, not gpu
<travmurav[m]>
and I vaguely remember something about there being "old interface" and "new better interface" for that which makes stuff more fun
<steev>
i know there's a lot of flux for the dpu right now, no idea when it'll all shake out
<travmurav[m]>
is there any public kernel tree for 8c* that has a device with working sound?
<HdkR>
I also recall that there is some new hotness that isn't wired up in any DEs for nightshift LUT
<steev>
travmurav[m]: maybe the downstream stuff?
<steev>
which, i thought i had around here, but i'm not finding now
<travmurav[m]>
Well, I implied mainline (unless you mean "almost mainline but not Torvalds just yet" kind of downstream :)
<steev>
nah, i meant android 5.4 msm
<steev>
closest we get is a 7cx i think
<travmurav[m]>
right, well, I think I have that for my 7c
<travmurav[m]>
well
<travmurav[m]>
if you mean chromebooks, those don't count
<steev>
agreed, and sadly that is what i meant
<travmurav[m]>
they have still-mostly-proprietaary-but-tf-a that doesn't block stuff from the owner so they can bypass the adsp
<travmurav[m]>
but In my case this doesn't work so I was hoping to look at some example of hooking the adsp audio up on those newest platforms
flowriser has joined #aarch64-laptops
<travmurav[m]>
as trying to do it myself failed last time I tried (probably made some mistake in the native code side)
<travmurav[m]>
or it uses some completely different stuff and the kernel just can't tell it's all broken until it attempts to make noise, at which point everything burns down
iivanov has joined #aarch64-laptops
<jenneron[m]>
travmurav: yeah, rmtfs overlaps with sc8180x.dtsi xbl, also mpss is different in that file from windows registry
<jenneron[m]>
the problem is that it doesn't work using values from windows registry except using default rmtfs
<steev>
there's a comment in the spx dts about that too
<jenneron[m]>
steev: do you mean a comment about using lenovo flex 5g rmtfs region?
<steev>
yeah
<steev>
and sizes and such
<jenneron[m]>
the difference is that it doesn't work for me
<steev>
oh, interesting
<steev>
maybe qzed might have some insight, i'm not sure
<travmurav[m]>
jenneron: is some remoteproc fails to load or the device crashes?
<jenneron[m]>
travmurav: fails to load mpss firmware
flowriser has quit [Remote host closed the connection]
<jenneron[m]>
travmurav: it may not load because of rmtfs region, but i don't know where to move everything else e.g. xbl if i change this
<travmurav[m]>
does it overlap it?
<jenneron[m]>
yes
<jenneron[m]>
windows rmtfs region overlaps sc8180x.dtsi's xbl
<jenneron[m]>
and maybe some other regions
<travmurav[m]>
well, you can't "move" things like xbl as you're not the one loading it but it's the bootloader. So you could try removing xbl and putting rmtfs there in case it's not protected memory anymore
<qzed>
as far as I can tell, for the remoteproc stuff you should only need to allocate a properly aligned region in range 0x8bd80000 to 0x9a500000 with enough capacity... but that's mostly inferred from the windows loader driver
<jenneron[m]>
oh, it still seems to overlap with adsp
<qzed>
could be though that mpss needs some kind of special address... at least on the spx it was the only node with an address defined in the inf/registry
<qzed>
right, you also don't want overlapping stuff xD
<jenneron[m]>
i'm just not that good with numbers :D
<qzed>
having to move and manage all that is mostly the reason why I wrote the comment in the spx dts, so I can kinda recommend going through everything, writing down the fixed addresses (like XBL which I forgot there) and shuffling the flexible parts around until you have something that fits
<jenneron[m]>
i think i can disable adsp to test it
<qzed>
as far as I can tell, the windows driver does that stuff dynamically, so it checks the registry for nodes defined with an address, places them, and then just puts the other regions wherever there's space in the range designed for pil
<qzed>
<jenneron[m]> "does gpu has to be in this range..." <- the gfxsuc/zap-shader thing yes, I think
pierro78___ has joined #aarch64-laptops
<pierro78___>
jenneron it will be easier for me to test the new dtb tonight ... I am at the office this afternoon and as I told yesterday I don t have ethernet internet here which makes things difficult ... thanks btw !
<jenneron[m]>
ok
pierro78___ has quit [Quit: Page closed]
jelly has quit [Ping timeout: 480 seconds]
jelly has joined #aarch64-laptops
Penguinpee has quit [Remote host closed the connection]
<robclark>
abelvesa: hmm, afaiu from dianders and sboyd that revert got sc7180 things working.. but haven't yet had a chance to try it myself
<dianders>
I think it might still report a cyclic dependency after the revert but at least it still ends up working in the end? I can double check in a bit if need be. Greg landed the revert this morning, though...
<steev>
abelvesa: second one is just the ending of the dmesg since /sys/kernel/debug isn't available in the initramfs
<abelvesa>
robclark: maybe the revert fixes a different thing than the cyclic dependency steev, bamse and I are talking about
<steev>
the revert that rob sent... sometimes? works, but there's spews of stuff in the dmesg
<abelvesa>
robclark, dianders: the issue I'm talking about is a very specific dependency between dispcc and dsi1-phy
<abelvesa>
and mdss
<abelvesa>
maybe the sc7180 has a different issue
<abelvesa>
mani_s: do you have a way to get the log from a kernel that doesn't reach initramfs on x13s ?
<abelvesa>
steev: would be helpful to see the entire logs for the patchset robclark has mentioned
<jenneron[m]>
you need 3 user-space services for it: pd-mapper, tqftpserv, rmtfs, i'm not sure this debian installation has these pre-installed
<jenneron[m]>
btw better use paste.debian.net
pierro78___ has joined #aarch64-laptops
<clover[m]>
Steev: sometimes when I reboot out of windows into Linux, kernel can't find my root partition and will go into a rescue shell
<clover[m]>
Holding power button to fold boot fixes it
<clover[m]>
Cold boot*
<pierro78___>
ok jenneron I don t have ethernet internet here so I ll try to install these tools tonight ...
pierro78___ has quit [Quit: Page closed]
<mani_s>
abelvesa, try earlycon=efifb in cmdline
<javierm>
abelvesa: what I usually use is "earlycon efi=debug debug initcall_debug log_buf_len=16M ignore_loglevel keep_bootcon boot_delay=100"
<mani_s>
javierm, you need to use efifb as the earlycon device to see the bootlog in crashing scenarios
Penguinpee has joined #aarch64-laptops
<abelvesa>
steev: ^^^
<steev>
right, okay - as for the patchset rob linked, things look good on the x13s with those reverts in place (there is still an occasional dpu doesn't seem to come up properly). mostly good on the c630 as well, but on the flex5g, there are a lot of 517s. if all we care about "upstream" for now, is the x13s to get lenovo to care about upstreaming more, then i'd say for now, x13s looks "good" but i need to test booting it more
<steev>
which i can do after work
matthias_bgg has quit [Quit: Leaving]
<javierm>
mani_s: is that true? I think that using without any options would use it anyways on EFI systems
<javierm>
or would default to serial output? I find it in practice that's not needed. Although is true that's better to make it explicit
<javierm>
mani_s: for instance, I don't use efifb but simpledrm that also supports the EFI-GOP
<mani_s>
javierm, this is what documented in kernel-parameters.txt
<mani_s>
earlycon= [KNL] Output early console device and options.
<mani_s>
When used with no options, the early console is
<mani_s>
determined by stdout-path property in device tree's
<mani_s>
chosen node or the ACPI SPCR table if supported by
<mani_s>
the platform.
<javierm>
mani_s: yes, so it depends on what you have in the DTB or ACPI tables as default
<mani_s>
javierm, there is no stdout property for x13s in dt and i'm not sure about acpi spcr
<abelvesa>
mani_s: earlycon is mostly useful when the proper console hasn't managed to probe before the hang
<abelvesa>
I don't see its usefulness here, TBH
<mani_s>
abelvesa, when you said, "a way to get the log from a kernel that doesn't reach initramfs" I thought the crash before the console probe
<steev>
i can always just connect a usb drive and dmesg > usbdevicemount
<abelvesa>
oh, my bad
<steev>
dianders: ah, crud, thank you for fixing that... i sent a v2 and didn't even notice, will remember to triple check in the future
<dianders>
steev: meh, no worries. It's impossible to be so paranoid that you never make mistakes like that. ;-)
<steev>
i've got another one coming at some point for the panel in the flex5g
<pierro78>
jenneron the 3 services were actually included ... pd-mapper fails to start (message at boot), its log has following error : "Aug 10 20:18:16 debian pd-mapper[571]: no pd maps available"
<pierro78>
jenneron I tried to start xfce and it didn t start ... there was a lot of errors in the boot console ... here is dmesg : https://paste.debian.net/1251484/ ... oh debian just crashed and the galaxy book s has rebooted ...
<jenneron[m]>
pierro78: did it happen before latest dtb?
<pierro78>
jenneron ... no it was working ... but I ve just done a "dist-upgrade" ... xfce was working with latest dtb before dist-upgrade ..
<pierro78>
(it takes some time to run so I just paste it there jenneron)
<jenneron[m]>
that's not good
<jenneron[m]>
it means no touchscreen
<pierro78>
right no touchscreen but I thought it was working before ...
<pierro78>
I can reboot in 5.11 to check ...
<jenneron[m]>
at least with dtb
<jenneron[m]>
idk what ACPI does to the needed regulator, but when i enable it in dts, it fails with failed to get current voltage error
<jenneron[m]>
actually it can be some always on regulator and the issue may be a reset gpio
<pierro78>
jenneron I wanted to test docker but it looks like kernel module br_netfilter is not there ...
<jenneron[m]>
yeah it's a minimal config
<jenneron[m]>
iirc
<jenneron[m]>
but docker is possible with proper kernel config
<pierro78>
jenneron I also noticed it doesn t draw power from charger ... with another I drew power from charger (but not enough power to charge the battery, only about 6W power to power the laptop I think ...)
<pierro78>
(another DTB iT)
<jenneron[m]>
it's because i disabled adsp for now
<jenneron[m]>
steev: do you mean my touchscreen regulator issue?
<steev>
no
<jenneron[m]>
so, why..
<jenneron[m]>
just want to know
<steev>
i thought it was spelled out in the commit message, but because if you have "remoteproc: qcom_q6v5_pas: Deal silently with optional px and cx regulators" (and i do believe your tree should), and you do not have that fix, it will return -ENODEV when it should continue for optional regulators
<pierro78>
it looks like it s taking its time to crash jenneron ...
<pierro78>
it s kind of stuck
<jenneron[m]>
ok, forget about the latest dtb, bad change
<jenneron[m]>
i should probably stop bisecting this
<jenneron[m]>
it may take long time
<leezu>
steev: I don't think we can to revert that commit. Essentially it's one commit in a series to enable kernel atomic mode setting. I'll test a few older kernels because I think this used to work..
<jenneron[m]>
qzed: is it possible that my device has another range? it seems to be impossible to bind everything (gpu, mpss, adsp) in 0x8bd80000-0x9a500000. how can i check this?
<qzed>
jenneron: I guess it's possible if other things are relocatable... I'm not sure though
<qzed>
I derived that from the reserved memory stuff shown in the windows device manager
<qzed>
I haven't checked the driver in which region it actually allocates things, so that might be an option to check
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
pierro78 has quit [Remote host closed the connection]