00:19 <NickH> adamc

00:20 <NickH> adamcstephens: the head of river has been on zig 0.17.2 for almost a week now, so depending on how old your build is you may be using it already

07:43 <lordmzte> ifreund: well, it seems like the hyprland folks have found a workaround though :)

07:43 <lordmzte> also, what are nvk and zink? :P

10:18 <ifreund> lordmzte: river uses the wlroots renderer. wlroots policy is to stick to open standards and not add workarounds for black-box proprietary drivers like nvidia

10:18 <ifreund> I think this is the only way to make development sustaniable

10:18 <ifreund> nvk is a new open source implementation of vulkan for nvidia hardware in mesa that's seen fantastic progress this year

10:19 <ifreund> zink is an implementation of opengl on top of vulkan in mesa that can be combined with nvk for an alternative to noveau

12:20 <dagle> Managed to crash river yesterday, then I found out that I actually managed to crash the gpu and it required a reboot. :)

12:21 <leon-p> careful: gpu crashes could indicate issues in the power distribution of your setup. I fried a set of RAM once that way because a laptops battery was acting up

12:23 <dagle> I think this was a driver / mesa / something else issue.

12:35 <ifreund> dagle: sounds like a GPU reset, wlroots has made the necessary changes to allow us to recover from those but they haven't landed in a wlroots release yet

12:36 <ifreund> with wlroots 0.18 we should be able to handle that kind of error

13:36 <lordmzte> ifreund: I do understand that wlroots doesn't upstream workarounds, but wouldn't it make sense to maintain a fork of wlr with patches regarding this? I already have my own minimally patched fork of wlr, mainly for screenshare, but i'm not sure if there's a patch for this problem I'm having, but there might be. About nvk, I don't think I'm ready to

13:36 <lordmzte> move away from proprietary nvidia drivers just yet, sadly, mostly because I often use cuda for de-/encoding and rendering and do often need GPU performance. Is wlr's vulkan backend considered better than the gles2 backend on nvidia hardware?

13:44 <leon-p> can't you do compute on vulkan? I am pretty sure cuda isn't really needed for that anymore.

13:45 <lordmzte> I don't think mpv supports hardware decoding with vulkan :D

13:49 <lordmzte> (and neither does kdenlive support hardware encoding without cuda. blender probably doesn't either)

13:51 <leon-p> 🤷 maybe I'll look it up once I am at my desk again. That laptop has an nvidia chip. Would be neat if I could use it from Linux so I could finally play sins of a solar empire again...

13:55 <lordmzte> The vulkan renderer also seems broken with cursors. I only have half a cursor despite `WLR_NO_HARDWARE_CURSORS=1`

14:26 <ifreund> lordmzte: I personally will have nothing to do with non-upstream wlroots forks, it's not a supported use-case for wlroots or river

14:27 <ifreund> perhaps the explicit synchronization work that looks like it will land soonish will help with your flickering, iirc nvidia's implicit sync is totally broken

14:28 <lordmzte> I totally understand! Thanks for the insights!

14:28 <ifreund> I know it's frustrating that your hardware doesn't work, this is really on your hardware vendor though not river/wlroots

14:28 <ifreund> at least one nvidia engineer is working with upstream wlroots/wayland-protocols to improve the situation fwiw

15:07 <lordmzte> Of course, but given that nvidia is notoriously bad at actually addressing the problems of their customers, I have to rely on workarounds in wlr/river, but I of course understand that you don't want to have to worry about that, I understand.

15:31 <adamcstephens> you do have another option, even if not ideal. buy a gpu from another company :)

15:34 <lordmzte> Well, not only do GPUs cost money, but also nvidia GPUs are unfortunately the most powerful last time I checked anyways. I could do dual GPU, but that's kinda expensive in terms of electricity and probably a driver nightmare

15:40 <vimproved> ifreund: yeah i saw the GPU reset stuff land in sway recently

17:51 <angry_vincent> bem

17:52 <angry_vincent> sorry, mistypo

18:05 <lordmzte> Just had river randomly crash while opening a window. Coredump: https://paste.rs/2OYpj River log: https://paste.rs/IHsa7

18:08 <lordmzte> Hah nice, it's even reproducible. It always happens when running my script, `vinput` (which does some cursed stuff ATM, but this isn't really an acceptable failure mode). code: https://git.mzte.de/LordMZTE/dotfiles/src/branch/master/scripts/vinput

