11:20 <lordmzte90> Hello! Having a strange issue where XWayland windows won't get any mouse events, I can reproduce this on both 0.3.0 and the latest commit. Any clues?

11:21 <lordmzte90> I'm on a Steam Deck running NixOS, river has been started by GDM (and a shim script in between that shouldn't do much; that works on all my other machines).

11:23 <ifreund> lordmzte: xwayland doesn't handle negative output coordinates, check your output configuration to make sure all outputs have exclusively positive coordinates

11:23 <lordmzte90> Oh yep, that's it!

11:23 <lordmzte90> Interesting.

11:23 <FireFly> ah that's good to be aware of

11:24 <ifreund> we should probably find some way to make this less of a footgun, I don't think sway does any better than river here currently for example

11:24 <lordmzte90> Changed my output coords around to be positive and everything works. I guess this must be kinda common given how quickly you figured it out :P

11:26 <ifreund> I don't acutally see people run into it all that often, It's just the only thing that made sense :D

11:53 <adamcstephens> Can you just prevent negative coordinates?

12:06 <FireFly> or offset everything--but I guess it kind of conflicts with relying on the wlr-output-management protocol to handle the output management

12:08 <FireFly> I wonedr if it'd be practical for xwayland to do the offsetting toward its client (so the client sees a translated space vs everything else) or if that would just cause more issues from now having two different coordinate systems

12:14 <ifreund> I believe there's some technical issue preventing xwayland from fixing this but I don't remember details or understand Xorg internals

12:14 <ifreund> https://gitlab.freedesktop.org/xorg/xserver/-/issues/899

12:14 <ifreund> https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/395

12:16 <ifreund> Perhaps river should reject negative coordinates suggested by wlr-output-managent if xwayland is enabled

12:33 <lordmzte29> That sounds like a good idea to prevent people from running into this, especially given that it doesn't look like anything is about to happen on the xwayland side any time soon.

12:35 <FireFly> yeah, I guess it's the reasonable workaround for now

12:38 <lordmzte29> I could work on a PR adding this check if that's fine.

12:38 <ifreund> https://codeberg.org/river/river/issues/1058

12:44 <ifreund> lordmzte: go for it if you like :)

12:45 <lordmzte29> Will do!

13:27 <lordmzte29> https://codeberg.org/river/river/pulls/1059 (y)

16:24 <sewn> anyone know what this 'error: no field or member function named 'execAllowFail' in 'Build'' build error in river/waylock/etc is?

16:25 <sewn> alpine can no longer build these programs on zig 0.12.0, so it is no longer possible to build from source without an archive of the original zig 0.11.0 package (gone due to repository change maybe)

16:35 <leon-p> you can get a statically linked executable of older zig versions from the zig website

16:54 <sewn> but what is causing this build error?

16:59 <novakane> well, breaking changes between zig 0.11 and zig 0

16:59 <novakane> 0.12

17:01 <novakane> execAllowFail probably has a new name

17:02 <sewn> what could that be?

17:06 <novakane> no idea, I haven't check

17:16 <sewn> boo.

17:19 <novakane> it's not like knowing the new name will fix your problem if you still use zig 0.12 to build these projects

21:31 <ifreund> sewn: ill make a zig 0.12.0 compatible release soonish

21:32 <ifreund> Im on vacation next week though and dont know if I'll find the time before then

21:32 <ifreund> if you want a patch for 0.12.0 compatibility see the next-zig branch

22:50 <yiyu> Hello! I apologize for this noob question. I was having some problem with KDE Connect while using river, and I traced it down and realized that it has something to do with dbus. I'm currently on NixOS, and I found this in the default config for sway from NixOS's Sway declaration: `exec dbus-update-activation-environment --systemd DISPLAY

22:50 <yiyu> WAYLAND_DISPLAY SWAYSOCK XDG_CURRENT_DESKTOP`. It fixed the problem, but I don't know why and how. I tried to look up the doc for dbus, but it's not that easily for me to understand. Can someone explain, if it's very complicated, maybe a link to the documentation would help? Thanks :)

22:53 <ifreund> yiyu: I don't know the details of your situation but in general things started through dbus activation will inherit the environment of the dbus process

22:54 <ifreund> this environment will likely be missing WAYLAND_DISPLAY, DISPLAY, etc unless the dbus process was started from within river (not at all a typical setup)

22:57 <ifreund> that command appears to add the missing environment variables to the environment used by dbus to start programs through dbus activation

23:01 <yiyu> Thanks for the reply! What would be the best practice to do all of this then? I currently start river from tty. Would it be better to update the dbus env in river's init script, or should I write a startup script that sets the env variable before launching river?

23:03 <ifreund> river's init script is the right place to do this, WAYLAND_DISPLAY and DISPLAY aren't set before launching river

23:08 <yiyu> Sounds good. Thank you so much for the help!