06:19 <dnkl> I'm seeing something really weird... if I switch between two tags, with exactly one view on each, the view gets unmapped from the output, and then immediately remapped, when switching *to* tag. That is, the window is not unmapped when switching away from a tag.

06:19 <dnkl> (river is on latest master)

06:23 <dnkl> WAYLAND_DEBUG shows a wl_surface.leave followed immediately by a wl_surface.enter. Nothing else in-between

06:33 <dnkl> foot, with DPI aware rendering, flickers in multi-monitor setup when it's forced to guess a DPI...

06:35 <LarstiQ> dnkl: does that (still) happen on monitors with scale 1 (looking at https://codeberg.org/dnkl/foot/issues/714)

06:39 <dnkl> that issue is no longer relevant, since there's no longer an "auto" value for "dpi-aware"

06:40 <dnkl> with DPI-aware rendering the scale factor is ignored (for font sizing), so yes, it happens regardless of what the scaling factor is

06:40 <dnkl> we could perhaps remember the last used DPI, and use that when we don't know which DPI to use

06:41 <dnkl> that's how we handle the scaling factor, with dpi-aware=no

06:41 <dnkl> still, this has to be a bug in river...

06:41 <dnkl> I don't see how it could be intentional

06:42 <LarstiQ> I'll refrain from speculating and let someone more qualified answer :)

07:02 <ifreund> dnkl: that sounds like an issue caused by the scene graph API being impossible to update atomically at the moment... I'll have a look and see if things can be improved there

07:15 <dnkl> ifreund: thanks! I'll take a look at my side, to see if I can improve things. I suspect the same issue may occur on some compositors when minimizing the window.

07:45 <dnkl> alright, I can work around it in foot, by stashing the last known "good" DPI value

08:07 <ifreund> hmm, as far as I can tell it's currently intended for wlr_scene to send enter/leave events when a surface becomes visible/hidden

08:08 <ifreund> It sends the leave event late though, which seems like a bug to me and I think I see the cause

08:13 <ifreund> wlr_scene_node_set_enabled() sets node->enabled to false before calling scene_node_update(). This means that that scene_nodes_in_box() will skip the node during iteration since it's disabled

08:13 <dnkl> thanks for looking into it

08:14 <dnkl> after checking again, I do see leave/enter regardless of how many views are mapped

08:14 <ifreund> I'm not quite sure yet why it does end up sending the output leave event right before enter

08:14 <dnkl> which makes sense given your expansion

08:14 <dnkl> explanation

08:16 <dnkl> there *is* a difference in how foot renders, with one view vs. many. not sure why, and not sure I care 😅

08:17 <ifreund> hmm, what kind of difference?

08:18 <dnkl> with one view, the window redraws twice. Once with a bad DPI, then it corrects itself

08:19 <dnkl> I can try to check what's going on, later today. Holding a presentation at work soon... 😅

08:19 <ifreund> I think I can explain that

08:20 <ifreund> if there are multiple windows river might drop the bad frames due to waiting for all of the open clients to commit a new buffer in response to the configure

08:21 <ifreund> if there is only one client visible, the first buffer it commits will be displayed right away

08:21 <ifreund> I susped that if you test with multiple foot instances you may see one of them redraw twice (or maybe more, I think it's racy)

08:22 <ifreund> s/susped/suspect/

08:22 <ifreund> anyhow, good luck with the presentation

08:56 <ifreund> dnkl: wlroots issue: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3833

08:59 <ifreund> anyhow, I don't think this is likely to be fixed until wlroots 0.18 unfortunately though I could perhaps add a hacky workaround

09:00 <vyivel> we could squeeze a fix into 0.17.3

09:00 <ifreund> oh, that would be nice. I'm not sure how complicated the fix will be though.

09:26 <ifreund> heh, waybar can crash river by setting an exclusive zone larger than the width/height of the output

09:26 <ifreund> I think I might consider this a wlroots bug as well, it seems to me that wlr_scene_layer_surface_v1_configure() should handle this

10:28 <dnkl> vyivel: ifreund: thanks, no need to rush from my point of view :)

11:51 <novakane> ah damn, looks like zelbar also makes river crashes, is the wl_output geometry event fine to compare the exclusive zone with outputs width/height?

11:54 <ifreund> novakane: I don't think clients should try and guess what limits the compositor has

11:54 <ifreund> it's fine for the compositor to just close them if they get too greedy

11:54 <ifreund> (most likely due to strange user configuration)

11:55 <novakane> alright thanks, yeah that would be a messed config since using 0 would give you the max usable width/height anyway

12:40 <ifreund> it's release day: https://isaacfreund.com/blog/river-0.3-waylock-1.0/

12:48 <dnkl> congrats!

12:54 <ifreund> thanks :)

12:56 <LarstiQ> woohoo!

13:10 <pfr> How do I map volume and screen brightness keys?

13:10 <pfr> XF86* keys

13:14 <ifreund> pfr: the same as any other key... what isn't working about them?

13:15 <ifreund> you can use `xkbcli interactive-wayland` to figure out the names if that's the issue

13:18 <pfr> so with a `riverctl map normal XF* spawn "raise vol"` for example?

13:18 <pfr> that's what I've tries and it doesn't work.