18:08 <lordmzte> See ClipboardConnection.zig

18:12 <lordmzte> Note that this code used to run a few river commits ago, it did often leave "dangling" window frames and general glitchyness though

18:48 <ifreund> lordmzte: that stack trace doesn't have line numbers... could you try running bt in gdb?

18:57 <lordmzte> https://paste.rs/XczQ0 here ya go

19:11 <ifreund> lordmzte: hmm, its still not terribly helpful due to inlining sadly but it seems to be corruption of one of the linked lists iterated in Root.commitTransaction()

19:12 <ifreund> it would be really helpful if you could reproduce it under valgrind, I can try and see if I can reproduce it myself tomorrow

19:22 <lordmzte> Hmm, last time I touched valgrind, everything would slow down to 0 and I didn't get any useful info out of it. Got any quick guides for it?

19:25 <ifreund> lordmzte: the bug you hit seems unrelated to backend-specific code so it should be possible to reproduce in a nesed river session

19:25 <ifreund> just run valgrind river from within a river session, reproduce the crash, and give me the valgrind output

19:25 <ifreund> the only problem is, valgrind will make river run very slowly, so the crash might not reproduce if it is a race condition...

19:26 <ifreund> trying with a debug build of river would also be worthwhile as it ususally gives much better stack traces

19:27 <lordmzte> hmm, valgrind won't launch due to missing debug symbols for ld.so

19:29 <lordmzte> hmm, might be due to updating stuff and not rebooting, brb

19:30 <lordmzte> nope, still no good

19:31 <ifreund> huh, what distro?

19:31 <lordmzte> arch

19:32 <lordmzte> huh, fixed by setting `DEBUGINFOD_URLS`

19:32 <lordmzte> dinner time, will give this a shot afterwards

19:33 <ifreund> thanks!

20:07 <lordmzte> Got a valgrind log with a debug build of river. Seems to be an assertion failure, there's a nice trace now: https://paste.rs/FqbBW

20:07 <lordmzte> Also of note: I was unable to reproduce this in a nested session, it works there.

20:10 <lordmzte> vinput (the offender here) gets access to the clipboard via some old protocol (forgot the specifics) that requires a window, but the app itself doesn't have a window, so it creates a surface and then immediately destroys it again. smells raceconditiony to me.

20:10 <lordmzte> (yes I need to improve my code)

20:49 <ifreund> lordmzte: yes! this valgrind output will be very useful thanks

20:50 <ifreund> as for vinput, that "old protocol" is literally wayland.xml and this is a feature(TM) to avoid e.g. proprietary programs without focus from sniffing passwords off your clipboard

20:50 <ifreund> you probably want the "privledged" wlr-data-control protocol for fancy clipboard manager like stuff

20:51 <lordmzte> Yea I know, that's what I was referring to. I also don't think this "feature" really makes sense because you can barely see the window popping up for a few milliseconds.

20:52 <lordmzte> windows user probably won't even recognize a window popping up and immediately disappearing as unusual lol

20:52 <lordmzte> s/user/users

20:55 <ifreund> yeah, it's questionally effective in practice for sure

20:56 <lordmzte> since I haven't explained what vinput actually is: it's a script that reads the clipboard into a tmpfile, opens that in an editor and when that exists, puts that file in the clipboard. it's handy for having a one-button solution to type out messages in a sane editor and stuff.

20:57 <lordmzte> and yes, I do fully realize that this could be a 3 line shell script thank you very much

20:57 <lordmzte> but that's boring

20:58 <ifreund> I was gonna say wl-copy and wl-paste would do that just fine xD

21:01 <lordmzte> vinput was written with xlib before i switched to WL. that was........ delightful.

21:31 <ifreund> lordmzte: pushed a commit to this branch that should fix that assertion failure: https://github.com/riverwm/river/tree/assert-fix

21:31 <ifreund> would you mind testing?

21:32 <lordmzte> sure, give me a few minutes.

21:43 <lordmzte> Seems to work!

21:45 <ifreund> excellent, I'll push it to master :)

21:47 <lordmzte> great work! one less bug!

22:50 <pfr> Is there a way to modify the window border pixel width?

22:54 <novakane> pfr: yes with border-width command, see man riverctl(1)

23:02 <pfr> Thanks