ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor - https://github.com/ifreund/river - channel logs: https://freenode.irclog.whitequark.org/river/
<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.
waleee-cl has quit [Quit: Connection closed for inactivity]
hspak has quit [Quit: Ping timeout (120 seconds)]
hspak has joined #river
<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
travankor has joined #river
<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
<edrex> do dwm users just get used to moving individual windows?
<edrex> i guess that's one of the major features of i3/sway, ability to manipulate groups of views in a lot of ways.
<leon-p> yeah we currently fall short in that regard.
<leon-p> Maybe open a feature request or something.
<leon-p> "move all visible views to different output" is a valid usecase
<travankor> Do you guys run into the wlr_output_commit freeze?
<leon-p> Yup.
<leon-p> frequently
<leon-p> that's why I am currently on sway
<travankor> So it's not GPU specific or anything?
<travankor> I'm on wayfire rn
<leon-p> ¯\_(ツ)_/¯ I have some intel integrated chip thingy
<leon-p> (btw, got the river layout PR compiling. Does not actually work yet, but at least it compiles)
<travankor> 👍
<travankor> I'm curious if the wlr_output freeze happens for non-Intel people
<travankor> so amd, nouveau, or panfrost
<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
<leon-p> s/has/does not have/
<travankor> I've seen "Atomic commit failed (pageflip)" on sway and wayfire, but this doesn't freeze their compositors
<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
<travankor> ah, yes that's more correct
<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
<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
travankor has quit [Remote host closed the connection]
travankor has joined #river
<edrex> i've seen something similar with sway early days, but I can't find the issue.
<travankor> pre-wlroots?
<edrex> maybe, around that time
<edrex> but yeah, the pageflip error shows up in sway logs alot (eg when switching VTs) and is usually harmless.
<travankor> it's always been harmless when I started using sway (around 1.0)
<ifreund> I have an amd card and haven't been able to reproduce it yet
<ifreund> I too am curious if the issue might not vanish after implementing damage tracking
leon-p has quit [Quit: leaving]
<ifreund> leon-p: you're right that requiring namespaces to be globally unique would be awkward, but it would probably be better UX
<ifreund> without that you can end up with the same layout client having a different namespace on different outputs
<ifreund> or different clients having the same namespace of course
<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
<ifreund> (and check if the wl.Client is equal if the namespace is the same)
travankor has quit [Remote host closed the connection]
travankor has joined #river
travankor has quit [Ping timeout: 240 seconds]
<ifreund> hmm, wonder if that's a fuzzel bug or river bug https://0x0.st/-zAT.png
snakedye has joined #river
<snakedye> Is there a way to send windows to another output with the current tag configuration?
<ifreund> snakedye: you mean the current tags of the destination output?
<ifreund> not currently, no. Though that will certainly be possible in the future
<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.
<dnkl> ifreund: I never seen that with fuzzel before
<dnkl> Doesn't mean there isn't a problem with fuzzel, of course
<dnkl> Auto-scaled bitmap font maybe?
waleee-cl has joined #river
<ifreund> dnkl: this happens when using fuzzel on an output rotated 90 degrees, everything else is the same
<ifreund> and yeah I'm using a bitmap font
<ifreund> snakedye: I see, yeah that's not possible yet in a way that's easy to bind to a single key
<dnkl> ifreund: ah, never tried that before
<dnkl> does it work in sway?
<ifreund> not sure, I'll check
<ifreund> dnkl: the font's funky in sway as well
<dnkl> how about a non-bitmap font?
<ifreund> the font looks normal with a non-bitmap font but it seems to be incorrectly scaled to 2x
<ifreund> only happens with 90/270 degree rotation, not with 0 or 180
<dnkl> hmm... and is that foot in the background? The two _should_ render fonts identically...
<ifreund> yeah, foot has no issue
<dnkl> what does fuzzel log on stderr? It should mention the output's properties, including scaling factor
<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)
<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)
<ifreund> looks like the PPI is the only change
<ifreund> s/PPI/logical PPI/
<dnkl> the "logical" PPI is derived from the "logical" output dimensions, i.e. the width/height from xdg_output_handle_logical_size()
<dnkl> and from the actual/physical monitor dimensions
<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
<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
<ifreund> Nope, I'm using whatever the default is for that: https://0x0.st/-zA3.txt
<ifreund> fuzzel 1.4.2, foot 1.6.2
<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.
<ifreund> looks like 10-scale-bitmap-fonts.conf is symlinked by default on void
<ifreund> but yeah same bitmap font with size 10 for both fuzzel and foot
<dnkl> I'm prepping a POC patch for fuzzel. But I'm still curious why foot behaves differently...
<dnkl> completely untested ;)
<ifreund> I'll give it a whirl :)
<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.
<ifreund> dnkl: patch seems to work, thanks
<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.
<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
<dnkl> ifreund: thanks for testing :)
<ifreund> no problem!
<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.
<ifreund> dnkl: they aren't afaik
<ifreund> wlroots sends the physical width/heigh
<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
<ifreund> heh, My new montior stand certainly made testing easier (and let to discovering the bug in the first place
<ifreund> now I just need a second monitor so I can better debug river issues
travankor has joined #river
<dnkl> yeah, multiple output brings a whole set of new issues to the table...
<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
<snakedye> do you plan to add the ability to drag windows from one output to another?
<ifreund> no
<ifreund> though it's possible I could be convinced otherwise eventually
travankor has quit [Remote host closed the connection]
<dnkl> ifreund: fuzzel master has been updated now
<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.
leon-p has joined #river
<ifreund> dnkl: nice :)
<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
<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/.
<leon-p> Maybe hold all changes until the client sends "done"
<leon-p> or why not "riverToplevel.commit" or something like that
<ifreund> hmm, a commit request for river control would be a good idea yeah
<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
<ifreund> either that or a way to represent commands such that they could be queued up
<ifreund> which would also get rid of that roundtrip issue with my current v2 approach for river-control
<leon-p> yeah a command queue would probably work better for changing outputs
<ifreund> it would be much more robust yeah
<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.
<ifreund> that seems like a reasonable way to expose such functionality with the CLI, though getting the protocol needs to come first
<ifreund> s/protocol/protocol done/
<leon-p> I think now might be a good time to have a github issue to collect all the ideas for the protocol
<leon-p> considering the amount of questions recently that have been answered "not yet, but with river-control-v2"
<ifreund> I feel like the draft PR is a fine place to dump this stuff
<ifreund> though if you want to organize it into a big issue with a checklist be my guest
<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
<ifreund> heh, good luck with the math
* ifreund lazily pastes a log of this discussion as a comment on the PR
snakedye has quit [Quit: Connection closed]
snakedye has joined #river
snakedye has quit [Ping timeout: 248 seconds]
waleee-cl has quit [Read error: Connection reset by peer]
waleee-cl has joined #river
jjanzic has joined #river