<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]
<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]
<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>
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]