02:37 <jacobly> primary selection broke for one application recently, bisecting now

02:41 <jacobly> c2ce893dd0b05a11b7907c6a6af92eb5d74e288e is the first bad commit

02:43 <jacobly> good log: `debug(wlroots): [xwayland/selection/incoming.c:487] XCB_XFIXES_SELECTION_NOTIFY (selection=1, owner=2097154)`

02:44 <jacobly> bad log: `debug(wlroots): [types/wlr_primary_selection.c:49] Rejecting set_primary_selection request, serial 34 was never given to client`

02:47 <jacobly> full logs: https://gist.github.com/jacobly0/643113f4d2f10e845cccb80c4dbbd2ec

09:43 <ifreund> jacobly: thanks, that commit is proving much more problematic than expected :/

09:44 <ifreund> It looks like this is an Xwayland client?

11:16 <upsala_> Is it possible to make the resizing via keyboard repeat when the key is held?

11:17 <upsala_> maybe with an additional optional parameter that represents the time in ms between every repeat

11:17 <upsala_> if 0 it is not repeating

11:17 <ifreund> upsala_: have you tried using a mapping with -repeat?

11:18 <upsala_> I have not :(

11:18 <ifreund> it uses the same keyboard repeat rate/delay for key repeat that can be set with `riverctl set-repeat`

11:19 <upsala_> ok perfect, I should've (as always) checked the manpage first, my bad

11:20 <ifreund> no worries :D

11:21 <upsala_> Ok, I actually don't care about the mpv anymore then :)

11:21 <upsala_> +issue

11:26 <ifreund> heh, I still want to fix it though. I don't like river having bugs

12:31 <jacobly> well it's not supposed to be an Xwayland client

13:17 <jacobly> and with the latest commit I'm hitting an assertion

13:18 <jacobly> `river[5164]: assert(self.focused_output == target_layer.output);`

13:40 <ifreund> hmm, perhaps that assertion was a bit too overzealous

13:41 <ifreund> jacobly: how are you able to reproduce that?

13:42 <jacobly> it happens on startup, can't do any more testing until tonight

13:43 <ifreund> ok, no worries

13:44 <ifreund> what kind of layer-shell programs (status bars, launchers, and the like) are you using?

13:44 <ifreund> in particular, which are you starting from your init script?

13:45 <jacobly> it happens in the river session that only runs wlgreet

13:45 <ifreund> that should probably be enough to reproduce it, thanks

13:49 <jacobly> I think it happens as soon as wlgreet launches

14:14 <ifreund> jacobly: should be fixed :)

15:04 <jacobly> thanks, also should I be testing if the monitor disable issue wasa fixed? I also noticed that there is an issue when pressing the physical power button of an active monitor, not sure if that's the same issue.

15:07 <ifreund> jacobly: no, I haven't had a chance to fix the output configuration issues yet. The workaround currently would to be re-run whatever configuration utility used after enabling/disabling outputs

15:13 <jacobly> hmm, I don't think I'm using one

15:15 <jacobly> but anyway, my current workaround is to never disable outputs

15:16 <jacobly> I think the powering off a monitor issue was a crash so maybe it is different, it was the left monitor if that matters

15:16 <ifreund> by "configuration utility" I mean wlr-randr, kanshi, wdisplays, or similar. Some wlr-output-management cleint

15:16 <ifreund> the crashes on output hotplug should be fixed, the issue where one can end up with overlapping outputs isn't yet though

15:20 <jacobly> got it, I'm not sure how to use wlr-randr when I'm unable to connect to the wayland server, but I haven't tried

15:24 <ifreund> settting WAYLAND_DISPLAY=wayland-1 should work

15:24 <ifreund> (maybe replace 1 with a higher number if needed)

15:26 <jacobly> sorry, I mean when the monitors are overlapping I get ConnectionRefused and similar errors

15:28 <ifreund> while running stuff from within the wayland session? that's surprising

15:28 <ifreund> I'd only expect that if the wayland compositor crashes or one attempts to run something without WAYLAND_DISPLAY set

15:30 <jacobly> maybe it was an unrelated environment issue I already fixed, will try again