11:19 <itshog> Hello, I'm currently trying to build river with a local installation of wlroots following the instructions in this issue

11:19 <itshog> https://github.com/riverwm/river/issues/550

11:20 <itshog> But it doesn't work

11:22 <itshog> It seems like `zig build` can't find wlroots

11:30 <ifreund> itshog: what does pkg-config -l wlroots say?

12:35 <itshog> ifreund: The -l flag is not recognized

12:36 <itshog> But running `pkg-config --libs wlroots` gives `-L/usr/local/lib -lwlroots`

12:40 <ifreund> and is your wlroots installed there?

12:41 <ifreund> if so everything should work fine

12:45 <itshog> No, it's in a test directory at .local/tmp/usr/local/lib

12:47 <ifreund> well there's your problem

12:48 <ifreund> you need to point pkg-config to the wlroots.pc file for your local install

12:48 <ifreund> the pkg-config man page should tell you how to do so

14:58 <lordmzte> I'm having a very strange issue: sometimes when an SDL2 window in an application I wrote opens, river crashes. Unfortunately the log (will send a link in a bit) isn't very helpful, as there are no debug symbols to generate a stack trace with. I use the most recent version of river, built with the river-git AUR package. When I build manually however, I cannot reproduce this (neither in Debug nor

14:58 <lordmzte> ReleaseFast build modes).

15:00 <lordmzte> https://paste.rs/RvpPm (a lot of this is output from child processes spawned by init)

16:02 <ifreund> lordmzte: can you get a stack trase from a coredump?

16:02 <ifreund> (coredumpctl gdb on arch)

16:03 <Guiltyfart> How do I get wlroots 17.1 ? I am on a stable distro  so I had to build wlroots from source but, but after building current master branch from source, zig build complains that I have wlroots version 17.0 installed and not 17.1

16:04 <ifreund> Guiltyfart: river is not compatible with wlroots master, you need to check out the 0.17.1 tag in the wlroots git repo

16:04 <ifreund> or use an 0.17.1 tarball from the wlroots releases page

16:07 <ifreund> lordmzte: also, from a quick glance the AUR PKGBUILD uses ReleaseSafe not ReleaseFast, have you tried that outside of the PKGBUILD?

16:11 <Guiltyfart> thanks for pointing that out, my bad for not scrolling down the listed branches pop up

16:12 <ifreund> lordmzte: actually, I think your crash is https://github.com/riverwm/river/issues/963

16:13 <ifreund> the debug log indicates that wlroots hits the broken codepath... should be fixed by wlroots 0.17.2 when it's out

16:14 <ifreund> (though it would be quite useful to confirm that https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4524 fixes it)

16:14 <ifreund> Guiltyfart: no problem!

16:21 <Guiltyfart> have you ever seen this before? I will I make an issue out of it?

16:22 <Guiltyfart> ```

16:22 <Guiltyfart> install transitive failure

16:22 <Guiltyfart> └─ install river transitive failure

16:22 <Guiltyfart>    └─ zig build-exe river ReleaseSafe native 1 errors

16:22 <Guiltyfart> river/InputConfig.zig:118:14: error: root struct of file 'c' has no member named 'libinput_device_config_dwtp_set_enabled'

16:22 <Guiltyfart>         _ = c.libinput_device_config_dwtp_set_enabled(device, switch (dwtp_state) {

16:22 <Guiltyfart>   ```

16:22 <Guiltyfart> *or will i make a github issue i should say

16:25 <Guiltyfart> I have a libinput pkg installed (1.20)that was required for building wlroots, maybe if i build wlroots with a neewer version of this lib it might solve the issue.

16:25 <Guiltyfart> libinput-dev is for ver 1.20

16:31 <ifreund> Guiltyfart: yeah, error is due to the libinput version being too old... I think that function has been around for at least a year though

16:32 <ifreund> it was added in 1.21, libinput is currently on 1.25...

16:32 <Guiltyfart> yep I found the github pull / issue where this line was added. currently compiling new libinput

16:32 <ifreund> you using debian?

16:34 <lordmzte> ifreund: I doubt it's #963, as the crash happens on opening the window, not closing it. Will get a stack trace.

16:35 <Guiltyfart> pop os (needed ubuntu derivative to run vivado on -_- )

