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
<travmurav[m]>
^^ describes how to either register with the endpoint or, alternatively, use your own SMTP server
<travmurav[m]>
(assuming your mail server doesn't mangle sent patches I guess)
<SpieringsAE>
ah yes, my guide did not specify this, well I just have an outlook account so we'll see
<travmurav[m]>
I think outlook is extra annoying on lkml due to a lot of mail mangling historically
<travmurav[m]>
in my experience people always have problems with outlook mail and lkml
<travmurav[m]>
so i.e. even if you submit the patches fine, you may have trouble responding to reviews from outlook
<SpieringsAE>
well it looks good, so lets go I guess
<SpieringsAE>
I think I messed something up, its missing the tags like arm: dts: and stuff
<travmurav[m]>
you're supposed to manually compose the commit message/subject and cover letter, tooling won't guess that for you
chrisl has quit [Ping timeout: 480 seconds]
<SpieringsAE>
yeah I did write some things in de cover letter
<SpieringsAE>
but I guess that part was unclear
<travmurav[m]>
SpieringsAE: also just in case want to note that "checkpatch" step of the guide is important as it will easily find many formal mistakes in the patches you're preparing
<SpieringsAE>
check patch did run, it denied me on my commit message so I expanded that
<SpieringsAE>
it ran when I did b4 send --reflect
<travmurav[m]>
SpieringsAE: yeah right, newer b4 runs checks itself, though I'm not sure if it always runs them since iirc last time for me it only run them once
<JensGlathe[m]>
you need to create keYs and register them with challenge response once, as described in the page travmurav pointed to.
<travmurav[m]>
or have git-send-email configured for smtp :D
<JensGlathe[m]>
that wouldbe the masochistic approach
<SpieringsAE>
I guess I would have to add arm64: dts: qcom: x1e80100-asus-vivobook-s15:
<SpieringsAE>
Or drop that last one?
<travmurav[m]>
SpieringsAE: the commit is fine apart from the subject prefix (should be as you say ^^) and s-o-b being in the cut, so it's not in the actual commit
<travmurav[m]>
SpieringsAE: so i.e. you generally want to "commit -s" your changes to let git put the tag in automatically
<JensGlathe[m]>
no you need all sorta, maybe a shortened string for the last one bc it leaves no room for a useful description
<travmurav[m]>
+ might want to change your git settings to capitalize the name if it wasn't intentional to have it all lowercase :D
<SpieringsAE>
yeah I tend to forget capitalization sometimes so it was accidental
<JensGlathe[m]>
has anybody added an iris node already?
<SpieringsAE>
I think only on x13s from what I saaw
<JensGlathe[m]>
oh interesting, thanks
<SpieringsAE>
wait no, I think I confused venus with iris
<JensGlathe[m]>
no prob. Still fighting with a newer - ish ubuntu config. The things i've seen 🙀
<SpieringsAE>
is iris camera stuff isp and stuff?
<JensGlathe[m]>
The same dtb on 6.12rc6 and 6.11.0-47 do different things, 6.11.0-47 gets gpio conflicts for the PS8830 retimers - weird
<JensGlathe[m]>
iris is video codec
<SpieringsAE>
that is odd indeed
<SpieringsAE>
ah okay encoders/decoders?
<JensGlathe[m]>
yes
<JensGlathe[m]>
and x1e ships with iris firmware too
<SpieringsAE>
I've been having a rough time at work with those on an imx8mp
<SpieringsAE>
I am really starting to dislike that thing
<macc24>
JensGlathe[m]: is it signed per-device model again?
<JensGlathe[m]>
pretty sure. Why not keep all the annoying practices
nothorseface has quit []
nothorseface has joined #aarch64-laptops
nothorseface has quit []
chrisl has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<SpieringsAE>
I fear that the vivobook-s15 part of the firmware might be too generic, I think S5507Q/QA might have been a better choice
<SpieringsAE>
I guess we'll get past that if that issue ever props up
<JosDehaes[m]>
@_oftc_bryanodonoghue:matrix.org: search the AUR PKGBUILD for widevine (for some reason it was removed), and build it
alfredo has quit [Ping timeout: 480 seconds]
nothorseface has joined #aarch64-laptops
<SpieringsAE>
There is this weird thing on this asus, the fn key doesn't seem to work
<travmurav[m]>
SpieringsAE: for media keys?
<SpieringsAE>
in wev and keyd monitor it shows nothing, when I press fn + f# I get nothing
<SpieringsAE>
yeah
<travmurav[m]>
might be that EC internally handles the fn key and expects some notification from acpi to enable it
<travmurav[m]>
which is done to make sure firmware always has f1 f2 etc
<SpieringsAE>
that seems annoying, there is some setting in the bios about the fn key I'm gonna try switching that one
SpieringsAE has quit [Remote host closed the connection]
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
well, that did something, f1/mute f2/audiodown f3/audioup work now, but the rest still not lol
<travmurav[m]>
oh so it started sending media keys?
<travmurav[m]>
or it only sends f1 f2 etc?
<SpieringsAE>
a couple of them at least
<travmurav[m]>
weird
<SpieringsAE>
but no brightness/microphone
<travmurav[m]>
but i.e. on aspire1 it was always sending f1 f2 regardless of fn pressed or not until I send it a notification that "os has booted"
<SpieringsAE>
there is one other one that does something, it is the projector button or something, f7, it now sends left meta + p with fn
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<macc24>
<SpieringsAE> "in wev and keyd monitor it shows..." <- hold on let me check one thing
<macc24>
it might be implemented similarly to slim7x as on key press the ec does an irq and host finds the key value in 0x05 smbus register
<bamse>
deathmist: effectively all of power management is handled in a driver on the OS-side, rather than using ACPI mechanisms
<bamse>
deathmist: add to this that many devices aren't obvious how to describe using ACPI devices...
<bamse>
deathmist: so we have some work to do across firmware, specification and implementation to get there
<SpieringsAE>
about that, I'm currently still living without a battery indicator, which I don't really like, I heard something about pd-mapper, so I installed that from the aur but it just says 'no pd maps available'
<SpieringsAE>
do I need some specific module for it?
<SpieringsAE>
JensGlathe[m]: yep got all of those
<jhovold>
is the fw path correct?
<jhovold>
i.e. match what's in your dts?
<SpieringsAE>
the gpu firmware loads correctly
<SpieringsAE>
let me double check
<jhovold>
check the adsp node as well
<travmurav[m]>
I recall pd-mapper reads sysfs to check what's the path of the firmware file that was loaded to the remoteproc to find .jsn near it, so perhaps a "dumb" question but did adsp/cdsp even boot? ;D
<bamse>
indeed, if you run "grep '' /sys/class/remoteproc/*/firmware | cut -d: -f2 | xargs dirname" you will get the path(s) that it will use, and then it tries to load any *.jsn therein
<bamse>
well, prefix that/those with /lib/firmware/
<SpieringsAE>
I think I should maybe try unblacklisting those
<JensGlathe[m]>
when you boot from nvme that is
<SpieringsAE>
yeah I boot from nvme right now
<SpieringsAE>
I guess those are related to that issue where the usb will reset during boot and then break the boot procedure
<JensGlathe[m]>
yes
<bamse>
the q6v5_pas is...the qcom_edac results in a crash on x1e devices; so that unrelated, but might still be needed, depending on the workaround for that having made it into whichever branch you're using
<SpieringsAE>
okay I will only remove q6v5_pas first
SpieringsAE has quit [Remote host closed the connection]
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
and I'm back, now with battery percentage wooo
<travmurav[m]>
and I'd guess you didn't have sound working before ;P
<Sayatomoki[m]>
x13s's usb-c dp alt mode only output 4k/30hz?
<JensGlathe[m]>
yes, 2 lanes only
<bamse>
SpieringsAE: that warning is normal
<SpieringsAE>
travmurav[m]: very likely yeah didn't try tbh, but this dtb is still quite barebones
<Sayatomoki[m]>
oh...
<JensGlathe[m]>
SpieringsAE: Looking sorta normal, I also get this timeout
<bamse>
Sayatomoki[m]: there's a patchset on the list which enables switching between 2 and 4 lane USB/DP... but the USB controller gets upset and you often loose USB support after the switch
<travmurav[m]>
speaking of 2 lane dp, is there any way currently to force 4 lanes on those devices (8c3,x1e) even if it breaks orientation/usb/etc?
<travmurav[m]>
cool I guess that's the answer xD
<Sayatomoki[m]>
the list?
<Jasper[m]>
bamse: Any soc limits?
<Jasper[m]>
@[Saya tomoki] Linux Kernel Mailing List
<bamse>
Jasper[m]: no, it's a implementation issue on our side, hardware can do it just fine
<Jasper[m]>
bamse: Ah, also sm8x50
<Jasper[m]>
Was wondering what socs the patch applies to
<bamse>
all the qcom socs where we support DP (that physically has 4 lanes available)
<bamse>
well, all socs has that, but not all boards do
SpieringsAE has quit [Remote host closed the connection]
nothorseface has quit []
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
hmmm i ran `b4 prep --set-prefixes arm64: dts: qcom: x1e80100-vivobook-s15:` and it made this: [PATCH arm64: dts: qcom: x1e80100-vivobook-s15: v2] Enable the gpu
<SpieringsAE>
which definetly does not seem like the other things I see on the mailing list
<travmurav[m]>
SpieringsAE: noo, you just reword the commit message
<SpieringsAE>
that too, but I have to add the prefixes
<SpieringsAE>
I feel like that should work
<SpieringsAE>
its pretty good now
<travmurav[m]>
well yes, you add them manually when you reword the commit message
<travmurav[m]>
the --set-prefixes has different semantics completely
<travmurav[m]>
like, whatever you see in git history of linux, you would also just write in your commits as if you were to make a PR
<travmurav[m]>
and b4 prefixes are for send-email, i.e. if you want to send [PATCH RFC] to note it's a draft
<SpieringsAE>
it seems to me like I have to put it in the cover letter
<SpieringsAE>
ah okay
<SpieringsAE>
it was indeed the commit I think I've got it now
<SpieringsAE>
this b4 tool is very neat
<travmurav[m]>
SpieringsAE: also I think author name should be exactly the same as s-o-b name so you may want to commit --amend --author="Blah <email>" to fix the author
<SpieringsAE>
jep that did do it
<SpieringsAE>
Okay I think thats everything addressed
<bamse>
SpieringsAE: "apply comments by ...", please next time describe what those changes as...perhaps bjorn forgot what he asked about, or perhaps someone else wants to understand what you changed without checking what was asked
<bamse>
SpieringsAE: patch looks good now though...think i will be able to get it included in v6.13
* bamse
is bjorn, fyi...
<bamse>
SpieringsAE: thank you for your contribution!
<SpieringsAE>
weee thank you for your review and this additional comment, its been a learning day
<agl>
steev: Do you do nothing more for the x13s. I ask because now ist the kernel 6.11.7 but your last kernel is 6.11.0. Or are the versions since 6.11.0 not important for the x13s?
chrisl has joined #aarch64-laptops
<travmurav[m]>
fwiw third number is a patchnum for stable backports and many people (dunno if steev's workflow is that) completely ignore stable, so the next thing after 6.11 is 6.12-rc1 or, if you ignore rc, not yet released 6.12.0
<steev>
agl: no i still do, i just haven't pushed
<agl>
steev: I have compiled/installed 6.12-rc6 of jhovold. It runs good.
<steev>
indeed it does
chrisl has quit [Ping timeout: 480 seconds]
<agl>
steev: I will wait for your new kernel ...
<SpieringsAE>
Now that I know how to send patches I'm finally going to fix a documentation fault in the input subsystem, it cost me a bit of time debugging once
<craftyguy>
jhovold: in-kernel pd mapper is disabled for x13s in your branch? Or earlier did you mean the newer soc kernel ?
nothorseface has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<jhovold>
craftyguy: it's only disabled for x1e as I wasn't able to reproduce the issues on the x13s
<jhovold>
probe order and other changes in timing can mask the issue so that doesn't necessarily mean we can't hit this also on the x13s however
jhovold has quit [Quit: WeeChat 4.4.2]
jhovold has joined #aarch64-laptops
nothorseface has quit []
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<craftyguy>
jhovold: thanks. currently I'm expecting the in-kernel pd mapper is enabled for the x13s since I've disabled the userspace pd mapper service in pmOS... so I was wondering if I had to go re-enable that :P
kettenis has quit [Remote host closed the connection]
nothorseface has joined #aarch64-laptops
SpieringsAE has quit [Quit: SpieringsAE]
<alexlanzano>
jhovold: What regressions did you see? I have in-kernel pd-mapper enabled on my slim 7x and havent noticed any issues. Im running torvalds master btw
kettenis has joined #aarch64-laptops
nothorseface has quit []
<JensGlathe[m]>
oof
<JensGlathe[m]>
thermal shutdown on compiling the kernel, grrr
nothorseface has joined #aarch64-laptops
<agl>
JensGlathe[m]: At which computer?
<JensGlathe[m]>
HP Omnibook X14
<JensGlathe[m]>
with 12.6-rc6. now on Ubuntu Kernel 6.11.0-49, let's see what happens
<JensGlathe[m]>
They have a deviating x1e80100.dtsi
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
and again, not satisfying
jhovold has quit [Ping timeout: 480 seconds]
davidinux has joined #aarch64-laptops
indy has quit [Ping timeout: 480 seconds]
davidinux has quit [Quit: WeeChat 4.3.1]
weirdtreething has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
weirdtreething has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]