13:28 <ifreund> leon-p: I can reproduce one weird cursor thing on startup that goes away as soon as I move my mouse: I see a second cursor with the wrong orientation on my second 90 degree transformed monitor

13:28 <ifreund> it doesn't happen on river 0.1.0/wlroots 0.14.1

13:28 <ifreund> I can't reproduce any other cursor weirdness on startup

13:29 <ifreund> do you think this is worth delaying 0.1.3 to investigate? if not I'll probably tag that this weekend. A fair number of bugfixes have collected since 0.1.2

13:33 <leon-p> ifreund: I might have time today to investigate, if not I don't think its worth delaying 0.1.3 for though

13:36 <ifreund> cool

13:43 <novakane> oh yeah I use shortlog from 0.1.2, didn't thought there was already so many fixes

14:34 <leon-p> ifreund: fixed it: https://github.com/riverwm/river/pull/520

14:36 <leon-p> also 519 seems worth investigating. I encountered issues that appeared similar whenever I touched cursor code. We probably have a few different places where view size is stored and they may get out of sync

14:42 <ifreund> hmm, yeah that's certainly a bug

15:53 <pkap> When I unfocus an output with full layout, the output is re-rendered with the top-stack view instead of the last focused view. Is this intended for some reason or is it a bug?

15:53 <pkap> I hope it's clear what I mean...

15:55 <ifreund> pkap: what's happening there is that focused views are rendered on top of all unfocused views regardless of the order of the view stack.

15:55 <ifreund> and if no views are focused the stack is just rendered in order

15:56 <ifreund> so it's not really a bug as that's what's intended, but I agree that it'll seem weird with a layout where views overlap

16:02 <pkap> Ah I understand, thank you for the detailed explanation.

16:04 <ifreund> no problem!

16:05 <ifreund> I'm not really attached to this behavior, but I don't know of any better way to do this while keeping things simple

16:06 <leon-p> ifreund: FWIW we already discussed changing render order to reverse focus order

16:07 <ifreund> for which seat though? (yes I know we currently only have one)

16:08 <leon-p> that was your answer back then as well :D

16:08 <ifreund> :D

16:09 <ifreund> Maybe having a specially handled default seat wouldn't be the worst thing in the world

16:09 <ifreund> or we could use focus order across all seats to determine render order

16:09 <leon-p> eh, I think the solution to this can be defered. Just let the layout generator set z ordering eventually and it's no longer rivers problem.

16:09 <ifreund> yep, that's pretty much my plan

16:19 <novakane> is 521 really a bug? I make some test with the game and if the settings is set to fullscreen mode it is weird like in the screnshot but if you set it to windowed it works as expected

16:20 <novakane> so it makes sense that if the game is set in fullscrenn river still saw it as a fullscreen toplevel since it is set by the app

16:20 <leon-p> novakane: if it crashes river, than it vertainly is

16:20 <leon-p> *certainly

16:20 <leon-p> the game rendering weirdly however can definitely be a bug in that game

16:20 <novakane> yeah sure didn't have any crash though

16:21 <leon-p> the issue contains a backtrace from a crash, so apparently for them it did. Maybe you got lucky :P

16:23 <novakane> yeah I saw, I tried switching fullscreen on/off like 30 times in row and didn't have any porblems so I can't say anything about this part lol

16:24 <novakane> but for the rendering that doesn't sounds like an issue for me

16:25 <ifreund> yeah, the bug is the crash

16:25 <leon-p> it's probably part of it. The client - due to a bug or incorrect understanding of Wayland - does something weird, which results in the bad rendering and may result in a crash. The first symptom is not our problem, but the second is. The server should not crash, regardless of how wrong or weird the client behaves.

16:29 <novakane> well can't reproduce it, the only thing I have is a timeout in the transaction at the start of the programm with 2 pending configure

16:30 <leon-p> it may depend on the setup, or maybe you two are running different version?

16:32 <leon-p> Maybe I'll try to reproduce later, but now I have a session I'd rather not loose :P

16:35 <novakane> that's why you have multiple tty :P

17:46 <ghostbuster> so if one of my outputs is not recognized by wlr-randr, is that the responsibility of wlroots?

17:52 <ifreund> ghostbuster: probably yes, you might find more information in debug logs from river

18:04 <ghostbuster> ifreund: i can see it being detected but then it gets deallocated I think

18:04 <ghostbuster> https://termbin.com/mtso

