04:29 <edrex> schmo: it's a known issue, but nobody has dug in to seriously debug it yet. I have it too (i started using river ~4 days ago) and I'm probably going to try to dig in with some debug statements.

04:30 <edrex> https://github.com/ifreund/river/issues/196

06:13 <leon-p> had to make a minor change to the protocol: Namespaces can't be globally unique, since we have a layoutv1 object per output. So namespaces can only be unique per output

06:55 <edrex> i notice the view -> output map is independent from the view -> tag bitmask, where in i3/sway views -> workspaces and workspaces -> outputs. I like being easily move groups of windows between displays. I guess one could use status info to iterate all the views and move them one at a time, if there were control commands for targeting a particular view

06:56 <edrex> do dwm users just get used to moving individual windows?

06:57 <edrex> i guess that's one of the major features of i3/sway, ability to manipulate groups of views in a lot of ways.

07:01 <leon-p> yeah we currently fall short in that regard.

07:02 <leon-p> Maybe open a feature request or something.

07:02 <leon-p> "move all visible views to different output" is a valid usecase

07:05 <travankor> Do you guys run into the wlr_output_commit freeze?

07:06 <leon-p> Yup.

07:06 <leon-p> frequently

07:06 <leon-p> that's why I am currently on sway

07:06 <travankor> So it's not GPU specific or anything?

07:07 <travankor> I'm on wayfire rn

07:07 <leon-p> ¯\_(ツ)_/¯ I have some intel integrated chip thingy

07:08 <leon-p> (btw, got the river layout PR compiling. Does not actually work yet, but at least it compiles)

07:08 <travankor> 👍

07:09 <travankor> I'm curious if the wlr_output freeze happens for non-Intel people

07:10 <travankor> so amd, nouveau, or panfrost

07:11 <leon-p> Well, this appears to be a bug that only affects river, so I doubt its a driver bug. I'd be surprised and worried if other graphics hardware has the same fault

07:11 <leon-p> s/has/does not have/

07:13 <travankor> I've seen "Atomic commit failed (pageflip)" on sway and wayfire, but this doesn't freeze their compositors

07:14 <leon-p> well, river is also not frozen: you can still do stuff. It apparently just blocks the attaching of other buffers to DRM somehow

07:15 <travankor> ah, yes that's more correct

07:15 <leon-p> hmmm... All other compositors I run (sway, hikari and wayfire) do damage tracking. might be interesting to try a compositor which like river renders at the screens refresh rate

07:20 <edrex> travankor yeah, i'm curious if it's intel only too. I was just going to ask on the issue for ppl to post their chipset

07:24 <edrex> https://github.com/ifreund/river/issues/153#issuecomment-757672357

07:24 <edrex> i've seen something similar with sway early days, but I can't find the issue.

07:25 <travankor> pre-wlroots?

07:25 <edrex> maybe, around that time

07:27 <edrex> but yeah, the pageflip error shows up in sway logs alot (eg when switching VTs) and is usually harmless.

07:28 <travankor> it's always been harmless when I started using sway (around 1.0)

10:14 <ifreund> I have an amd card and haven't been able to reproduce it yet

10:15 <ifreund> I too am curious if the issue might not vanish after implementing damage tracking

10:29 <ifreund> leon-p: you're right that requiring namespaces to be globally unique would be awkward, but it would probably be better UX

10:30 <ifreund> without that you can end up with the same layout client having a different namespace on different outputs

10:30 <ifreund> or different clients having the same namespace of course

10:33 <ifreund> I don't think the code is evern very awkward, we just need to iterate over all clients of all outputs once when handling the get_river_layout request

10:34 <ifreund> (and check if the wl.Client is equal if the namespace is the same)

14:51 <ifreund> hmm, wonder if that's a fuzzel bug or river bug https://0x0.st/-zAT.png

15:13 <snakedye> Is there a way to send windows to another output with the current tag configuration?

15:30 <ifreund> snakedye: you mean the current tags of the destination output?

15:31 <ifreund> not currently, no. Though that will certainly be possible in the future

15:33 <snakedye> I am asking if it's possible to send a window to a tag that belongs to another output. Basically moving an application to another output.

15:47 <dnkl> ifreund: I never seen that with fuzzel before

15:47 <dnkl> Doesn't mean there isn't a problem with fuzzel, of course

15:49 <dnkl> Auto-scaled bitmap font maybe?

15:55 <ifreund> dnkl: this happens when using fuzzel on an output rotated 90 degrees, everything else is the same

15:55 <ifreund> and yeah I'm using a bitmap font

15:56 <ifreund> snakedye: I see, yeah that's not possible yet in a way that's easy to bind to a single key

15:56 <dnkl> ifreund: ah, never tried that before

15:57 <dnkl> does it work in sway?

15:57 <ifreund> not sure, I'll check

15:57 <ifreund> dnkl: the font's funky in sway as well

15:58 <dnkl> how about a non-bitmap font?

16:00 <ifreund> the font looks normal with a non-bitmap font but it seems to be incorrectly scaled to 2x

16:00 <ifreund> only happens with 90/270 degree rotation, not with 0 or 180

16:01 <dnkl> hmm... and is that foot in the background? The two _should_ render fonts identically...

16:01 <ifreund> yeah, foot has no issue

16:01 <dnkl> what does fuzzel log on stderr? It should mention the output's properties, including scaling factor

16:02 <ifreund> 0/180: info: wayland.c:1444: HDMI-A-1: 1920x1080+0x0@60Hz ASUS VS238 23.10" scale=1 PPI=96x98 (physical) PPI=96x98 (logical)