16:36 <lordmzte> Actually, it might be: https://paste.rs/jCcSO

16:37 <ifreund> lordmzte: you would be surprised at the crazy illogical things X11 programs and SDL do...

16:37 <ifreund> would you mind trying with the linked wlroots patch?

16:38 <lordmzte> hah yea - SDL2 is currently just the contemporary backend for my GUI engine. will get rid of it :D

16:38 <lordmzte> sure!

16:52 <lordmzte> If I run river master with the wlr commit of the PR you linked in LD_PRELOAD, I get a crash immediately when starting river. Log: https://paste.rs/pdSrK stack trace: https://paste.rs/neY2o

16:53 <lordmzte> This is a debug build now, turns out I just couldn't repro it earlier because I was missing -Dxwayland

16:54 <ifreund> lordmzte: I think you're using wlroots master but need to be using the 0.17 branch

16:54 <lordmzte> I'm using the PR you linked here.

16:54 <ifreund> wlroots master has breaking changes not compatible with river and in particular zig-wlroots

16:54 <ifreund> that PR is a PR to master branch, you can either cherry-pick that commit onto 0.17.1 or use the 0.17 branch

16:55 <ifreund> sorry for not making that clear

16:55 <lordmzte> Oh I see. I actually was using the tip of the 0.17 branch already with a small patch to fix screenshare on nvidia - I also managed to repro it there.

16:55 <ifreund> actually, I don't think the 0.17 branch has the cherry-picked version of that commit yet, you could use this backports branch: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4525

16:56 <lordmzte> I can just cherry-pick it on if it doesn't have it.

16:56 <lordmzte> Alright, will try it. BRB

16:56 <ifreund> thanks :)

16:58 <lordmzte> It is indeed fixed!

16:59 <ifreund> excellent, thanks for confirming. I never could reproduce that issue but I don't use much X11 stuff

17:16 <lordmzte> I'll work on #635 now. One question to begin with: what's the best way to express "unmap this input from any output" on the CLI?

17:16 <lordmzte> The interface I have in mind for now is `riverctl input INPUT_NAME map-to-output OUTPUT_NAME`

17:17 <lordmzte> s/INPUT_NAME/INPUT_GLOB

17:19 <ifreund> lordmzte: perhaps just `riverctl input <glob> map-to-output disable`

17:20 <lordmzte> wouldn't that be a little misleading as, to my understanding, it should be something like "all" instead?

17:20 <lordmzte> sorry, I'm asking too many questions that we should probably discuss in the PR

17:21 <ifreund> I don't think either all or disable is inherently more correct, it's just a matter of perspective

17:21 <lordmzte> fair

17:21 <ifreund> feel free to do either for now, we can worry about the bikeshedding once the rest of the patch is ready

17:22 <lordmzte> heh yea :D

17:38 <alebastr> ifreund: is zig 0.12 really planned for next week?

17:38 <lordmzte> ough that means they'll postpone async again

17:59 <lordmzte> How should I get a `wlr.InputDevice` given a `c.libinput_device`?

18:01 <lordmzte> I think the best way would be to change the fact that settings in InputConfig currently take libinput_devices and have them take the wlr device instead. Should be easy enough.

18:04 <ifreund> alebastr: no, what gave you that idea?

18:06 <ifreund> lordmzte: I think it would be cleaner to put all the libinput config options in a LibinputConfig struct and separate them out into a separate file

18:06 <ifreund> then have a field of the InputConfig struct be `libinput_config` or similar

18:07 <ifreund> In general, all the current input config code is pretty libinput specific

18:08 <ifreund> your call if you want to try to refactor things in that way or not though.

18:09 <ifreund> actually, I'd recommend just special casing your new config option and trying to touch as few lines as possible for the feature addition PR

18:09 <ifreund> it's always nicer to review refactoring stuff separately from new features

18:12 <alebastr> ifreund: date on the github milestone :(

18:29 <ifreund> alebastr: ah, that didn't used to be there. I don't know the full story but I haven't heard enough release noises to make me think it will really happen in 6 days

18:30 <ifreund> last I heard the idea was to not set a hard deadline for 0.12.0 and rather try and fix as many issues impacting real world projects as possible

18:32 <lordmzte> Sounds like that'd be best left for another PR, right?

19:10 <lordmzte> It appears that there is a bug in zig-wlroots I'm blocked on here: zig-wlroots declares the extern function `wlr_cursor_map_input_to_output` taking a non-optional output pointer, whereas that argument should actually be nullable. I do not believe the behavior of the output being null is documented anywhere, but reading the implementation, it should have the desired effect.

19:12 <ifreund> lordmzte: luckily that's easy to fix, just send a PR over to https://codeberg.org/ifreund/zig-wlroots

19:13 <lordmzte> :)