18:05 <ghostbuster> debug(wlroots): [backend/drm/atomic.c:34] connector DP-1: Atomic test failed (modeset): Invalid argument

18:13 <ifreund> ghostbuster: that seems to be the same error as https://github.com/riverwm/river/issues/502

18:14 <ifreund> Pretty sure this a wlroots 0.15.0 change/regression is triggering this

18:17 <ifreund> ghostbuster: do you happen to have sway installed? If so it might be useful to see a debug sway log of whatever they do to make this work

18:17 <ghostbuster> i can test it yeah

18:17 <ghostbuster> FWIW I've had issues with sway as well

18:18 <ghostbuster> this one is intermittent though, all three monitors work sometimes

18:19 <ifreund> gabm[m] in the issue said it worked for them on sway, so they may very well be doing something differently

18:20 <ifreund> sway's code dealing with this stuff is way more complex than river's though, so it's hard to know exactly what thing they do differently matters here :D

18:39 <ghostbuster> hmm i just tried on sway and same issue, only 2/3 displays come up

18:40 <ghostbuster> also interesting that it's not always the same display that fails

18:41 <ifreund> almost certainly a wlroots bug then :/

18:42 <ifreund> feel free to open an issue there with all the logs you have: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues

18:43 <ghostbuster> river has better logs too, sway doesn't even really report an error, even when started with --debug

18:44 <ifreund> hmm, really? maybe they disable debug logs entirely in release builds?

18:50 <ghostbuster> oh nvm I didn't look hard enough

18:51 <ghostbuster> yeah same error, Atomic test failed

18:55 <ifreund> thanks for testing, that certainly suggest a wlroots bug then

19:07 <tiosgz`> re "focus seems not to update after unlocking", apparently it's not that simple, coz i "accidentally" typed something right after and it worked

19:08 <tiosgz`> model situation: a window (nheko) is focused on output eDP-1, with the cursor over a text field (thus that weird text-cursor-ish shape)

19:09 <tiosgz`> i lock the session, then unlock

19:10 <tiosgz`> the previously focused view still has brighter (i.e. focus-marking) border, but the mouse cursor has the default shape and there's no text cursor in the text field

19:11 <tiosgz`> i press "f", which is apparently registered by qutebrowser on my other output, VGA-1, coz it starts showing hints

19:11 <tiosgz`> moving the mouse out of nheko and back onto it restores the expected state

19:12 <ghostbuster> so i'm a complete newbie to all things graphical, but backend/drm/atomic.c is including xf86drm.h and xf86drmMode.h .. are those for xwayland compatibility or is that how modesetting works on linux even for wayland

19:14 <ifreund> I think that's where the modesetting interface lives and the xf86 in the name is just legacy

19:15 <ghostbuster> drmModeAtomicCommit is the the call that's failing and it doesn't seem to be defined within wlroots

19:16 <ifreund> ghostbuster: you'll probably have better luck getting help debugging this in #sway-devel (general wlroots development channel despite the name)

19:16 <ghostbuster> will do

19:16 <ifreund> I'm not very familiar with the DRM api

19:21 <tiosgz`> oops, forgot to note that i have focus-follows-cursor enabled

19:30 <ghostbuster> rebooted and now all monitors come up, randomly

19:31 <ifreund> tiosgz`: ah, yeah it's bound to be related to that

20:00 <tiosgz`> ifreund: the difference with ffc disabled is only that i cannot re-focus the correct view so easily

20:03 <ifreund> tiosgz`: roger that, I see code I wrote that was intended to handle this. Probably need to pull out a debugger and see why it isn't working

20:28 <tiosgz`> ifreund: i think it's coz the lock manager focuses whichever output it wants, but then it just asks the seat to focus last focused view on focused output

20:29 <tiosgz`> focus focus focus, there hasn't been enough of this word :D

20:29 <ifreund> tiosgz`: ah, yeah maybe need to save the currently focused output on lock and restore that

20:30 <tiosgz`> does it need to change it at all during lock?

20:35 <ifreund> tiosgz`: actually probably not, not sure why I made it do that

20:38 <ifreund> tiosgz`: Untested patch: https://0x0.st/oHM9.diff

20:42 <tiosgz`> s/un//, thanks!

20:42 <tiosgz`> will report if i find out it introduces another problem

20:44 <ifreund> tiosgz`: sweet, does that mean it fixes the issues you were seeing?

20:44 <tiosgz`> yes, afaict

20:45 <ifreund> nice, thanks for investigating this