16:03 <ifreund> 90/270: info: wayland.c:1444: HDMI-A-1: 1920x1080+0x0@60Hz ASUS VS238 23.10" scale=1 PPI=96x98 (physical) PPI=54x174 (logical)

16:03 <ifreund> looks like the PPI is the only change

16:03 <ifreund> s/PPI/logical PPI/

16:05 <dnkl> the "logical" PPI is derived from the "logical" output dimensions, i.e. the width/height from xdg_output_handle_logical_size()

16:06 <dnkl> and from the actual/physical monitor dimensions

16:06 <dnkl> but I think I see the problem. It doesn't take the rotation into account, so it'll divide the XDG provided width with the phsyial height

16:07 <dnkl> have you changed dpi-aware in foot.ini? Because it _should_ have the same bug for dpi-aware=yes/auto, but probably not for dpi-aware=no

16:09 <ifreund> Nope, I'm using whatever the default is for that: https://0x0.st/-zA3.txt

16:09 <ifreund> fuzzel 1.4.2, foot 1.6.2

16:11 <dnkl> same bitmap font? Normally, bitmap fonts aren't scaled, but if you've enabled 10-scale-bitmap-fonts.conf under /etc/fonts/conf.d, or in some other way enabled scaling of bitmap font(s), that could explain the difference.

16:12 <ifreund> looks like 10-scale-bitmap-fonts.conf is symlinked by default on void

16:12 <ifreund> but yeah same bitmap font with size 10 for both fuzzel and foot

16:13 <dnkl> I'm prepping a POC patch for fuzzel. But I'm still curious why foot behaves differently...

16:17 <dnkl> ifreund: https://0x0.st/-zAG.patch

16:17 <dnkl> completely untested ;)

16:19 <ifreund> I'll give it a whirl :)

16:22 <dnkl> I think I see why foot works and fuzzel doesn't; foot uses the correct definition for PPI (the output's diagonal) when scaling fonts, while fuzzel is broken and only uses the y-axis' PPI.

16:22 <ifreund> dnkl: patch seems to work, thanks

16:23 <dnkl> I.e. foot technically has the same bug, but it's barely noticable on your output since its x- and y-axis have pretty much the same PPI.

16:23 <dnkl> so, I'm going to apply the same patch to foot, and all my other projects, as well as updating all projects to use the correct PPI

16:24 <dnkl> ifreund: thanks for testing :)

16:24 <ifreund> no problem!

16:27 <dnkl> ifreund: do you know if the width and height in wl_output_listener::geometry() are affected by the transform? The documentation seems to suggest they are not.

16:27 <ifreund> dnkl: they aren't afaik

16:28 <ifreund> wlroots sends the physical width/heigh

16:29 <dnkl> ifreund: I was going to say I'm on laptop and can't test this myself.. but realized I could have... but now I don't have to :) thanks

16:30 <ifreund> heh, My new montior stand certainly made testing easier (and let to discovering the bug in the first place

16:31 <ifreund> now I just need a second monitor so I can better debug river issues

16:35 <dnkl> yeah, multiple output brings a whole set of new issues to the table...

16:37 <ifreund> also need to get motivation to improve the UX around it, currently it just does what dwm does for multiple outputs which is kinda painful

16:41 <snakedye> do you plan to add the ability to drag windows from one output to another?

16:46 <ifreund> no

16:46 <ifreund> though it's possible I could be convinced otherwise eventually

16:54 <dnkl> ifreund: fuzzel master has been updated now

17:00 <snakedye> fair, seamless communication between output seems complicated to implement but I think something like an hot edge would be easier to accomplish. ex: pushing a window on a screen edge and it pops on the adjacent output.

17:55 <ifreund> dnkl: nice :)

17:55 <ifreund> snakedye: yeah, I'd be much more likely to accept a solution that doesn't involve rendering a surface on two outputs at once

18:05 <leon-p> well, we really would just need the next river-control to be able to change the output and tags of arbitrary views /atomically/.

18:05 <leon-p> Maybe hold all changes until the client sends "done"

18:05 <leon-p> or why not "riverToplevel.commit" or something like that

18:06 <ifreund> hmm, a commit request for river control would be a good idea yeah

18:07 <leon-p> would require Views to have a third state though which is then copied to pending on commit. But I doubt thats a problem

18:08 <ifreund> either that or a way to represent commands such that they could be queued up

18:09 <ifreund> which would also get rid of that roundtrip issue with my current v2 approach for river-control

18:09 <leon-p> yeah a command queue would probably work better for changing outputs

18:09 <ifreund> it would be much more robust yeah

18:10 <leon-p> I think riverctl should by default then commit directly after adding the command to the queue, but have an option to omit the committing.

18:11 <ifreund> that seems like a reasonable way to expose such functionality with the CLI, though getting the protocol needs to come first

18:12 <ifreund> s/protocol/protocol done/

18:12 <leon-p> I think now might be a good time to have a github issue to collect all the ideas for the protocol

18:13 <leon-p> considering the amount of questions recently that have been answered "not yet, but with river-control-v2"

18:15 <ifreund> I feel like the draft PR is a fine place to dump this stuff

18:15 <ifreund> though if you want to organize it into a big issue with a checklist be my guest

18:16 <leon-p> I am technically not opposed to that, but me being here is basically just procrastinating while I am actually working on math excercises, so I don't actually have the time for that right now :D

18:17 <ifreund> heh, good luck with the math