robclark 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
<steev>
dgilmore: that is exactly what happened... i was trying to find where y'all hide the dtb files
<dgilmore>
steev: I probably should file a bug about it writing on removable media. But it's probably a UEFI bug Lenovo won't fix
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
KREYREN_oftc has quit [Remote host closed the connection]
<travmurav[m]>
Jasper: as a first step, we can easily apply overlays and hook stuff in in dtbhack, long term this would need more thinking
<travmurav[m]>
i.e. I think right now the sc8280xp pcie changes can be applied with a simple dt overlay, zap shader is more complicated as overlays don't allow killing nodes, but can keep that in code until we find some nice way to fallback in the driver instead
<travmurav[m]>
but I guess kernel still needs quite some fixes for that funny bus iommu driver thing that was apparently needed to be exclusive until now
<travmurav[m]>
I guess the other interesting thing right now is remoteprocs...
<travmurav[m]>
for cros we have i.e. video-firmware {iommus=}; so linux can set up the firmware for the remoteproc without hyp/tz help, so I suppose that one can be used as-is; don't think the same is implemented for adsp/cdsp (whatever sc8280xp uses?) but probably can be done in the same way
<travmurav[m]>
robclark: any chance you know how iommu stream ids for firmware were found on cros? Unless it was just "we kicked it on and looked which stream id created a fault on iommu"
<jglathe_x13s>
robclark, Jasper[m]: something needs to check which EL we're on and select accordingly. This needs to be somewhere in the kernel (in of?), preferrably where all drivers can use it that need to make this distinction. Either way, sounds complex.
<jglathe_x13s>
travmurav[m] kicking it sounds like some good debug strategy, why not
<steev>
travmurav[m]: you can't /delete-node/ in an overlay? i thought you could
<travmurav[m]>
yes, /delete-node/ and /delete-property/ are dtc (compiler) directives
<travmurav[m]>
the closest to delete-node is overlaying status=disabled but this requires the kernel to respect that prop for the node (which is not always the case)
<travmurav[m]>
and I think for deleting props there is nothing at all
<steev>
ahhh
jhovold has joined #aarch64-laptops
<albsen[m]>
how can I get my x13s to go into suspend-to-ram? I've seen on https://github.com/jhovold/linux/wiki/X13s#suspend that the "deepest sleep states" aren't supported yet, not sure if that means suspend to ram or hibernation. at the moment I have only s2idle. maybe I'm missing a config somewhere?
<jhovold>
albsen[m]: s2idle is the only thing supported in this plaform
<jhovold>
hibernation support is not implemented yet
<jhovold>
but we hope to get the power consumption in s2idle down further still
iivanov has joined #aarch64-laptops
<albsen[m]>
<jhovold> "albsen: s2idle is the only thing..." <- thx, is that a hardware issue or could someone (maybe me) implement it? where would I start looking?
hexdump01 has quit []
hexdump0815 has joined #aarch64-laptops
<jhovold>
it's a platform (hardware/firmware) limitation, windows also only uses s2idle these days
<albsen[m]>
ah, I see, didn't check on windows sleep before removing the drive :D
matthias_bgg has joined #aarch64-laptops
<travmurav[m]>
(and using s2idle is completely normal and if implemented properly would be more or less equivalent to suspending to ram power consumption wise)
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
<konradybcio>
steev: LMH (limits management hardware) limits the power and other variables of the CPUs, the irq only tells the OS that LMH has started doing something, so that the OS can figure out what to tell the scheduler
matthias_bgg has joined #aarch64-laptops
<Segfault[m]>
i see the lmh has both temperature and current sensors available to it, those current sensors wouldn't happen to be accessible to linux would they?
KREYREN_oftc has joined #aarch64-laptops
<konradybcio>
you can forget about it :P
<Segfault[m]>
damn, i would've liked to measure the power draw of each part of the soc lol
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
<jglathe_x13s>
Volterra actually has 3x MAX34417 on the board for that purpose I huess
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
<adamcstephens>
I picked up an OWC TB4 dock off ebay, and it works well with the x13s. :)
<Segfault[m]>
i've been using a lenovo 21AS one with mine, works great although i wish dp-mst worked in linux :P
<adamcstephens>
ahh, i am a single monitor user :)
<adamcstephens>
i had to look up what that was
<Segfault[m]>
the x13s has no trouble driving three external monitors in windows at the same time as its internal lcd, i was pretty impressed with that tbh, with my setup i connect two to the dock and one to the other usb-c port, all three on one port would need way too much bandwidth
<gwolf>
Segfault[m]: Using a single USB-C port, or using both?
rz has quit [Remote host closed the connection]
rz has joined #aarch64-laptops
<Segfault[m]>
both ports for all three monitors, i've got one 1440p 165hz, one 1080p 144hz and one 1080p 75hz
<gwolf>
OK, so it's not _that_ much --- that would be slightly over the bandwitdh needed for a single 4K+ monitor
<Segfault[m]>
what 4k 60hz per cable?
<gwolf>
oh, 165Hz and 144Hz, didn't see that!
<gwolf>
I seldom pay much attention to those numbers, as I don't care much about them, but they _are_ remarkable
<Segfault[m]>
heh yeah that makes things a bit more difficult
<gwolf>
FWIW I ran a 4K+ at 30Hz for a long time, and didn't realize I could run it at 60 (not from my C630, but from my desktop)
<gwolf>
...but TBH, I don't really feel the difference :-)
<Segfault[m]>
i haven't confirmed but i think the x13s should be able to do all of that over a single cable, but if it can it'd mean no usb 3
<Segfault[m]>
and i'm not sure my dock can accept that much bandwidth lol
<gwolf>
I can assure you my brain doesn't.
<Segfault[m]>
oh it actually can, but yeah the usb 3 connection is more important than running everything over a single cable
<Segfault[m]>
gwolf: tbh at first i always think something's wrong with the x13s when i use its built in display because i'm so used to the higher refresh rates lol
<gwolf>
I like high resolutions... but don't care too much about refresh rates
<gwolf>
FWIW, I know I'm kind-of-silly, but am currently using Wayland with scale=0.75, because my current monitor (I'm on a 6 month leave) is only 1080p
<gwolf>
So I know I'm only fooling myself by behaving as if I still had a decent monitor... but it works
<Segfault[m]>
heh yeah with modern software even 1080p can get a bit claustrophobic
<Segfault[m]>
actually this reminds me i never tested my 1440p monitor with the x13s in linux
<adamcstephens>
i use a 4k monitor at about 1.25x scale
<adamcstephens>
27"
<Segfault[m]>
it's not working through my direct usb-c to dp cable i normally use for this monitor, cable might've died or something, i'll check on another device in a bit
<Segfault[m]>
oh it's not working through the dock either, probably just needs a reboot then
<gwolf>
right, cable quality is quite a thing. I was severely underwhelmed at the desktop computer I bought (used) before my trip, around last August, because it didn't reach over 1080p with my 4K+ monitor...
<gwolf>
...only to find it was the DP-to-HDMI cable I was using.
<Segfault[m]>
ugh yeah i still need to find a 2m usb-c cable that works properly with my dock
<Segfault[m]>
i should really just get one of the active thunderbolt ones but they're expensive :P
<gwolf>
...or buy more, cheaper monitors, and put them farther away, so they cover the whole wall :-]
* travmurav[m]
at some point tried to look for type-c - type-c "usb4" kind of a cable and couldn't really find any that would not be either just usb2.0 data or super expensive TB with redrivers
<Segfault[m]>
right now i'm using a 1m usb3 cable which works but it's really too short
<travmurav[m]>
I also noticed it seems to hard to find simpler docs that would use c-c cables instead of having a hard wired 10cm cable in them (so i.e. something similar to a simple box with ethernet, hdmi and some usb but that I could wire my laptop into with a long cable)
<travmurav[m]>
(that is, if my primary usecase is displayport alt mode)
<konradybcio>
travmurav: there are super cheap (âŦ8 here) tb3 docks from hp etc
<konradybcio>
they may require a hp power adapter though
<konradybcio>
(or equivalent)
<Segfault[m]>
the main thing i look for is a dock that doesn't take a usb-c power input, the 40AS for instance uses a lenovo slim tip adapter
<Segfault[m]>
aside from limiting the maximum power output a lot of the docks that pass through usb-pd are really buggy
<gwolf>
travmurav[m]: Right, very short cables are also what I'm used to finding...
<travmurav[m]>
konradybcio: interesting, though I guess I'd be immediately concerned if all the MST stuff such dock would do won't work with my poor 7c1 xD
<Segfault[m]>
hmm, in linux the x13s can only drive my 1440p monitor at 60hz
<Segfault[m]>
oddly it has a 99.95hz option (which afaik isn't in the EDID?) but setting that makes it go blank and it doesn't recover until it's disconnected and reconnected
<Jasper[m]>
The only fully featured cable I have is a Lumia 950(XL) Convergence dock c-c cable
<Segfault[m]>
usb-c alt mode also seems to not have working hotplug at the moment? or if it does it's extremely inconsistent
svarbanov has joined #aarch64-laptops
svarbanov_ has quit [Read error: Connection reset by peer]
<jhovold>
Segfault[m]: yeah, there are a ton of regressions in 6.8-rc1 in the MSM DRM driver it seems
<Segfault[m]>
:/
<jhovold>
I fixed a few over the weekend, and have tracked down the intermittent hard resets that people have been hitting to another drm driver regression
<jhovold>
and on top of that we have DP hotplug, I thought it was completely broken for VT consoles, but it turns out the external display shows up if I wait 90+ (sic) seconds
<konradybcio>
that's a lot of seconds
<jhovold>
I don't do hotplug in X, but there's some indications in my limited testing that that is affected too
<jhovold>
For more details, here's a link the a series fixing issues with the internal display not coming up occassionally:
<Segfault[m]>
actually, does anyone else here use gnome? i'm kinda surprised nobody spotted and traced the software fallback that i ran into before i did
<jhovold>
For the hotplug issue, I've so far only mentioned it to some of the drm folks and opened an issue here:
<jhovold>
if it affects also wayland and xorg, then it may be worth commenting there
<jhovold>
Segfault[m]: I think at least steev uses gnome, and I think robclark too?
KREYREN_oftc has quit [Remote host closed the connection]
<_[m]123>
what's that fallback? it crashes or?
<Segfault[m]>
no it was just really slow
<_[m]123>
glad someone else has some high demand for dp output
<_[m]123>
I switched to kde because of it
<Segfault[m]>
the fallback wasn't related to dp alt mode, that was purely an opengl thing in gnome
<_[m]123>
it's stable
<_[m]123>
but I still have to replug minimally 2 3 times up to 10 before the usb reset triggers the screen or something
<_[m]123>
after sleep
<_[m]123>
also torrenting doesn't prevent sleep and sleep does disconnect all usb also external nvme
<_[m]123>
but I can do 60hz on 2.4k or something
<_[m]123>
it's a high end Samsung tv
<adamcstephens>
i was able to drive my 4k monitor @ 60hz through this OWC dock into displayport. i did hit one or two of those hard resets though in testing :/
<jhovold>
_[m]123: have you tried waiting a really long (90+ seconds) after connecting the external display to see if it eventually shows up in KDE as well?
<jhovold>
long time*
<jhovold>
assuming this is with 6.8-rc
<Segfault[m]>
ironically despite the massive amount of trouble i had with wifi i don't think i've had any of the drm issues aside from occasional hard reboots that i think happened when trying to init the display lol
<_[m]123>
I've done that in the start indeed sometimes it starts working but lol if you wait each time 5 minutes it sucks
<_[m]123>
it's with 6.8 and 6.7
<_[m]123>
6.8 is worse seems
<_[m]123>
(btw I'm trying to get the touchpad replaced through support, so far they're very responsive and I'm happy for it)
<jhovold>
_[m]123: yeah, waiting 90 seconds is not acceptable either, it's a regression that should be fixed
rz has quit [Remote host closed the connection]
rz has joined #aarch64-laptops
todi has joined #aarch64-laptops
<_[m]123>
90 seconds is the real max time?
<jhovold>
no, just an estimate of how long it took for the display came up in my test
<spawacz>
Are there any Acer Aspire 1 114-61 users? I've found one for 80 euros and I'm thinking of buying it just for very basic things. I read it is almost fully supported by mainline kernel, but the emmc is soldered and nonreplaceable, so in case it dies, the whole laptop is unusable?
<jhovold>
haven't tried to debug that myself
<jhovold>
so no idea where that delay came from yet
<jhovold>
just an indication that something is broken
<travmurav[m]>
spawacz: if emmc dies or the bootloader is gone from it, the device is a brick, yes
<travmurav[m]>
but it shouldn't be too big of a concern as long as you're careful
<_[m]123>
have been experiencing audio issues again too now - sometimes just no output though all seems fine đ§
<steev>
using gnome with what? the only times i've noticed slowdowns, it was an issue that has since been patched; i only have an asus 2K monitor and an apple dongle for external display here. that said, what version of mutter are you using?
<_[m]123>
over BT
<_[m]123>
ah yesterday no way to get it back, today I just disconnect and reconnect and fixed đ
<spawacz>
travmurav[m]: the bootloader is on the emmc where the rest of the OS is?? So if I do a wrong 'dd' it's over?
<spawacz>
that's crazy
<travmurav[m]>
spawacz: exactly
<travmurav[m]>
welcome to the way smartphones do it :)
ungeskriptet is now known as Guest241
ungeskriptet has joined #aarch64-laptops
<jhovold>
_[m]123: bluetooth sometimes fails to initialise, known issue, check the wiki
<jhovold>
a reboot should work around it for now
<travmurav[m]>
spawacz: well, if the device didn't have hw secure-boot or if there was a signed programmer available, the device would've trivially recoverable from anything, but I don't think acer/quanta would share the programmer blob
<Segfault[m]>
<steev> "using gnome with what? the..." <- on a qcom device do you get a big lag spike whenever you open the clock/calendar/notification panel thing from the status bar?
Guest241 has quit [Ping timeout: 480 seconds]
<steev>
no?
<travmurav[m]>
Segfault: fyi never seen that lag on 7c too
<Segfault[m]>
weird, i'd been getting them on multiple qcom devices for a while
<steev>
wayland? xorg?
<Segfault[m]>
and was able to reliably reproduce it and i think it was rob clark who came up with a patch to fix it
<Segfault[m]>
wayland
<steev>
hm, the mesa patch?
<Segfault[m]>
yeah
<Segfault[m]>
if it's happening to you it should be pretty obvious if you just click quickly on the clock in the status bar though, it basically freezes the whole system without the patch
<steev>
i don't have that here, as i'm just using 23.3.5-1 (what's in debian testing)
<steev>
nope, can't reproduce the entire system freezes
<steev>
at least, xorg
<Segfault[m]>
maybe it only happens in wayland
<steev>
let me put in my weekly report from last week for work and then flip to wayland
* travmurav[m]
couldn't reproduce lag after spamming the clock on wayland on 7c
<Segfault[m]>
because i've hit that on sc8180x and sc8280xp multiple times for something like a year now at least
<Segfault[m]>
ofc i don't anymore with the patched mesa
<steev>
which version of gnome/mutter?
<steev>
and gnome-shell
<steev>
wayland doesn't reproduce here either
<Segfault[m]>
46, although iirc i've tested at least as old as 44 and it happened there too
<steev>
but you also need external display connected?
<Segfault[m]>
nope, happens regardless of external display or not
<steev>
not happening here in kali :/
<steev>
i don't have any sort of thing hooked up to the calendar though, further than the required e-d-s though, i think
<Segfault[m]>
even on a fresh install of both debian and fedora i was hitting that issue
<Jasper[m]>
I may still have gnome installed
<Jasper[m]>
Will check when I get home
<_[m]123>
> Probe failure due to command timeouts (infrequent)
<_[m]123>
that one? ok didn't know but indeed reboot fixed
<steev>
i see that every now and again with bluetooth, i don't think it's the chip, i think it's the serial
<jhovold>
_[m]123: right
<_[m]123>
it's super rare though I've been using non stop almost for weeks, first time yesterday when I switched to no Bluetooth audio
<steev>
clover[m]: it's not 6.8 (sorry!) but i did just push 6.7.5, which includes the pcie changes from johan, fixed gpu tsens instance (there was a typo in the previous version and it was set as cpu-crit not gpu-crit)
<jhovold>
Here's an updated wip branch for the X13s: