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
<robclark> icecream95: we could set CACHED_COHERENT on more things but I assume there would be a performance penalty
<icecream95> robclark: PIPE_USAGE_STAGING is set, which does mean "fast CPU access"
<icecream95> I am curious as to exactly what the performance penalty is, and whether it matters what level of CPU cache the GPU is reading from
chrisl has joined #aarch64-laptops
<anthony25> am I the only one to get GPU lockups on 6.14 on x1e80100?
chrisl has quit [Ping timeout: 480 seconds]
<robclark> icecream95: writecombine is fast CPU access for what staging buffers are normally used for
<robclark> anthony25: I've not had a chance to try 6.14-rc yet.. (but didn't see any issue with msm-next on top of v6.13.. (but standard disclaimer, if you are still on mesa 24.2 move to 24.3 or newer)
janrinze has quit [Ping timeout: 480 seconds]
<anthony25> JensGlathe[m]: I'll double check on 6.13 with your patch adding the regulators, wifi/bt etc. for the slim 7x, I had a similar issue on 6.13 while charging but didn't ssh into my laptop to check what it was
<anthony25> I had a similar issue after I applied your patch, I mean, and I don't remember having that before
<anthony25> robclark: thanks, I'm on mesa 24.3.4
janrinze has joined #aarch64-laptops
<icecream95> robclark: In any case PERSISTENT | COHERENT is currently buggy and uses WC. But is it a VLC bug that it doesn't always use MAP_COHERENT when available?
pstef_ has joined #aarch64-laptops
<robclark> I don't think MAP_PERSISTENT implies coherent.. IMO this is a vlc bug
<robclark> maybe we should drop the check for STAGING, I guess that should be orthogonal
pstef has quit [Ping timeout: 480 seconds]
<icecream95> But perhaps on other GPUs MAP_PERSISTENT is CPU-cached and faster than PERSISTENT | COHERENT, so VLC can't win
<robclark> I would have to dig thu the mapping of gl usage flags to gallium.. but MAP_PERSISTENT implying coherent seems strange... what we want to look at is whether app is asking for frequent read access
<icecream95> Perhaps the CPU Activity Monitors could be checked for low IPC or stalling on memory accesses... except then you'd have to replace the persistent mapping while it's in use
<robclark> we can't really change cache settings retroactively without reallocating
<robclark> lmk what flags vlc uses and I'll look at it later and see if I can come up with a recommendation.. we can, if needed, at driconf quirk of something like that
chrisl has joined #aarch64-laptops
<robclark> I guess GL_MAP_READ_BIT should be a hint.. but I guess GL_MAP_COHERENT_BIT should be set.. maybe a driconf hint to make READ_BIT imply COHERNENT_BIT, perhaps?
<icecream95> There is also the option of disabling GL_ARB_buffer_storage or GL_ARB_pixel_buffer_object, an extra 4 GB/s memory bandwidth shouldn't matter much for x1e...
chrisl has quit [Ping timeout: 480 seconds]
pstef has joined #aarch64-laptops
<robclark> decoding into malloc memory and memcpy into gpu buffers is probably not a horrrible option.. I guess most video stream are at lower fps than screen so they _potentially_ get sampled by the gpu more than once
pstef_ has quit [Ping timeout: 480 seconds]
pstef_ has joined #aarch64-laptops
pstef has quit [Ping timeout: 480 seconds]
jluthra has quit [Read error: Connection reset by peer]
steev has quit [Read error: Connection reset by peer]
robher has quit [Read error: Connection reset by peer]
ardb has quit [Read error: Connection reset by peer]
leiflindholm has quit [Read error: Connection reset by peer]
rsalveti has quit [Read error: Connection reset by peer]
rsalveti has joined #aarch64-laptops
bylaws has quit [Read error: Connection reset by peer]
lool has quit [Read error: Connection reset by peer]
steev has joined #aarch64-laptops
lool has joined #aarch64-laptops
jluthra has joined #aarch64-laptops
robher has joined #aarch64-laptops
ardb has joined #aarch64-laptops
bylaws has joined #aarch64-laptops
Melody91 has quit [Remote host closed the connection]
leiflindholm has joined #aarch64-laptops
spawacz has quit [Remote host closed the connection]
Melody91 has joined #aarch64-laptops
spawacz has joined #aarch64-laptops
pstef has joined #aarch64-laptops
pstef_ has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hexdump0815 has quit [Ping timeout: 480 seconds]
tobhe has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
hexdump0815 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
pstef_ has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
pstef has quit [Ping timeout: 480 seconds]
pstef has joined #aarch64-laptops
pstef_ has quit [Ping timeout: 480 seconds]
pstef_ has joined #aarch64-laptops
pstef has quit [Ping timeout: 480 seconds]
SpieringsAE has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
pstef has joined #aarch64-laptops
pstef_ has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
pstef_ has joined #aarch64-laptops
pstef has quit [Ping timeout: 480 seconds]
pstef has joined #aarch64-laptops
pstef_ has quit [Ping timeout: 480 seconds]
icecream95 has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> Lenovo Thinkpad Universal Thunderbolt 4 Dock on x13s, works with display (HDMI) and LAN
<JensGlathe[m]> 2 lanes DP altmode and USB-3, nice
srinik has joined #aarch64-laptops
<erebion3421EPVPN[m]> Update to my dock question: Got a Thunderbolt 4 Dock, just arrived and it just works with my X13s.
<smoorgborg[m]> Is this with 6.14rc2?
<erebion3421EPVPN[m]> I'd have preferred a dock with a 2nd USB-C port (for devices), but that one with one port if the only thing I found.
<erebion3421EPVPN[m]> I'm on 6.12.x and it just works
<JensGlathe[m]> I had mine in the closet, bought in '23 but didn't work with the older kernels
<erebion3421EPVPN[m]> Additionally that dock has holes for screws, so I can mount it under the desk, giving me plenty of space on the desk. :)
<JensGlathe[m]> That's good news I guess
<JensGlathe[m]> Asking myself if it also has DisplayLink capabilities
<erebion3421EPVPN[m]> I specifically bought it because it was one of the few where DisplayLink was not mentioned.
<JensGlathe[m]> but 2dp connectors, 1 hdmi... ok with TB4 you get enough bandwidth for those, but not in DP Altmode. So I would assume DisplayLink or something similar.
jglathe_angrybox has joined #aarch64-laptops
landwork has left #aarch64-laptops [#aarch64-laptops]
patrickm has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> Another issue I have had 2 times with 6.14: Kernel NULL pointer exception from wpa_supplicant https://pastebin.com/D531CX55
<JensGlathe[m]> Not very nice
patrickm has joined #aarch64-laptops
abcdw has quit [Remote host closed the connection]
kuruczgy has quit [Remote host closed the connection]
ursa-major has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
flokli has quit [Quit: WeeChat 4.5.1]
flokli has joined #aarch64-laptops
sre has joined #aarch64-laptops
ursa-major has joined #aarch64-laptops
kuruczgy has joined #aarch64-laptops
<erebion3421EPVPN[m]> TIL: The Thunderbolt Dock 4 actually has 2x USB-C on it
<steveej[m]> erebion 🏳️‍🌈♾ 3421@EPVPN: could you share the model or a link? the dock i have hasn't been working great and i'm looking for a replacement
<erebion3421EPVPN[m]> ThinkPad Dock 40B0
abcdw has joined #aarch64-laptops
<maz> yeah, comes with the old, non USB-C power supply! I need one! :)
<JensGlathe[m]> Bought mine on ebay
<\[m]> <erebion3421EPVPN[m]> "ThinkPad Dock 40B0" <- I also have this one but it's performance has been a nuissance
<erebion3421EPVPN[m]> Wait, what. Why would that be a point pro buying one?
<\[m]> can't flash the fw
<erebion3421EPVPN[m]> \[m]: Huh, seems to work fine for my X13s
<\[m]> maz: i can sell you mine - it's shelved for a while
<JensGlathe[m]> Now that support is getting better I‘ll play around with it
<\[m]> I can't remember what it was but it was multi screen I believed? and for work laptop which has windows and IT support unwilling to flash newer tb drivers
<\[m]> but the hardware itself is good for sure BUT the firmware flashing issue is very annoying and no mac os / linux fw flashing tool
<\[m]> e.g. it won't work in macbook m<x>
<\[m]> because parallels doesn't virtualise thunderbolt 🙂
<erebion3421EPVPN[m]> Huh. Well, I guess I don't have any issues with flashing as it just works™.
<\[m]> and in windows, it kept looping on some USB message
<maz> \[m]: I don't *really* need one, but I have a bunch of these power supplies sitting around...
<\[m]> it's probably unwarranted but if I can't flash firmware to my hardware I'm ready to throw it out 🙂
<erebion3421EPVPN[m]> maz: It already comes with a PSU, no need to have/get one.
<\[m]> maz smoll price 😄 hahha
chrisl has joined #aarch64-laptops
<maz> erebion3421EPVPN[m]: you're missing the point. one can never have too many power supplies.
<erebion3421EPVPN[m]> I gave a lot away to other people and reduced the number by a lot, NOW I don
<erebion3421EPVPN[m]> 't have too many power supplies.
<\[m]> it was expensive though but I've gone for the caldigit tb4 now, even more expensive, but you have a mac os flashing tool
<\[m]> lulz you never know you need to desolder a transistor from one or something 😄
<maz> erebion3421EPVPN[m]: well, we are bound to have different opinions on what is needed to live a happy life. extra power supplies are an absolute requirement on my end.
<maz> (and plenty of other things)
<\[m]> s/transistor/capacitor/
<\[m]> I guess if you have thinkpad p models?
<jannau> \[m]: looks like firmware updates using fwupd/lvfs works https://github.com/fwupd/firmware-lenovo/issues/452
<\[m]> I think I have the 40AN but those product codes make no sense to me - I will try nonetheless
<\[m]> ah no it's a newer version my bad
chrisl has quit [Ping timeout: 480 seconds]
<LiangQi[m]> ASUS Vivobook 14 (X1407QA)
<LiangQi[m]> a low end linux arm64 laptop announced recently, 3999 CNY, about 530 euro. Perhaps you can get it at 3199 CNY.
<\[m]> aight fwupd is also in homebrew 🥳
<JensGlathe[m]> <\[m]> "and in windows, it kept looping..." <- Yeah that was annoying and read like some bureaucratic fight between Lenovo and Microsoft
<\[m]> aight it also fails with fwupd 😭
pstef_ has joined #aarch64-laptops
pstef has quit [Ping timeout: 480 seconds]
pstef has joined #aarch64-laptops
<JensGlathe[m]> Liang Qi: probably x1p42100, support for it is very new (but I read a merge message yesterday). Currently we have CRD, Thinkbook 16 and VivoBook S15 supported with it
<JensGlathe[m]> No gpu acceleration yet
pstef_ has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> Oh its x1 26100 even
<JensGlathe[m]> no support yet
<albsen[m]> how can I debug a random freeze and restart on ubuntu? I'm guessing its related to using an external screen, when attached the system suddenly stops and then simply restarts after 10 seconds or so
enyalios has quit [Remote host closed the connection]
enyalios has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
patrickm has quit [Ping timeout: 480 seconds]
pstef_ has joined #aarch64-laptops
patrickm has joined #aarch64-laptops
pstef has quit [Ping timeout: 480 seconds]
pstef has joined #aarch64-laptops
pstef_ has quit [Ping timeout: 480 seconds]
patrickm has quit [Ping timeout: 480 seconds]
patrickm has joined #aarch64-laptops
pstef_ has joined #aarch64-laptops
pstef has quit [Ping timeout: 480 seconds]
patrickm_ has joined #aarch64-laptops
patrickm has quit [Ping timeout: 480 seconds]
patrickm_ is now known as patrickm
chrisl has joined #aarch64-laptops
pstef has joined #aarch64-laptops
patrickm has quit [Ping timeout: 480 seconds]
pstef_ has quit [Ping timeout: 480 seconds]
patrickm has joined #aarch64-laptops
jglathe_ has joined #aarch64-laptops
pstef_ has joined #aarch64-laptops
pstef has quit [Ping timeout: 480 seconds]
jglathe_angrybox has quit [Ping timeout: 480 seconds]
<jhovold> kuruczgy: regarding the rtc, yes, the plan is to use the uefi offset wherever possible (e.g. on machines that have it and where the efi variables are writeable)
<konradybcio> Jens Glathe: IIRC x1p2 should run with x1p4 dt
<JensGlathe[m]> oh nice
<JensGlathe[m]> so its x1p4 binning
<JensGlathe[m]> would be nice to have X1-45 support
<SpieringsAE> a devictree lsp has appeared in the vscode extensions and its pretty neat, much better than just the linter
<SpieringsAE> I can actually ctrl click my way to other nodes now weeee
todi has joined #aarch64-laptops
todi1 has quit [Ping timeout: 480 seconds]
<robclark> I'm hoping qc will post x1-45 support.. it should be quite similar to x1-85, so I'm expecting it to amount to handful of "magic register" values rather than any major changes.
<JensGlathe[m]> wouldbe nice to have
SpieringsAE has quit [Quit: SpieringsAE]
<anthony25> does that mean we could have "generic" firmware binaries in linux-firmware signed by qualcomm instead of each manufacturer?
<JensGlathe[m]> eh what, that would be cool
<JensGlathe[m]> next up, full documentation?
<enyalios> i fixed my weird cifs problem, i needed to set NLS_DEFAULT to "utf8", but i could also work around the problem with `-o iocharset=utf8` when mounting the cifs filesystem
<anthony25> robclark: do you know of any explicit sync issue with freedreno? (on mesa 24.3)
<anthony25> hyprland gets glitchy with explicit sync, I don't know if it's a bug with the compositor or with freedreno
<anthony25> for example, I get flickers in gtk apps (nautilus, password prompt)
<robclark> anthony25: nope .. android and CrOS is 100% explicit sync, and we don't have any issues there
<anthony25> ha they're using freedreno?
<robclark> the qc chromebooks are
<anthony25> I'll check on gnome if I have the same problem, but I need to check if gnome is using explicit sync
<robclark> fwiw, I've been using g-s wayland (it's the default for fedora) with no issues.. idk if it is using explicit sync or not
<d0pefish> anthony25: I noticed the same glitchiness on hyprland and had to disable explicit-sync too, noticed it as soon as I opened a terminal and started typing, it's almost as if the previous frame is shown again or something, like your cursor's going backwards then forwards
<d0pefish> I haven't tried any other desktops yet
<anthony25> d0pefish: we seem to hit the same issue
pengyu[m] has joined #aarch64-laptops
<pengyu[m]> hey, guys. I just purchased one Qualcomm laptop, with secure boot enabled, without UEFI fw configurations, if it is possible to load linux?
<robclark> hmm, I think at present you'd need to be able to disable secure boot.. which laptop doesn't allow this?
<pengyu[m]> robo&kala tw220, sc8280xp based
<Jasper[m]> Oh that thing
<Jasper[m]> Interesting
<Jasper[m]> What leads you to believe that you cannot acces uefi configuration?
<Jasper[m]> s/acces/access/
<pengyu[m]> Jasper[m]: I cannot access it from advanced boot provided by windows. shutdown /r /fw refused to enter UEFI fw
<Jasper[m]> Does spamming keypresses work? Potentially with an external keyboard
<Jasper[m]> s/external/usb/
<Jasper[m]> No idea what the one sold with it connects through
<pengyu[m]> the interesting thing is that it is recognised as QUSB_bulk_cid:xxx_sn:xxx when I attach it to my another laptop.
<pengyu[m]> Jasper[m]: sadly, no
<Jasper[m]> pengyu[m]: As-is or when rebooting to fw?
<pengyu[m]> Jasper[m]: when I keep it unpowered
<pengyu[m]> The manufacturer provided a recovery, when pressing vol- and power, it would boot from external usb(secure boot too), what a weird device.
<Jasper[m]> Do you have pics for that by any chance?
<Jasper[m]> Maybe vol+ and power will work
<Jasper[m]> Or both volume buttons (if the button works like that)
<pengyu[m]> Jasper[m]: you mean QUSB_bulk one?
<Jasper[m]> The recovery mode
<pengyu[m]> Jasper[m]: No, I tried many random ways.
<pengyu[m]> Jasper[m]: it is a windows pe with automatic scripts
<Jasper[m]> Ahhh
<Jasper[m]> @Pengyu could you power it off, leave usb connected to another device and hold both vol up and down?
<pengyu[m]> this is the recovery
<Jasper[m]> Did you remove the ssd?
<anthony25> gnome doesn't enable explicit sync
<anthony25> (but they might just enable it on a list of drivers)
<pengyu[m]> Jasper[m]: yeah, I tried it, boot logo then poweroff
<Jasper[m]> Jasper[m]: And this^
<pengyu[m]> Jasper[m]: remove ssd, power on with vol up and down pressed, right?
<Jasper[m]> SSD removed was a question, but sure. It shouldn't matter normally
<Jasper[m]> Do not press power
<Jasper[m]> Just vol up and down while connected to another pc
todi1 has joined #aarch64-laptops
<pengyu[m]> <Jasper[m]> "Just vol up and down while..." <- nothing special, it gets the device charged
todi has quit [Ping timeout: 480 seconds]
<Jasper[m]> pengyu[m]: To?
<pengyu[m]> Jasper[m]: from host to guest
<Jasper[m]> Oh charged
<Jasper[m]> I thought it said changed
<Jasper[m]> So the qusb_bulk thing didn't change I assume?
<pengyu[m]> I don't know how to reproduce qusb_xxx(edl 9008) thing again
<pengyu[m]> it is really weird
<Jasper[m]> pengyu[m]: Interesting, would be good to have
<Jasper[m]> Both volume buttons or vol up should do that normally
<Jasper[m]> Another thing to try is to have the device powered off, first press volume down and then press power
<Jasper[m]> Instead of at the same time
<pengyu[m]> <Jasper[m]> "Instead of at the same time" <- It boots from USB again
<pengyu[m]> This device make me crazy
<Jasper[m]> And if you let go of power as soon as you see a logo?
<Jasper[m]> pengyu[m]: Keycombo's on these tend to be a bit frustrating to time
<Jasper[m]> But the fact that you got into edl is somewhat promising
<pengyu[m]> yeah, but what can I do when I get into edl?
<Jasper[m]> pengyu[m]: Either not much or a whole lot, depends on how the soc is configured at the factory
<Jasper[m]> Can you try holding down and power again at the same time? Make sure they are held before any logo and such are shown
<Jasper[m]> Shame these are kinda hard to get...
srinik has quit [Ping timeout: 480 seconds]
<pengyu[m]> Jasper[m]: It still tries to boot from usb, if I remove usb, it keeps showing logo, then poweroff after a while.
<Jasper[m]> @Pengyu Did you happen to get this device recently?
<robclark> anthony25: I don't even see hyprland requesting a fence fd, so no idea how it is thinking it is doing synchronization. Interestingly gnome-terminal seems to render fine, but kitty (and presumably some other apps) do not
<anthony25> robclark: on Ubuntu I don't think I can build the last version of hyprland easily because it misses some wayland protocols, but v0.46 seems to have less issue than 0.47 with explicit sync
<anthony25> and nautilus doesn't have the issue on Ubuntu, while on Tumbleweed it flickers a lot
<anthony25> I tested Weston on Ubuntu, and I didn't see the issue, and explicit sync was enabled
<anthony25> pretty difficult to test, as sway and gnome don't enable explicit sync
<pengyu[m]> <Jasper[m]> "@Pengyu Did you happen to get..." <- yes. And I can't bear windows anymore.
<anthony25> I'll see if I can force it in sway (I think I can just authorize it for freedreno)
<robclark> anthony25: idk what enabling explicit sync translates into.. but I'd kinda expect the app to be importing/exporting fence fd's. Which doesn't seem to be the case. It looks more like explicit sync without the sync part, in which case the results are entirely expected ;-)
<anthony25> haha
<anthony25> it's weird that AMDGPU doesn't have the issue
<anthony25> (or intel igpu)
<Jasper[m]> <pengyu[m]> "yes. And I can't bear windows..." <- Where did you get it from if I may ask?
<JensGlathe[m]> is there a secureboot EFI Shell?
<Jasper[m]> From what I can find, yes, but no
<Jasper[m]> Yes, they get leaked sometimes. No, there isn't supposed to be (especially not arm64)
<robclark> anthony25: hmm, so I was testing on a device that only had f39, so older (afaict, pre-explicit-sync) version of hyprland.. which seems to have the same issue?
<robclark> anyways if I'm understanding the config system properly you could try something like:
<anthony25> that's what I did, yes
<anthony25> and it fixes it
<robclark> could you try each of them individually?
<anthony25> if I just disable explicit_sync_kms, it doesn't fix it
<anthony25> disabling explicit_sync is what fixes my issue
<robclark> ok
<anthony25> so I tried to use opengl:force_introspection, it didn't fix it
<anthony25> I might want to try once this patch happens in a stable release: https://github.com/hyprwm/Hyprland/pull/9217
SpieringsAE has joined #aarch64-laptops
<SpieringsAE> anthony25: I've been fighting the glitchy graphics on hyprland as long as I've had my asus, its quite annoying, halloy is practically unusable with how glitchy it is
<SpieringsAE> everything is fine on KDE though, I feel like that should have explicit sync too
<anthony25> try what robclark pasted
<anthony25> it "fixed" all glitches for me
<SpieringsAE> I will, but my asus is currently clonezillaing itself to a new bigger ssd
<SpieringsAE> and it seems like it is going to take a while lol
<SpieringsAE> for some reason the speed is hovering at like 2GB/min right now
<anthony25> wow
<anthony25> does it use a really small block option?
<anthony25> *block size
<SpieringsAE> this is the first time I've ever done this so no idea really
<SpieringsAE> maybe this usb nvme adapter is just very jank idk
<robclark> hmm, so f41 has hyprland 0.44.1 which seems to work fine
<SpieringsAE> block size 4096 bytes
<SpieringsAE> maybe because it is an ntfs partition? I would asume it just dd's it
<robclark> with this version I do actually see eglDupNativeFenceFDANDROID() calls... so it is actually doing sync..
<anthony25> so it's doing explicit sync correctly?
<anthony25> how do you see the egl calls?
<robclark> `apitrace record -a egl Hyprland` ;-)
<robclark> what version of hyprland do you have? If older than 0.44.1 , then maybe this is an already fixed bug?
<anthony25> thanks, so I can bisect
<anthony25> I think it's the other way, they introduced a bug
<anthony25> I have 0.46.2 on Ubuntu, 0.47.2 on Tumbleweed
<robclark> hmm, 0.39.1 was super bad. (but not sure I have enough free disk space on that thing to update to something newer)
<SpieringsAE> I'm running arch linux arm so I pretty much have the newest version, it has been like this as long as I know
<SpieringsAE> since august ish
<SpieringsAE> its not just an arm thing either, because its fine on my pinebook pro
<anthony25> I try to build it on HEAD, I was just curious if it was hitting a bug in freedreno, but probably not
<SpieringsAE> idk it seems like the only possibility to me at this point
<SpieringsAE> or it does something wrong that all drivers except freedreno tolerate
<robclark> or different combination of supported extensions causes hyprland to do something differently, etc
<anthony25> SpieringsAE: I think it was more that by luck it was working well on amdgpu and intel, nvidia seemed to be broken also
<SpieringsAE> it has always been fine on my intel/nvidia laptop, interesting
<robclark> if you can repro, maybe you can apitrace it for me (just `apitrace record -a egl Hyprland`, open a terminal, then exit. should be enough)
<robclark> hyprland does seem to have some checks for nvidia driver, fwiw, and in some cases disables explicit sync w/ nv driver
<SpieringsAE> hmm maybe thats it, it has a 1050 mobile, so kinda old
<robclark> I think is trying to check driver version? but didn't look closely
<anthony25> and the force_introspection option was introduced as a hack to solve glitches on some nvidia gpus with explicit sync
<anthony25> robclark: I quickly try to build hyprland over the last commit, see if I have the same problem, if I do I record an apitrace
<anthony25> thanks a lot for the help!
<anthony25> unless you want to use this case as an experiment to make sure that it indeed doesn't hit a bug in mesa
<robclark> anthony25: another thing you could try is this kernel patch:
<robclark> maybe having syncobj without timeline semaphore is breaking some assumption
<anthony25> last hyprland commit is still buggy (less, but still very glitchy in nautilus or gtk apps)
<anthony25> I send you an apitrace
<robclark> ok, thx
<anthony25> record didn't work, I did `apitrace trace -a egl Hyprland`
<robclark> oh, right, I typod that
SpieringsAE has quit [Remote host closed the connection]
srinik has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
icecream95 has joined #aarch64-laptops
weirdtreething has quit [Read error: Connection reset by peer]
weirdtreething has joined #aarch64-laptops
<anthony25> robclark: I tried your kernel patch (adding DRIVER_SYNCOBJ_TIMELINE), it fixes the problem
<robclark> ok.. I guess hyprland has some bad assumption about timeline semaphore support somehow.. or maybe this is a problem of how wl protocol uses syncobjects
<anthony25> what is the downside of adding the timeline semaphore?
<robclark> I guess I should have another go at enabling `DRIVER_SYNCOBJ_TIMELINE`... I did fixup a few related turnip issues a while back, but dropped the kernel patch because I was still hitting some lockup/hang with turnip, which I didn't have time to debug
<robclark> or maybe it was just an issue with the combo of zink+turnip... I don't remember exactly
<anthony25> I can look at forcing explicit sync in sway, and see how wlroots handles it
<anthony25> I can open a bug to hyprland, the problem is more that there's not a lot of owners of x1e laptops running Hyprland to understand better how the driver works :(
<robclark> I'd have to look at how wl proto uses syncobj fd's.. if it assume timeline semaphore behavior then binary syncobj just won't work..
<robclark> if that is what is going on, then just disabling `DRIVER_SYNCOBJ_TIMELINE` in other drivers should have the same result
weirdtreething_ has joined #aarch64-laptops
weirdtreething has quit [Ping timeout: 480 seconds]
weirdtreething_ is now known as weirdtreething
<robclark> oh, also there was the unanswered question of how to deal with old userspace on a new kernel which started exposing `DRIVER_SYNCOBJ_TIMELINE`.. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25981 .. but maybe enough time has elapsed
<robclark> but yeah, from my reading of https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/linux-drm-syncobj/linux-drm-syncobj-v1.xml?ref_type=heads it seems to have the assumption that DRIVER_SYNCOBJ implies DRIVER_SYNCOBJ_TIMELINE
<robclark> looks like panfrost and lima are the only others to advertise the former but not the later
jhovold has quit [Ping timeout: 480 seconds]
wapitiii[m] has joined #aarch64-laptops
<adrian_> hey, i'm working on the freebsd support for snapdragon x1