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
<craftyguy>
abby: I installed wev and it seems to report sysrq when I push fn+s: sym: Sys_Req (65301), utf8: ''
<abby>
hm, xev wasn't reporting it iirc
<craftyguy>
some of the other bindings on that page you sent also work, like setting keyboard backlight
<abby>
yeah some of them work
<craftyguy>
so maybe sysrq is actually working? I couldn't get it to work earlier when doing the alt+sysrq magic stuff to sync/reboot...
<craftyguy>
I kinda assume I was supposed to hold alt, then press fn+s for sysrq, release fn+s and continue holding alt while doing the rest of the dance?
<craftyguy>
else there's no way to press 's' for sync 🤷
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
nothorseface has quit []
hipboi has joined #aarch64-laptops
juergh_ has joined #aarch64-laptops
juergh has quit [Ping timeout: 480 seconds]
<craftyguy>
hmm, resuming from suspend on my x13s w/ jhovold's 6.12-rc6 fails every time (3 for 3) w/o an external display connected. anyone else see this?
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
agl has quit []
agl has joined #aarch64-laptops
agl has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
agl has joined #aarch64-laptops
kul has joined #aarch64-laptops
kul has left #aarch64-laptops [Leaving]
hipboi has quit [Quit: hipboi]
hipboi has joined #aarch64-laptops
nothorseface has joined #aarch64-laptops
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
<bamse>
craftyguy: what does "fail" mean here?
<bamse>
i pulled in the -rc6 packet from arch here, and it did a suspend/resume cycle without any complaints in the log...
<craftyguy>
no display/backlight
<craftyguy>
connected external display and got nothing either
<craftyguy>
all three times it was suspended for >30min, not sure if that has something to do with it
<bamse>
(i presume you've checked that the system is still happily running, just that display is dead)
<craftyguy>
I haven't been able to check that the system is happily running, I've not been in a situation yet where I can try pinging or sshing to it (at cafes and stuff)
<craftyguy>
switching VTs doesn't appear to work, and I was mashing magic sysrq and it didn't appear to respond but there's some confusion about whether sysrq key mapping on the x13s works?
<craftyguy>
(I hve magic sysrq enabled in kernel)
<craftyguy>
I'll check my sway config when I'm back at the system, thanks for the link
hipboi has joined #aarch64-laptops
hipboi has quit []
hipboi has joined #aarch64-laptops
hipboi has quit []
hipboi has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
<craftyguy>
abby: fyi evtest also shows sysrq is coming through when I hit fn+s. it just doesn't seem to work when I resume from suspend and have no display output :/
<abby>
are you sure it actually resumed?
<craftyguy>
nope! because I have no display
<craftyguy>
that's the problem :P
<craftyguy>
open lid and/or tap pwr button (two things that used to wake it), don't seem to wake it anymore or ??
hipboi has quit [Quit: hipboi]
iivanov has joined #aarch64-laptops
hipboi has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
alfredo has quit []
iivanov_ has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
deathmist has quit [Ping timeout: 480 seconds]
nothorseface has quit []
iivanov has quit [Ping timeout: 480 seconds]
nothorseface has joined #aarch64-laptops
nothorseface has quit []
nothorseface has joined #aarch64-laptops
hipboi has quit [Quit: hipboi]
deathmist has joined #aarch64-laptops
hipboi has joined #aarch64-laptops
srinik has joined #aarch64-laptops
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
iivanov_ has joined #aarch64-laptops
iivanov_ has quit [Remote host closed the connection]
iivanov has quit [Read error: No route to host]
iivanov has joined #aarch64-laptops
tobhe has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
<deathmist>
bamse: hm so there never even were DSDT bits for some things but only PEP drivers providing the ACPI methods? is the spec that much more restrictive in comparison to "the wild west that is device-tree" especially historically? I assume that's why power management is seemingly "non-existent" currently on Linux side too on X1E?
<JensGlathe[m]>
wdym
<deathmist>
JensGlathe[m]: with regard to what part :p it was mostly a reply to "many devices aren't obvious how to describe using ACPI devices so we have some work to do across firmware, specification and implementation to get there"
<travmurav[m]>
I'd say acpi for wos is at the state it is because intel never thought acpi would be applied to pure mmio systems like what's often done in the embedded world
<JensGlathe[m]>
Power management on x1e is working
<travmurav[m]>
like on x86 you get mostly stuff like pcie glue etc to pretend IP blocks are discoverable
<travmurav[m]>
but then with pcie glue you still need to control the resources of ip blocks like clocks and power domains
<deathmist>
JensGlathe[m]: what kinda battery life do you get? I read somewhere someone got 6 hours and I've seen the signs of early bringup states still with "pd_ignore_unused clk_ignore_unused" kernel cmdline stuff which certainly won't help there
<macc24>
travmurav[m]: are there even any non-mmio devices on modern x86 besides the superio?
<macc24>
and the ec*
<travmurav[m]>
well I meant pure mmio vs "discoverable" stuff via pci(e) glue
<macc24>
ah
<travmurav[m]>
so like we have stuff just thrown into the address space
<travmurav[m]>
but the point is, we also have centralized resource control for clocks, power domains etc
<deathmist>
ah and also "fw_devlink=off", never messed with mainline enough to remember if that could affect power usage too
<travmurav[m]>
which, arguably, makes it possible to save more power by controlling those things more carefully from the OS
<travmurav[m]>
but I'm not sure if acpi allows to describe such an intricate system
<macc24>
and yet, qcom did it xD
<travmurav[m]>
well qcom didn't do it, they found an easier way of throwing stuff into driver code :D
<travmurav[m]>
bu then again, linux has very mature support for qcom and x1e is pretty much the same stuff with few things changed
<travmurav[m]>
and afaiu currently x1e can go into dram selfrefresh level of sleep, just with few subsystems broken?
<travmurav[m]>
though I'm still really confused how Jens Glathe 's laptop sleeps so well without sleep stats ticking xD
<travmurav[m]>
but I guess those boards were designed with more qcom guidance/design and not the x86 fixed forced regulators shit I get on aspire1 -_-
<macc24>
afaict a lot was copypasted from crd
<travmurav[m]>
and even with half of the board forced powered on I get a week of suspend on that thing
<Jasper[m]>
travmurav[m]: Except for maybe the Dell?
<travmurav[m]>
so I guess x1e designs are better when they don't ahve to deal with that crap
davidinux has joined #aarch64-laptops
<Jasper[m]>
iirc they gloated about reusing the intel board design (and were complaining about PMIC's)
<travmurav[m]>
Well eh, I'd be surprised if someone went beyond just copying the reference design tbh
<travmurav[m]>
so I'd assume the laptops are only different by the chassis and the amount of mistakes vendor made when copying from the reference design xD
dbalan has quit [Quit: Bridge terminating on SIGTERM]
\[m] has quit [Quit: Bridge terminating on SIGTERM]
kuruczgy[m] has quit [Quit: Bridge terminating on SIGTERM]
JosDehaes[m] has quit [Quit: Bridge terminating on SIGTERM]
Dylanger[m] has quit [Quit: Bridge terminating on SIGTERM]
MrCatfood[m] has quit [Quit: Bridge terminating on SIGTERM]
Eighth_Doctor has quit []
travmurav[m] has quit [Quit: Bridge terminating on SIGTERM]
noisycoil[m] has quit []
nirik has quit [Quit: Bridge terminating on SIGTERM]
macc24 has quit [Quit: Bridge terminating on SIGTERM]
freekurt[m] has quit [Quit: Bridge terminating on SIGTERM]
dcavalca has quit [Quit: Bridge terminating on SIGTERM]
erebion[m] has quit [Quit: Bridge terminating on SIGTERM]
KieranBingham[m] has quit [Quit: Bridge terminating on SIGTERM]
JensGlathe[m] has quit [Quit: Bridge terminating on SIGTERM]
konradybcio has quit [Quit: Bridge terminating on SIGTERM]
amstan has quit [Quit: Bridge terminating on SIGTERM]
emily[m] has quit [Quit: Bridge terminating on SIGTERM]
Nios34[m] has quit [Quit: Bridge terminating on SIGTERM]
zeph[m] has quit [Quit: Bridge terminating on SIGTERM]
steveej[m] has quit [Quit: Bridge terminating on SIGTERM]
bumble[m] has quit [Quit: Bridge terminating on SIGTERM]
NecoArc has quit [Quit: Bridge terminating on SIGTERM]
mynery[m] has quit [Read error: Connection reset by peer]
EricMolitor[m] has quit [Read error: Connection reset by peer]
integral[f][m] has quit [Quit: Bridge terminating on SIGTERM]
DenysVitali[m] has quit [Read error: Connection reset by peer]
shjim[m] has quit [Read error: Connection reset by peer]
farchord has quit [Read error: Connection reset by peer]
snypaper[m] has quit [Read error: Connection reset by peer]
ahoneybun[m] has quit [Read error: Connection reset by peer]
jenneron[m] has quit [Write error: connection closed]
lollaritits[m] has quit [Write error: connection closed]
tinko92[m] has quit [Remote host closed the connection]
wiley[m] has quit [Remote host closed the connection]
coni21[m] has quit [Remote host closed the connection]
EdgarOE6DUG[m] has quit [Read error: Connection reset by peer]
sandman187 has quit [Remote host closed the connection]
anonymix007[m] has quit [Read error: Connection reset by peer]
Sayatomoki[m] has quit [Remote host closed the connection]
Jasper[m] has quit [Remote host closed the connection]
travmurav[m] has joined #aarch64-laptops
<travmurav[m]>
perhaps in a few generations they will understand the platform better and there will be some more interesting stuff
davidinux has quit [Quit: WeeChat 4.3.1]
macc24 has joined #aarch64-laptops
<macc24>
slim7x and magicbook art 14 have modified ec firmware, surface laptops have microsoft's ec iirc
<travmurav[m]>
yeah but swapping the ec is "bells and whissels" stuff I'd say as long as it doesn't really tap into the base platform (i.e. by controlling power)
<travmurav[m]>
but I guess without looking at the schematics it will be hard to say how much was customized
<travmurav[m]>
sadly my random quick searches don't yield anything on schematics for those funny things so far
<JensGlathe[m]>
I have suspended it at 09:00 today, let’s see ( it had 100%)
<SpieringsAE>
nice, I plan on opening up my asus this weekend maybe, I want to check out how the hdmi is hooked up. I wouldn't be surprised if there is a DP -> HDMI bridge in there
<SpieringsAE>
just like the dev kit would have gotten
<SpieringsAE>
macc24: does something need to be set up in the dtb for it to find the EC?
<SpieringsAE>
I see it looks through sysfs somewhere
<macc24>
SpieringsAE: yes
<macc24>
you need the i2c interface enabled at 400khz
<SpieringsAE>
I think that might already be done
<macc24>
the exact one ec sits on has to be enabled
<SpieringsAE>
yeah its enabled
<SpieringsAE>
at least someone speculated that that one has the EC
<macc24>
yeah i did that
<macc24>
probably
<SpieringsAE>
ah wait, and the keyboard is on that one
<SpieringsAE>
I guess that makes some sense given how much interaction they seem to have
<SpieringsAE>
theres actually two devices left on that bus it seems. Or is the EC split?
<macc24>
who knows
<macc24>
i see both 0x5b and 0x76 sometimes used for the ec
<SpieringsAE>
yeah those are listed in the dtb
<SpieringsAE>
guess ill do an i2cdetect
<SpieringsAE>
see what pops up
<macc24>
i wouldn't recommend poking around i2c bus like that
<SpieringsAE>
ah okay, its been fine on sbcs, but I guess that might be different here then
<JensGlathe[m]>
The nxp3222 usb3 repeaters are there too, i guess i2c5
<SpieringsAE>
the asus has the ps8830's
<SpieringsAE>
spread on 3 i2c busses
<JensGlathe[m]>
And 2 nxp3222 for the type-a ports
<SpieringsAE>
ah, those are extra there aswell? interesting
<SpieringsAE>
so its usb-mp -> ps8830 -> 2 nxp3222
<SpieringsAE>
?
konradybcio has joined #aarch64-laptops
<konradybcio>
has anyone bisected the "failed to get DP sink modes" / low-res dp on x13s yet?
<konradybcio>
broke somewhere around 6.12rc, I think
hipboi has quit [Quit: hipboi]
<konradybcio>
SpieringsAE: the NXP chip only concerns USB2 lanes
<konradybcio>
and PS8830 is only connected to non-MP ports
<SpieringsAE>
Pretty sure the two type A's are usb3
<SpieringsAE>
hmm then why would I have 3, it only has 2 type c ports
<konradybcio>
check the _STA field, it may be disabled
<SpieringsAE>
maybe the third then splits it for the usb-A ports?
<konradybcio>
or it may not be disabled and just left on by the vendor
<SpieringsAE>
is that in the dsdt?
<konradybcio>
yes
<JensGlathe[m]>
The hp x14 has 2 ps8830, and 2 nxp3322
<JensGlathe[m]>
Sorry 1 nxp
<SpieringsAE>
konradybcio: can't really find anything, then again I don't really know how to read dsdt's
<SpieringsAE>
there seems to be UCS0 and UCSI that have something to do with it
<SpieringsAE>
and RTM0,RTM1,RTM2
<SpieringsAE>
and maybe UCN0,UCN1,UCN2
e^pi-1 has joined #aarch64-laptops
e^pi-1 has left #aarch64-laptops [WeeChat 4.4.3]
<SpieringsAE>
everytime I think I am starting to understand this dsdt stuff, I see something that just messes it up again
<macc24>
i wonder what happened to arm64 chromebooks
<SpieringsAE>
my gf has one, a lenovo with some mediatek chip, slightly more powerfull than my pinebook pro
<SpieringsAE>
I think that one was pretty new
<macc24>
i don't think i heard of any faster arm chromebook chip than mt8195
<SpieringsAE>
I think she has the mt8183, fennel14, I ran alarm from a usb on it for a bit
<SpieringsAE>
which was quite terrible lol, might just have been the usb that was bad though
<macc24>
fun laptop, i have a krane and kinda regret not getting a traditional laptop or something with more ports
<SpieringsAE>
that mt8195 looks similar to an rk3588
<SpieringsAE>
core layout wise
<SpieringsAE>
its actually a bit better, nice
<macc24>
imho it's a lot better because it's in a laptop
<SpieringsAE>
I'm still praying for a pinebook pro upgrade board with the rk3588
<SpieringsAE>
instead of that poopy rk3399
<SpieringsAE>
I mean its workable
<SpieringsAE>
is there any way to relate the //pin list things in dsdt to actual dt gpio's? I fear not
<travmurav[m]>
depends on what gpio it is
<SpieringsAE>
main chip or like pmic?
<travmurav[m]>
straight gpio? 1-1 numbering, interrupt gpio? need to do 5 translations
<SpieringsAE>
oof
<SpieringsAE>
yeah these are interrupts lol
<SpieringsAE>
I think it might be the lid switch
<SpieringsAE>
and some other stuff
<travmurav[m]>
but i think x1e had straight number near virtual gpio somewhere, idr
<SpieringsAE>
well they seem to be the same as the ones on the t14s
alfredo has joined #aarch64-laptops
<bamse>
deathmist: the acpi spec defines how power management should be done using acpi, but i guess it doesn't necessarily prohibit you from doing things on the side (it's just a bad idea if you want compatibility)
<SpieringsAE>
huh it seems like there is an extra i2c bus in the dsdt that is not currently active in the dtb, i2c8
<bamse>
deathmist: comparing that to device-tree...i don't know if that would be better, it only defines data; all the actual power management logic needs to be implemented in each OS
<bamse>
SpieringsAE: that's not unusual...but note the off-by-one in numbering between dsdt and devicetree
<SpieringsAE>
yeah I figured that one out :)
<SpieringsAE>
I am a matlab writer so I am well versed in switching between 0 and 1 based indexing hahaha
<SpieringsAE>
the asus seems to have an i2c based RTC if I'm reading this right
<SpieringsAE>
Wasn't the rtc integrated? I remember something about the alarm bit not being accesible in some patch
* travmurav[m]
wants to bet money it's the pep mailbox virtual rtc
<SpieringsAE>
I don't know what that means, but I guess kind of like a fake i2c?
<travmurav[m]>
there is a fake i2c that goes into pep driver (I think)
<travmurav[m]>
so acpi can pretend there is an "acpi compatible" rtc but it ends up writing into emulated i2c
jhovold has joined #aarch64-laptops
<SpieringsAE>
thats pretty whack
<SpieringsAE>
wack*
<travmurav[m]>
"\\_SB.ABD",
<travmurav[m]>
is this the i2c bus?
<SpieringsAE>
it is definetly mentioned there
<SpieringsAE>
Field (\_SB.ABD.ROP1, BufferAcc, NoLock, Preserve)
<travmurav[m]>
yeah this is virtual/pmic stuff
<SpieringsAE>
dang
<travmurav[m]>
SpieringsAE: just look up "Device (ABD)" :^)
<travmurav[m]>
and you will se a funny DEP field
<SpieringsAE>
you mean the \_SB.PEP0?
<travmurav[m]>
yes
<travmurav[m]>
that """i2c""" goes into pep, as I said and I didn't even need to open the correct dsdt as it's same on all woa
<SpieringsAE>
rip
<travmurav[m]>
I wonder how much disappointment that """rtc""" definition has caused to people here, everyone gets confused by it
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<bamse>
SpieringsAE: \\_SB.ABD provides a communication bridge between dsdt and firwmare; where the rtc alarm function is implemented
<bamse>
so it's not an i2c bus, but iirc it's expressed in the same fashion in dsdt
<travmurav[m]>
I guess it's just because acpi has special opcodes for i2c but nothing else
chrisl has quit [Ping timeout: 480 seconds]
<bamse>
yeah, there are a few different GenericSerialBus providers, but i guess this was a convenient abstraction to use
SpieringsAE has quit [Quit: Leaving]
Jasper[m] has joined #aarch64-laptops
jenneron[m] has joined #aarch64-laptops
psydroid[m] has joined #aarch64-laptops
z3ntu has joined #aarch64-laptops
KieranBingham[m] has joined #aarch64-laptops
DenysVitali[m] has joined #aarch64-laptops
<kettenis>
nicely illustrates what a complete joke acpi is on these systems
<jhovold>
Here's an updated wip branch for the X13s:
<jhovold>
- fix usb-c orientation detection for port 3
<jhovold>
- add displayport lttpr support
<jhovold>
- (drop 20 fixes now in mainline)
<jhovold>
Known issues:
<jhovold>
- external display still does not work here on the crd and t14s even if lttpr support should improve things for those who do get that far (depends on monitor?)
<tobhe>
jhovold: to get external display to work on the t14s I needed to reduce the data-lanes to 2
<tobhe>
downside is that that broke the OLED variant
chrisl has joined #aarch64-laptops
<jhovold>
tobhe: thanks, abel suggested that as well but it made no difference here last time I tried, I'll give it another try with the latest branch as well to be sure
<jhovold>
shouldn't need to break the oled variant since that controller should still use four lanes
chrisl has quit [Ping timeout: 480 seconds]
<jhovold>
tobhe: reducing the data lanes indeed made dp altmode work here on the crd with the lttpr support in place
<jhovold>
abelvesa: ^
<jhovold>
i'm getting a bunch of errors on connect and disconnect, and on the second disconnect the machine reset
<jhovold>
the reset is apparently a known issue, so maybe its best to keep dp altmode disabled for a while still...
<bamse>
jhovold: data-lanes on the type-c/QMP phys?
<jhovold>
on the displayport controller (e.g. mdss_dp0_out)
alfredo has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<jhovold>
hmm, I'm only seeing the errors and reset on the crd, things do seem to work on the t14s (with reduced data lanes)
<jhovold>
but man, the t14s uefi fw seems to be really broken
<jhovold>
some kernels fail to start with systemd-boot, a *copy* of the same kernel starts successfully
<jhovold>
the failing kernels also start successfully if I launch an uefi shell and exit before trying to start it
<maz>
in the end, I'm quite happy with my scripts that directly boot from EFI. it really looks like the less you interact with the firmware, the better things are.
<jhovold>
and I could only get it to work at all with nvme boot if I pass the dtb directly to the efi stub
<maz>
ah, that too.
<jhovold>
yeah, it was you comment on the devkit fw that made me try the above
<maz>
note that I have to use the EDK2 shell, and not the built-in one. otherwise, nothing works.
<jhovold>
sd-boot worked fine when booting from usb, but then the same build failed when I installed it on the nvme
<konradybcio>
fwiw sl7 "enjoys" the dp resets and has no issues with grub
<konradybcio>
but then microsoft's uefi looks very.. paid attention to
<maz>
konradybcio: now you are bragging! ;-)
<konradybcio>
maz oh this machine has its very.. prominent quirks too, though ;)
<konradybcio>
such as a hi tech touchpad which is not hid over i2c..
<maz>
laptops: just don't.
<craftyguy>
jhovold: does "update wcn6855 pwrseq to v6" fix anything? :D
<craftyguy>
exeat: ahhh thanks, I'll try this. yeah not the first time I've struggled with sysrq on this thing :/
<jhovold>
craftyguy: no, it's just churn :) but those patches are merged now which means I can move them under the --- linux-next --- marker in the branch (which feels good ;))
<craftyguy>
woo nice! :)
<tobhe>
> some kernels fail to start with systemd-boot, a *copy* of the same kernel starts successfully
<jhovold>
craftyguy: haven't noticed any (new) issues with suspend on the x13s so not sure what the issue you reported is about
<tobhe>
mine just randomly fails
<tobhe>
often a few times in a row
<konradybcio>
maz I'm actually torn.. devboards are obviously nicer for early bringup or hunting down annoying bugs, but beyond that, I prefer dogfooding end-user-grade machines
<jhovold>
I've seen that once too, one sd-boot entry failed consistently until it started once...
<konradybcio>
some issues you only notice in daily use
<tobhe>
plugging in usb sticks randomly resolves the issue sometimes
<jhovold>
heisenboot...
<tobhe>
yeah, so it might be that your copy did not actually make a difference
<jhovold>
oh, it does, that one copy still boots successfully every time
<tobhe>
something also keeps on adding new uefi boot entries with binary windows boot params for grubaa64.efi
<tobhe>
and those fail
srinik has quit [Ping timeout: 480 seconds]
<tobhe>
and you can't tell it apart from the working one in the uefi boot selection because both show up as Ubuntu
<jhovold>
never got grub to work at all (from usb)
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
hearing all of this makes me very surprised that my asus is doing fine so far
<SpieringsAE>
I mean, my first one didn't have a boot menu in the firmware, but that seems to be resolved with this one
<SpieringsAE>
besides that, no issues whatsoever with booting, used grub from usb, and sd-boot from nvme
chrisl has joined #aarch64-laptops
alfredo has quit [Read error: Connection reset by peer]
<robclark>
I haven't had any particular problems with grub on my 7x.. I might have been using s-d boot when I was bootstrapping things (and booting from usb-c), but pretty sure I used grub from usb-c at least once
<JensGlathe[m]>
deathmist: at home now, X14 opened with 77% battery after ~10hrs, laptop was in a suspend state.https://pastebin.com/9N2EYdwS
<JensGlathe[m]>
On Ubuntu Concept 24.10 x1e with 6.11.0-49, no smmu inconsistent warnings.
iivanov has quit [Quit: Leaving...]
<jhovold>
and for the record, like anonymix007 mentioned (I think), it's ExitBootServices() that fails (with sd-boot)
<jhovold>
end up back in the boot menu, currently with working keyboard, but I think I ended up there with non-functional keyboard a few times as well (e.g. like what I saw with grub)
<macc24>
i've been using sd-boot 256.6-1 from debian and it's all fine in my slim7x, aside key delay
<JensGlathe[m]>
any progres on the brightness keys front?
<macc24>
which device?
<JensGlathe[m]>
ITE8897
<macc24>
i meant which laptop?
<JensGlathe[m]>
HP X14s
<JensGlathe[m]>
HP Omnibook X14 *
<macc24>
check out my rust program i've posted above, run it and dump what it says about brightness keys
<macc24>
as in press them and copy output
<JensGlathe[m]>
oh will do
<macc24>
in 30 minutes-ish i can check dsdt and add it to it8987-qcom-tool
<JensGlathe[m]>
macc24: Do I need your driver to be loaded for this?
<macc24>
all you need is i2c5 enabled in dts
<macc24>
the tool would even tell you that if it's missing :D
<SpieringsAE>
hmm, it doesn't seem to output anything on my asus
<SpieringsAE>
it did find something on i2c-3
<SpieringsAE>
nada
<SpieringsAE>
you do mean like fn + f# right?
<JensGlathe[m]>
On mine it says it listens on /dev/i2c-6, but I know this, dev enumeration is not coherent with i2c bus numbering from dt
<SpieringsAE>
wait you are right, why doesnt that match? I haven't seen any aliases
<SpieringsAE>
yeah, /dev/i2c-3 is actually i2c5 in the dtb, wack
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
<deathmist>
JensGlathe[m]: 23% for 10 hours in suspend doesn't really scream working power management to me other than maybe turning off the display which is definitely the largest power sipper by far :D I meant battery life during some browsing/video playback for example but I'm assuming neither of those would net great results atm
<deathmist>
or even idle battery life to have some baseline for power consumption with nothing going on except wifi on and brightness at 50% for example (which really isn't all that bright on the HP OmniBook X 14 thanks to it's 300nits max display)
jhovold has quit [Ping timeout: 480 seconds]
<SpieringsAE>
hey nice, it seems the lid switch on the asus is the same as the t14s, so imma yoink that
<SpieringsAE>
tlmm 92 goes low when the lid is closed
<SpieringsAE>
also tlmm seems to be gpiochip9
<robclark>
deathmist: AFAIU there was some issue with not being able to disable one of the pcies, preventing hitting lowest power state, but konradybcio was working on something for that. That said, I was able to get a full days use out of my 7x (mostly vscode + recompiling/debugging stuff), the problem is more that power consumption floor is too high, not that the ceiling is too high. (That said, super-long video playback
<robclark>
probably also involves doing video decode with hw accel, which would need some ffox/chrome work)
<deathmist>
I figured video hwdecode would be a pain yeah, perhaps something like mpv would be easier to make eventually work with that so you could at least playback videos there paired with yt-dlp
<macc24>
<JensGlathe[m]> "On mine it says it listens on /..." <- it looks at i2c iface with a specific BAR to not be fooled by /dev/ numbering
anonymix007[m] has joined #aarch64-laptops
<anonymix007[m]>
What's the best way to contact Lenovo about firmware issues? I've tried "email support" and haven't received any response from them after multiple weeks
<macc24>
robclark: i **think** i saw ffmpeg support for v4l2 m2m
<macc24>
anonymix007: what firmware issues?
<robclark>
yeah, I think ffmpeg and gst.. and in theory it could work on chromium (because we use this on Chromebooks) but probably someone still has to spend some time untangling build options, and deal with gbm vs minigbm.
<SpieringsAE>
is there actually some benefit to labelling the display type in the dtb if it works fine with "edp-panel"? my asus seems to have an atna56ac03, which is not (yet?) listed for the panel-samsung-atna33xc20 driver
<SpieringsAE>
okay poking random gpio's with gpiod to find the bl_en pin is not a good idea lol
<SpieringsAE>
that one sadly doesn't seem to be the same as the t14s/7x unless I'm messing something up