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
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<steev>
funny enough
<steev>
debconf has a slide that says audio is still hard on linux lol
chrisl has joined #aarch64-laptops
<tobhe[m]>
well hard and kind of dangerous
<steev>
yeah
<steev>
tobhe[m]: JensGlathe[m]: so uhhhh, apparently i'm not smart, and i *thought* i'd run git pull on the mybw repo but i didn't...
<icecream95>
All of those memory bandwidth numbers seem quite low... with tinymembench I see about 90 GB/s writing to RAM from a single core
<icecream95>
Also note that with x1e I see read bandwidth limited about 60 GB/s on Linux, but Windows gets significantly better numbers
<steev>
105K MB/s is 105GB/s
chrisl has joined #aarch64-laptops
<valpackett>
oh lol the impedance measurement in wcd938x.c has a "If ramp is not complete, give additional 5ms" that sleeps and.. doesn't reread the regs
chrisl has quit [Ping timeout: 480 seconds]
<valpackett>
well hm that's the same in some other wcd drivers and doesn't help if i add a reread..
tobhe has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
<valpackett>
OKAAAAYYYY figured one thing out at least!!
<valpackett>
distortion at high volume is due to qcom-lpass/rx-macro/HeadphoneEnableSeq.conf setting 'RX HPH Mode' to CLS_H_ULP
<valpackett>
thanks to 2015 era android audio modders on xda forum for talking about that setting lol
<steev>
i'm aware, i'm trying to figure out why mine is different
<valpackett>
......and the "quiet audio gets panned to the left" effect was due to the compander (RX_COMP[12] Switch), the "too boomy attacks" thing too
chrisl has quit [Ping timeout: 480 seconds]
hexdump0815 has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<dgilmore>
robclark: have you used chromium on fedora on your x13s lately?
<dgilmore>
I am getting a ton of tears and I can not actually navigate anything. all other apps seem okay
chrisl has quit [Ping timeout: 480 seconds]
<valpackett>
oh wow, chromium *is* busted (on x1e too here)
<valpackett>
the glitches with the bluish gradienty nonsense triangles remind me of intel haswell ones back in the day
chrisl has joined #aarch64-laptops
<JensGlathe[m]>
Seen those on element-nightly a few days ago, switched to element-desktop
<jhovold>
mani_s: regarding the reset on poweroff, are you passing efi=noruntime (as you should)?
ungeskriptet_ has joined #aarch64-laptops
ungeskriptet has quit [Ping timeout: 480 seconds]
ravikant_ has joined #aarch64-laptops
<jdb[m]>
efi=noruntime is still needed? I thought it has been fixed
<jhovold>
it's still needed as the restart service triggers a page fault, which appears to reset some machines even if the kernel sometimes recovers
<jhovold>
on x13s it crashes consistently
<jdb[m]>
Thanks for the confirmation. Here is another unrelated topic:
<jdb[m]>
jhovold: when using the ThinkPad X13s with an external screen, does the built-in display switch off when you close the lid?
ravikant_ has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<jhovold>
jdb[m]: I haven't checked until now, but that doesn't seem to be the case in my setup at least. I guess it depends on your DE?
<jdb[m]>
Thanks. I use Gnome + wayland, this is supported at least on Intel machines, I don't see what could be x86 specific
<jdb[m]>
We'll investigate to see where this could be coming from
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
SpieringsAE has quit [Quit: SpieringsAE]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<lynxy>
join #sony
<lynxy>
woop, missed the slash
<lynxy>
woop, wrong network entirely
<robclark>
jhovold: is the screen still on or just the backlight? Maybe there is some issue with the bl control?
<robclark>
err, src, that was for jdb[m]
<jdb[m]>
robclark: I still see the full image when I open just 1mm, so I think the screen is still on
<robclark>
could also be lid detect, ie. not realizing that it is closed?
<jdb[m]>
there is an event being fired when I reopen the screen, there is a very short flash on screen (at least on the external one) deterministically, so I would say the the lid detect works
<jdb[m]>
lid open is triggering an event, that's for sure ; lid closing, I can't tell as nothing happens
<jdb[m]>
could it be asysmmetrical ?
<robclark>
from the display side of things.. you could for ex set a short timeout for the screen to blank, and then see if the screen does indeed blank after the timeout. But that seems to work find on my yoga 7x, so I don't expect there are any problems with that
<jhovold>
jdb[m]: I realise my reply was ambiguous when rereading now; I ment to say that the display doesn't seem to turn off here either
<robclark>
display does seem to go off when I close the lid on the 7x.. and windows move to the external screen.. so some event is generated. (I do have macc24's 7x EC driver, I wouldn't be surprised if lid detect required an EC driver?)
<jdb[m]>
so it should be considered a known issue / current limitation for the moment (at least potentially depending on the DE)
<jhovold>
sounds like it's working for robclark, I use dwl/wlroots and I wouldn't expect it to handle things like this (yet)
<jdb[m]>
just to be clear, with no external screen it works as it should
<jhovold>
then it should suspend (depening on your systemd settings)
<jdb[m]>
I have this issue when I have a (4K) external screen plugged-in
<robclark>
fwiw, I'm using bog standard gnome-shell.. if that matters
<jdb[m]>
me too
<jdb[m]>
indeed, with no external screen, it does suspend, good point so that's a different scenario. At least it proves that the lid switch is working, both when closing and when opening
<jdb[m]>
I've confirmed by running a video in the background, it stops right away when I close the screen
<jdb[m]>
when I re-open the laptop, I can see the Wi-Fi network reconnecting
<jdb[m]>
so the code to switch off the screen during suspend could be different vs. the code to just switch the screen off while having an external display connected? Interesting...
<jdb[m]>
it smells more like a user-land issue
<jdb[m]>
even weirder, the surfaces don't refresh anymore on the external screen when I close the lid, I can only the mouse cursor moving
<jdb[m]>
(^ I test this with an external screen)
<jdb[m]>
multiscreen support is not fully backed somewhere in the stack
<jdb[m]>
s/screen/mouse : EDIT/
<robclark>
if you have the screen setup to extend desktop, instead of mirror, you should see windows moving from built in display to external when you close the lid.. maybe there is some gnome settings option that controls this?
<mani_s>
jhovold, I was not using this parameter, but looks like using it also doesn't fix it
<macc24>
robclark: lid sensor doesn't require my ec driver
<macc24>
it's just a gpio
<robclark>
ahh, ok
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<valpackett>
to test the lid event itself, use ' libinput debug-events '
<jdb[m]>
robclark: oh I know the expected behavior, I've been using Gnome for many many years, I just don't get the right experience on the X13s
<jdb[m]>
I wonder if the 2 lanes - 4 lanes support could make a difference (I haven't included the existing patches yet) as this is with a 4K display
<jdb[m]>
^ There seems to be some missing support within the MSM driver, like this one
<jdb[m]>
or I'm hitting some specific bugs that are triggered by my external monitor potentially
<jdb[m]>
Val Packett: I guess the lid events work as the laptop suspends / resumes when closing/!reopening the screen, but I could double check
Lucanis has quit [Ping timeout: 480 seconds]
<robclark>
the # of lanes will matter for refresh rate, but not for what the DE does when you close the lid
chrisl has joined #aarch64-laptops
<valpackett>
speaking of newer eDP standards like the above link..
<valpackett>
i've been wondering if the PSR black screen i'm seeing is due to MSM DP just not supporting newer stuff too
<valpackett>
msm supports only the enable bit from DP_PSR_EN_CFG while intel supports a bunch of stuff there
<valpackett>
DP_PSR_FRAME_CAPTURE particularly makes me think
<steev>
jdb[m]: i include the 4 lanes patchset in my kernel for X13s that I am running when I was testing and saw the issue as well
<jdb[m]>
I'm starting to think like Val Packett that the MSM driver is not yet as robust / exhaustive as some other display drivers
<jdb[m]>
<Jasper[m]> "Yeah it won't like 4k60 I think" <- indeed, that's why I'm trying to force it to 30Hz
<jdb[m]>
is the 4-lane support close to be accepted upstream? I haven't followed the latest patchset
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<robclark>
IIRC the 4 lane support is just usb/dt stuff, not actually any changes in drm
<jdb[m]>
intereresting. I'm not implying it will make a difference, but I will check it to reduce the options
<valpackett>
yes, it's qmpphy
chrisl has joined #aarch64-laptops
<robclark>
jdb[m]: for your issue, I don't really expect it is anything in the driver tbh.. but you could check /sys/kernel/debug/dri/0/state before and after closing the lid to see if userspace thinks it disabled the display
<jdb[m]>
the eDP-1 connector is using crtc-0, which is linked to crtc[87]. In both cases, crtc[87] appears as enabled and active, with the lid open or closed
<jdb[m]>
plane[39] (plane-0) is linked to crtc-0 in both status
<jdb[m]>
in the closed case, I can see a new plane, plane[75], which also refers to crtc-0 and which says "allocated by = KMS thread"
<jdb[m]>
I have no idea why this plane with a size of 512x512 is appearing
<jdb[m]>
doing the test multiple times, I have even captured a scenario where 2 such planes have appeared
<robclark>
`size=512x512`.. that is probably the cursor
<robclark>
if cursor is spanning the two displays, I guess you'd probably get two?
<jdb[m]>
but why does this appear when the lid is closed? that's surprising
<jdb[m]>
at least, it seems to point out that usersapce didn't succeed in disabling the display
<jdb[m]>
Switching to Gnome / Xorg fixes all the Gnome / Wayland display issues I've shared earlier
<jdb[m]>
This looks like pure userland issues then, sorry for the noise
chrisl has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
<jdb[m]>
<jhovold> "on x13s it crashes consistently..." <- You wrote "With recent UEFI firmware efi=noruntime can be left out when the Linux Boot option is enabled."