13:19 <pfr> riverctl map normal XF86AudioRaiseVolume spawn "wpctl set-volume @DEFAULT_AUDIO_SINK@ 5%+"

13:19 <pfr> to be exact

13:20 <ifreund> pfr: you always need to pass modifiers for the mapping to riverctl map

13:20 <ifreund> in this case you want to pass "None" it seems

13:20 <pfr> ahhhh

13:21 <pfr> so.. riverctl map normal None XF86AudioRaiseVolume spawn "wpctl set-volume @DEFAULT_AUDIO_SINK@ 5%+"

13:24 <pfr> or, would the Fn key become the modifier?

13:24 <FireFly> nah, Fn is handled by the keyboard's firmware internally usually, so that should be right

13:26 <FireFly> the example init has https://codeberg.org/river/river/src/branch/master/example/init#L129-L132

13:26 <pfr> cool. xkbcli shows keycodes and keysums. Key code for F5 being FK05 and keysum is simply F5

13:26 <pfr> so perhaps I shouldn't use XF86*

13:27 <pfr> riverctl map normal None F5 spawn ..

13:29 <FireFly> I mean, you could do that but wolud be annoying to not have an F5 key otherwise on the system..

13:29 <pfr> do I need to add the "$mode"

13:29 <FireFly> the $mode is normal

13:29 <FireFly> you're passing it already

13:29 <pfr> gotcha

13:30 <pfr> last question... unrelated to river specifically... but I'm using `brightnessctl` to adjust my laptop screen brightness. THis requires root privliges

13:30 <FireFly> anyway, if it's not detecting/showing the keysym I'd look at if there's some other stage or mapping that handles it already.. for the media keys. at least on most laptops/similar they should emit the XF86 media key keysyms

13:31 <FireFly> pfr: I'm not sure but I'd guess it just writes to the sysfs backlight brightness directly. you could check ls -l /sys/class/backlight/*/brightness or so, at least on my system it's owned by group 'video' (but might vary depending on your distribution)

13:31 <ifreund> pfr: some keyboards have an "fn lock" key or similar to switch between sending e.g. F5 and "volume up"

13:32 <FireFly> (so, rather than being root you could add your user to the video group, in that case)

13:32 <ifreund> you can also use udev rules for that

13:32 <FireFly> true

13:33 <ifreund> which is probably how the video group is assigned in the first place...

13:33 <pfr> I'll look into that. Cheers

13:34 <pfr> when I use xkbcli to check Fn+F4 i get no output at all

13:34 <pfr> so it recognises the Fn key by itself and the F keys individually, but nothing when combined

13:35 <ifreund> pfr: no output could also mean that river has eaten that keypress due to the mapping you have defined for XF86AudioRaiseVolume

13:36 <pfr> True!

13:38 <FireFly> the backlight thing reminds me, a friend and I put a small script together recently for fading the backlight out a bit before locking (for swayidle purposes)--should polish it a bit and see if it makes sense to add to the wiki

13:39 <novakane> congrats on the release 🎉

13:40 <ifreund> thanks!

13:40 <ifreund> FireFly: there's also this tool for that purpose: https://git.sr.ht/~emersion/chayang

13:40 <novakane> you could use the passthrough mode to still gets value in xkbcli

13:41 <FireFly> ifreund: oh, nice, didn't know about that

13:42 <ifreund> fading out the backlight at the hardware level might look a bit different or have some advantage, I haven't tried either myself

14:12 <leon-p> happy release day 🐈

14:12 <ifreund> :)

14:18 <pfr> novakane: how to use passthrough mode with xkbcli?

14:21 <novakane> pfr: the passthrough mode is in river https://codeberg.org/river/river/src/branch/master/example/init#L112-L120

14:24 <ifreund> to be more exact, it's just a mostly empty mode defined by the user

14:24 <ifreund> which can be pretty handy at times

15:13 <tiosgz> ah, release :)

15:15 <tiosgz> ifreund: i'm not sure the layer-shell restriction works for all use cases. a typical thing taking ~half of the screen is an on-screen keyboard (which is usually layer-shell afaik)

15:16 <ifreund> tiosgz: hmm, yeah we cap it at 90% or so instead

15:16 <ifreund> *we could

15:22 <ifreund> I do wonder if anyone uses an on-screen keyboard with river though

15:29 <tiosgz> i don't know if anyone does, but they are more likely to report a bug to its dev when they try

15:29 <tiosgz> and especially with the wm protocol you don't know what everything people will use river for

16:07 <leon-p> IMO layershell isn't usable for on screen keyboards in its current state: you either shrink the available space or hide part of the application window with the OSK which isn't ideal. IIRC on mobile devices, applications get a hint indicating what part of their surface is obscured by the OSK so they can adapt their UI how they see fit. There is currently no wayland protocol for that AFAIK

22:36 <NickH> ifreund: Congratulations on 0.3.0 🎆

22:44 <adamcstephens> 🎉

22:55 <adamcstephens> LarstiQ: I merged the 0.3.0 PR into nixpkgs earlier today, so no need to build once that hits unstable

23:40 <pfr> Some nice changes in 0.3.0

23:42 <pfr> Happy to see the addition of a code of conduct too.

23:42 <pfr> Cheers to everyone for their work on river.