04:59 <sewn> xwayland reaches over 4096 fds

05:00 <sewn> when trying to run steam of course

05:00 <sewn> my concern is why isnt river retrieving the fd limit properly, its configured and reflected in ulimit for my user

05:12 <dnkl> processes don't "retrieve" limits. They're either inherited, or set explicitly

06:31 <LarstiQ> I think that might mean here that river explicitly sets a lower limit than it would inherit, which apparently is not enough to run Steam?

07:45 <lordmzte> I have a cool idea on how I'd like my tag selection keys to work: I hold down the super key, and then I also hold down number keys for all tags I'd like to be active (works on nkro keyboards), then I let go of super while still holding the number keys, locking the selection. Is there even remotely any chance of implementing this?

07:49 <leon-p> lordmzte: check !1100, it will also change how keybinds work

07:54 <lordmzte> oh yea I know of that PR, but I didn't know it changed keybinds. I'm really excited for that! Thanks!

15:37 <sewn> https://envs.sh/s6B.txt

15:38 <sewn> even zig std reports the right value

15:39 <sewn> wait

15:39 <sewn> why is it going for the minimum value

15:42 <sewn> the river comment notes that river shouldnt use a value supposedly higher than 4096, which is problematic for my usecase

15:44 <sewn> https://codeberg.org/river/river/src/branch/master/river/process.zig#L40-L43

15:53 <LarstiQ> sewn: "can be raised further if anyone reaches it in practice."

15:54 <sewn> doesnt seem to be raised further, its a limit of 4096

15:54 <LarstiQ> sewn: so try it out with a value that suits you and if that reproduces working/not working I'd guess ifreund would consider it

15:54 <sewn> is it common for river to leak file descriptors?

15:54 <LarstiQ> sewn: yeah no you need to recompile zig with changing that 4096 to something higher

15:54 <sewn> yeah makes sense

15:55 <sewn> i currently have the limit completely removed because otherwise i wouldnt be able to run steam

15:56 <LarstiQ> so how high does it actually go?

15:56 <sewn> unsure, i have to go lower and lower

15:58 <sewn> steam games running on proton use esync, and they reccomend a hard limit of 1048576.

16:01 <LarstiQ> https://github.com/zfigura/wine/blob/esync/README.esync#L18 right

16:01 <sewn> yep

16:01 <sewn> this is a pretty old fork of esync but in the wine-staging patchset that is also there

16:04 <ifreund> river doesn't modify the hard limit, it only sets its own limit to 4096

16:05 <sewn> thats if the limit is higher than 4096, it caps it there

16:06 <ifreund> sure, we could do soft = @max(soft, @min(4096, hard))

16:07 <ifreund> isn't esync internal to wine though?

16:07 <ifreund> I wouldn't be surpised if the real problem you are having is that xwayland or steam have an fd leak...

16:07 <sewn> one way to find out i guess?

16:07 <ifreund> also river's soft fd limit applies only to the river process, not children...

16:08 <sewn> oh. well thats concerning, since removing the limit makes xwayland work i guess

16:08 <sewn> maybe since xwayland is spawned from the river process ig

16:09 <ifreund> hmm, it might affect xwayland specifically since wlroots spawns that and river doesn't have the chance to reset the rlimt post-fork-pre-execve

16:10 <ifreund> iirc something about new wlroots API to allow that though...

16:12 <sewn> yay

17:02 <ifreund> sewn: could you test this? https://codeberg.org/river/river/pulls/1179

17:04 <sewn> sir yes sir

17:16 <lordmzte> I've been getting various wayland programs printing strange warnings since the latest river update, here's something that mpv prints on exit, for example, but I've observed this in other programs, too: https://gist.github.com/LordMZTE/21f8e7284ab3d3d62e9f02ebc21477b9

17:17 <lordmzte> Is this a bug in river?

17:18 <ifreund> lordmzte: no, that's a minor mpv issue that newer versions of libwayland now warn about

17:22 <lordmzte> Ah, I see. Interesting that it's apparently discouraged to destroy an event queue while there are still proxies bound.

18:25 <gbrlsnchs> sewn: `ulimit -n` shows 1024 for me and I use Steam + river daily. Is the higher number a requirement of a specific game you play? Asking mostly out of curiosity.

18:27 <gbrlsnchs> Although I do have `@users hard nofile 524288` set in /etc/security/limits.conf 🤔

18:46 <sewn> gbrlsnchs: any proton game

18:46 <sewn> ifreund: seems to be working so far

18:47 <sewn> I cant tesr much because my amdgpu is overheating

18:53 <gbrlsnchs> sewn: interesting that I never faced any issues regarding that before

18:55 <sewn> I am on a high refresh rate

18:56 <gbrlsnchs> sewn: does that affect fd limits? and out of curiosity, how high of a refresh rate?

18:56 <sewn> maybe? I'm on 144hz but games run at triple that

18:57 <sewn> the constant rendering could cause esync to get hungry

19:19 <gbrlsnchs> sewn: gotcha... mine is 75hz, for reference

19:19 <gbrlsnchs> but I usually run games at 144hz

20:04 <olie> is there a way to get the tags of windows programatically?

20:07 <olie> theres zriver_output_status_v1::view_tags to get the tags of outputs

21:08 <ifreund> olie: nope, interfacing with river programmatically is very limited currently

21:08 <ifreund> this is changing though, see: https://codeberg.org/river/river/pulls/1100

21:09 <ifreund> (tldr, tags and all other window management policy will be moved out of river to a separate window manager process)

21:13 <olie> so basically river is turning into xorg

21:15 <ifreund> there are some superficial similarities, all the details are different