19:13 <ifreund> and yeah, reading the source code is usually necessary to do things with wlroots

19:14 <lordmzte> But fair warning: it's unconfirmed whether it's actually optional, but the function will handle it just fine with the current impl and would set a field to null that is null-checked everywhere it's used :D

19:16 <ifreund> lordmzte: I'm pretty sure passing NULL is fine, sway does it for example

19:16 <lordmzte> great

19:17 <ifreund> It probably just didn't look fine at first glance when I wrote the zig-wlroots type signature

19:21 <lordmzte> https://codeberg.org/ifreund/zig-wlroots/pulls/75

19:22 <lordmzte> Would appreciate a quick merge so I don't need to mess too much with the submodule in river :D

19:25 <lordmzte> Thanks!

19:25 <ifreund> no problem :)

19:53 <lordmzte> How do I check whether a given wlr_input_device is attached to a given wlr_cursor?

19:58 <ifreund> lordmzte: until support for multiple seats is added, there is only one wlr_cursor

19:58 <ifreund> (adding support for multiple seats mostly involves some CLI code to assign input devices to seats + fixing bugs)

20:05 <lordmzte> Yea but there are some output devices (keyboards) that belong to no cursor at all, and it'd be nice to have a check for those to not spam the log with wlr errors

20:10 <lordmzte> Hmm, if I map my mouse to an output, then physically unplug that output, river crashes once I move my cursor. trace: https://paste.rs/ggLpz

20:10 <lordmzte> only happens if inputs are mapped to the output

20:23 <ifreund> lordmzte: you should be able to check the type of the input device to make sure it is not a keyboard

20:23 <ifreund> as for the crash on output unplug, sounds like you need to add some code to handle that...

20:25 <lordmzte> Yea, I should be fine if I just recalculate the mappings deactivateOutput

20:26 <lordmzte> I'd prefer not having to check a keyboard, as it seems to me like it would be cleaner to just check the association. Even if strictly all keyboards (and no other input devices) never belong to a cursor, this will pop up again with multi-seat support eventually.

20:31 <lordmzte> Wow, I was wondering why my touchpad wasn't being recognized and turns out it's the old having done a kernel upgrade, forgetting to reboot and then being confused why stuff doesn't work. brb.

20:58 <lordmzte> Review time! https://github.com/riverwm/river/pull/995

21:03 <lordmzte> I'll head to bed. Talk to you tomorrow!

21:49 <vyivel> huh river intends to support multiple seats

21:50 <ifreund> vyivel: is that surprising? :D

21:51 <vyivel> idk, feels like an explosion in complexity with little reward personally

21:51 <vyivel> but you do you

21:52 <ifreund> I don't think it's acutally that much complexity

21:52 <ifreund> It's mostly just a UX problem as far as I can tell

21:52 <vyivel> i'm fairly sure most programs don't know how to deal with multiple seats either

21:53 <ifreund> Most of river's code is already theoretically multi-seat aware but I've been too lazy to add the config bits for assigning input devices to seats

21:53 <ifreund> yeah, programs being unable to handle multiple seats is probably very common, what can you do though

21:54 <vyivel> /shrug

21:54 <vyivel> what do people use multiple seats for?

21:55 <ifreund> I think the wayvnc remoting stuff seems like the most common practical use-case

21:55 <ifreund> ask the sway users though, river users cant use multiple seats yet

21:56 <vyivel> hm, vnc makes sense

22:59 <leon-p> gnome uses multi-seat to give drawing tablets their own cursor

23:07 <Guest5> has anyone/is there a guide to doing a clear install of river under arch?

23:10 <Guest5> i was using sway up till now and it just feels really sluggish, and i wanted to give river a try

23:10 <Guest5> the only reason i was able to install sway was because of archinstall haha

23:20 <Guest5> and what login/dm is everyone using?