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
KREYREN_oftc has joined #aarch64-laptops
echanude has joined #aarch64-laptops
<adamcstephens> Iā€™d love to figure out how to activate the eSIM from Linux :)
<dgilmore> now the fun task of figuring out why systemd is being killed on boot
echanude has quit [Ping timeout: 480 seconds]
paddymahoney has quit [Read error: Connection reset by peer]
paddymahoney has joined #aarch64-laptops
<jglathe_> _[m]123 might take some time till they are available. And we have fun with this thing, still.
<jglathe_> _[m]123 think exponential
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
agl has quit [Remote host closed the connection]
agl has joined #aarch64-laptops
agl is now known as Guest2594
jglathe_volterra has quit [Remote host closed the connection]
<Guest2594> Test
Guest2594 is now known as agl_
agl_ has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
agl_ has joined #aarch64-laptops
agl_ is now known as agl
jhovold has joined #aarch64-laptops
agl has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
jglathe_volterra has joined #aarch64-laptops
agl has joined #aarch64-laptops
agl is now known as Guest2598
Guest2598 has quit []
agl_ has joined #aarch64-laptops
agl_ has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
agl_ has joined #aarch64-laptops
agl_ is now known as agl
agl has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
agl has joined #aarch64-laptops
<agl> Test
<pstef> ok, so I fixed the apparent lack of sound devices by switching from Gnome3 to KDE6. And the testing video that didn't play (just showed still frames) plays as expected under vlc
<pstef> I'm still not sure I get hw accel, I'll have to test that later today
<jhovold> _[m]123, konradybcio: that sounds promising, how often did you hit the resets before disabling qseecom?
<jhovold> _[m]123: do you remember what you did when you saw those dspp errors in the log? or do you seem them on every boot?
<konradybcio> jhovold up to 4 times a day or thereabouts
<konradybcio> commonly when opening firefox from the default kde start menu, not sure which part is more important
<jhovold> konradybcio: can you add some printks to the qcom efivar implementation and check if there are any accesses during runtime (and boot)? sounds a little far fetched, but we can trigger a reset by simply reading an efi variable in a loop currently
<steev> pstef: for hw video acceleration you need a firmware from the windows partition that (afaik) hasn't been submitted upstream like the rest have
KREYREN_oftc has quit [Ping timeout: 480 seconds]
<konradybcio> jhovold sure, in a couple hours
KREYREN_oftc has joined #aarch64-laptops
<jhovold> no rush
<_[m]123> jhovold it was multiple times per 24h so yes,progress!
<_[m]123> those were on connecting through the dock I believe, hdmi cable 'cycle'
<_[m]123> I always have the same set of apps open
<jhovold> _[m]123: and your modeset output from yesterday was with everything connected in the same setup
<jhovold> ?
iivanov has quit [Quit: Leaving...]
iivanov has joined #aarch64-laptops
iivanov has quit []
iivanov has joined #aarch64-laptops
<_[m]123> <jhovold> "\: and your modeset output..." <- that was with direct connection since the hotplug is borked via dock, don't always have the patience to replug 10 times
<_[m]123> I'll make a docking one now
<_[m]123> still wtf, I open the laptop with the external tv off, but the login screen opens on the external fckng crap
<pstef> steev: do you mean a690_gmu.bin? FW loader doesn't seem to complain about it missing
<_[m]123> somehow it disabled the internal screen both on direct ext screen and through dock
<_[m]123> should I open an issue in that repo that got linked yesterday?
<jhovold> pstef: he was referring to qcvss8280.mbn
<jhovold> for video acceleration
<jhovold> _[m]123: still no CTM blobs
<jhovold> doesn't hurt opening an issue, it seems you should never hit those errors on the X13s, so could indicate something is broken
<jhovold> just be specific in the report; when you saw it, setup, x13s, dock, compositor, ...
<_[m]123> yeah it's all a bit blurry I should've paid more attention, will look later
<pstef> jhovold: oh I already have it
xroumegue has joined #aarch64-laptops
Caterpillar has joined #aarch64-laptops
jglathe_ has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
jglathe_x13s has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
<adamcstephens> looks like i'm getting the same link training errors on 6.8 as _[m]123 , which correspond to the external display having issues
<adamcstephens> what prints the drm info in that paste.debian link?
<_[m]123> apt install librdrm-tests
<_[m]123> modesetup
<_[m]123> then
<_[m]123> if I remember
<_[m]123> s/modesetup/modetest/
<adamcstephens> thanks. i'm not a debian-based distro but the command is enough :)
<adamcstephens> so are the CTM blobs something we're still waiting on?
<_[m]123> damn it, reset again when afk and nothing in journald
<_[m]123> I guess it doesn't write active journald on improper shutdown ?
<_[m]123> it jumps from feb 27 to today boot though, might be misconfig
<adamcstephens> yes, there's generally not a chance to write logs to disk during a reset
<_[m]123> > system.journal corrupted or uncleanly shut down, renaming and replacing
<_[m]123> I left the laptop open because was uploading something
<jhovold> _[m]123: ok, still good to now that qcseecom isn't involved then
<jhovold> so it seems something in 6.7..wip/sc8280xp-v6.8-rc7 broke or started triggering an existing bug
<jhovold> and so far only _[m]123 and konradybcio who both run kde/plasma5 and ubuntu/debian appear to be affected
<Jasper[m]> Is this the same issue that turns off the laptop after FDE decryption?
<_[m]123> it's runtime, not boot
<_[m]123> and I only had the reboot issue on my arch install
<Jasper[m]> Ah, yeah only used to have that on occasion, but not anymore on Fedora at leazt
<Jasper[m]> *least
echanude has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
jglathe_x13s has quit [Ping timeout: 480 seconds]
jglathe_x13s has joined #aarch64-laptops
<dgilmore> jhovold: hotplugging worked when I used the USB cable that came with my monitor but not when using an anker one I have
ema has quit [Quit: leaving]
ema has joined #aarch64-laptops
Caterpillar has quit [Quit: Konversation terminated!]
Caterpillar has joined #aarch64-laptops
<jhovold> dgilmore: ok, was that the issue all along or did both cables work with 6.7?
<dgilmore> I will need to install 6.7 to check. First I need to recover the system. It crashed and now systemd gets killed when booting
<craftyguy> has anyone had problems with bluetooth after upgrading the x13s to jhovold's 6.8 kernel?
<craftyguy> I haven't debugged it much yet, just noticed it wasn't working properly (but reverting to 6.8-rc6 made it work), thought I'd ask here before debugging further just in case it was known :P
<jhovold> craftyguy: it's the first time I hear of any bluetooth regressions in 6.8
<craftyguy> ok, np, I'll poke around
<jhovold> hwo does it manifest itself?
<jhovold> how*
<craftyguy> right now, errors in bluez (e.g. "org.bluez.Error.Failed br-connection-sdp-search" when tryin gto connect to a device), no errors in dmesg or anything...
<craftyguy> I am using a different bt firmware, straight from lenovo and not from linux-firmware. so I'm going to try rolling that back first
<jhovold> yeah, there were some issues even with the latest bt fw in linux-firmware
<craftyguy> I'm using hpnv21.b8c
<craftyguy> extracted from the exe @ lenovo.com
<craftyguy> this worked on 6.8-rc6, which is confusing (for me at least, heh). I've been using this fw for a few months now, it really helps fix the bluetooth range issues for me
<jhovold> yeah, i don't see why it would work better with rc6 either
<jhovold> ok, qcom did do some changes to the mainline driver since rc6, so likely yet another regression...
<jhovold> ffs, that's not the only thing they broke, so tired of this...
<craftyguy> changes in the bluetooth driver?
<jhovold> yep
<jhovold> merged in after rc6
<craftyguy> I was going to check that now actually, and start reverting any BT changes to see if any "fixed" it
<jhovold> at least on change should just be reverted
<jhovold> not sure if the other is related to what you just reported
<craftyguy> can you share the shas?
<jhovold> this one should be reverted:
<jhovold> 7dcd3e014aa7 ("Bluetooth: hci_qca: Set BDA quirk bit if fwnode exists in DT")
<jhovold> and probably fixes your issue too
<craftyguy> ok I'll try it
<jhovold> there one or two more you can reverting if that one isn't enough
<jhovold> try reverting*
<craftyguy> sure no problem, I'm happy to try. thanks for your expert analysis of this, I would have just started blindly reverting BT stuff and hope for the best xD
<jhovold> np, thanks for reporting this, I'll send a revert of that first commit tomorrow in any case
<craftyguy> jhovold: (relatively) good news! reverting 7dcd3e014aa7 seems to fix it for me
<craftyguy> I can connect to my headset now, at least (was failing before reverting)
<craftyguy> wtf qcom for sending breaking changes in a late rc
<jhovold> rc7 even...
<jhovold> thanks for confirming
<craftyguy> yeah, brutal. you're very welcome, thanks for the help tracking it down. I got my tunes back \o/
<_[m]123> qcom does kernel dev?
<jhovold> sort of ;)
<_[m]123> they're testing your resilience
<_[m]123> guess it counts as a form of QA šŸ˜„
<pstef> once everything started working for me, x13s is really satisfying to use. Thanks for making it possible
<craftyguy> welp, this is weird... toggling dpms seems to make my mouse cursor disappear on sway/wlroots. is the x13s using a hw cursor or ? /me not sure where to start with this one, the stack is deeeep
<steev> it should be
<craftyguy> ugh so maybe another 6.8 regression?
<craftyguy> I don't actually know how cursors work heh
<craftyguy> if I restart sway, it comes back
<craftyguy> and nothing printed to dmesg, sway log, or syslog when it happens. niiiice :P
<_[m]123> just random disconnect... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/bUWYSOCdFXpMClkXIfGBUoQy>)
<_[m]123> * just random disconnect... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/AoJmMTUCghqlNBKexYbvHwyB>)
<_[m]123> ok so no way to get it back through the docking station, immediately connected when I put hdmi-> anker to usb c adapter but again disabled internal screen
<robclark> craftyguy: dump $debugfs/dri/0/state .. that should show what drm core _thinks_ the state is (incl cursor planes).. that will tell you if userspace vs kernel bug
<craftyguy> robclark: awesome, ok I'll check that out
iivanov has quit [Quit: Leaving...]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
hexdump01 has quit []
hexdump0815 has joined #aarch64-laptops
jglathe_x13s has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
<craftyguy> robclark: here's the diff between state before dpms screen off and cursor was visible, and after dpms screen on when cursor was no longer visible: http://0x0.st/s/h48jie8wPg3MG-RGc0JpYg/HFoG.diff
<robclark> ok, I'm going to guess the 512x512 layer was the hw cursor.. it is showing up in the before but not after. So I think sway is not restoring the hwcursor
<craftyguy> so it's probably a userspace problem, right?
<robclark> I think, yes
jglathe_volterra has quit [Remote host closed the connection]
<craftyguy> thanks for the help narrowing down the search :P
jhovold has quit [Ping timeout: 480 seconds]
<agl> steev: Are you ready with the new 5.8 kernel?
<agl> 6.8
echanude has quit [Ping timeout: 480 seconds]
ellyq has joined #aarch64-laptops
<steev> i still need to do the config changes, sorry
checkfoc_us has quit []
checkfoc_us has joined #aarch64-laptops