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/
<anthony25> hey I see more and more some river screenshots on /r/unixporn
<anthony25> that's really cool
maringuu has quit [Ping timeout: 245 seconds]
maringuu has joined #river
leon-p has joined #river
v0idify has joined #river
v0idifyy has quit [Remote host closed the connection]
gspe has joined #river
yyp has joined #river
<novakane[m]> that what I have when I say my screen is messed up https://imgur.com/DvZAyTE
<novakane[m]> I can live without using multiple tty now that the freeze is gone but thad weird tho
<leon-p> are you sure the issue is software?? I have seen similar corruption with bad HDMI cables.
<novakane[m]> yes because if I don't have river I don't have a problem
<novakane[m]> like if I have dwl on tty1 switch to tty2 and back to 1, everything is good
<novakane[m]> but if I do the same thing with river I have this
<leon-p> weird
<novakane[m]> I'm gonna try to remove the wokaround for the freeze to see if it's a coincidence or not
<novakane[m]> Ok it's that. If I remove the workaround everything is good
<ifreund> I bet the proper workaround is to only fail if the output commit failed due to being busy not due to permission being denied as we switched VTs
<ifreund> but wlroots doesn't expose that information, it just returns a binary true/false
<novakane[m]> Yeah because in the log i have commit busy then permission denied in loop
<novakane[m]> I think when you switch it make an infinite loop
<novakane[m]> well I choose this over the freeze but it's weird though
<novakane[m]> and I don't want to make to much test with this because I don't think my screen would like that ^^
<ifreund> I'm reverting the attempted workaround, seems like a more serious bup
<ifreund> *bug
<novakane[m]> I don't know if it happen only to me but yeah it's not an ideal workaround
<novakane[m]> oh wait I forgot I'm on river-layout-unstable-v1 branch so maybe it's because of this
<novakane[m]> maybe the workaround don't work on it
<ifreund> the changes there are completely orthagonal I believe
<ifreund> did you rebase the branch though? I don't think you'd have the workaround there otherwise
<novakane[m]> yeah I just copy paste it
<novakane[m]> maybe I should rebase it
<novakane[m]> I need to add /remove the glibc workaround every time I do something with branch so that's why I just copy/paste it for this
<novakane[m]> I tried with the master branch in case though and I have the same bug
<novakane[m]> It's crazy I just tried like 5 seconds and I have a 10000 lines log file with just permission denied
<ifreund> that's what an infinite loop looks like yeah
<ifreund> which is why I reverted this
<novakane[m]> yeah I know but didn't thought it would be so much line in so little time
<travankor> i was excited to see the output_renderer thing fixed :|
<travankor> but turns out it was false hope
<novakane[m]> Same :(
<ifreund> I think the real fix is either tracking down the issue or retrying only on EBUSY, both of which would be done in the wlroots drm backend
<ifreund> or just implement damage tracking which I plan on doing anyways
<ifreund> i don't know if retrying on EBUSY would actually be correct, but emperically it should work
<novakane[m]> Yeah all of this is above my skills or I would works on damage tracking
<novakane[m]> Even tracking down the issue is hard the log ain't really helpful here for me
<ifreund> novakane[m]: does setting WLR_DRM_NO_ATOMIC=1 change anything?
<novakane[m]> where should I pass it, in the build command?
<ifreund> no, when running river
<ifreund> e.g. WLR_DRM_NO_ATOMIC=1 river
<novakane[m]> ok let me try
<novakane[m]> nope I had a freeze just after lauching it
gspe has quit [Quit: gspe]
yyp has quit [Quit: now it's safe to turn off your computer]
yyp has joined #river
<leon-p> novakane[m]: you said dwl has the same freezing issue, which wlroots version does it use?
<leon-p> maybe this will just disappear when we update to the next version
<novakane[m]> leon-p: main branch use 0.12 now, it was using wlr master branch before, and I had freeze with both
<leon-p> dammit. I was trying to go through it, but there is basically no chance of me debugging that. The low-level graphics stuff isn't exactly trivial to grok if there is no documentation…
<novakane[m]> he changes to wlr 0.12 like mid february, so unless there is a fix in wlr since then, next version probably not gonna fix it
<novakane[m]> yeah there is nothing, that's one of a reason I mainly use river now
yyp has quit [Quit: playin minecraft]
gspe has joined #river
<novakane[m]> I was wondering couldn't river-options and river-control protocols be merged together? mainly the PR river-control v2
<novakane[m]> just by curiosity
<leon-p> sure they could, but what would be the benefit of doing that?
<novakane[m]> like you could use riverctl get-options with all of command for exemple
<ifreund> they may be if it makes sense for whatever atomic transaction thing I work out for river-control-v2
<leon-p> you don't need to merge the protocol for that
<ifreund> if I don't need to merge them though I won't
<novakane[m]> yeah it was a request, just reading them I was wondering why you need to use options for layout for exemple instead of river control
<novakane[m]> wasn't*
yyp has joined #river
yyp has quit [Quit: now it's safe to turn off your computer]
yyp has joined #river
dominikh has joined #river
yi has joined #river
yi has quit [Client Quit]
yyp has quit [Quit: now it's safe to turn off your computer]
gspe has quit [Quit: gspe]
gspe has joined #river
dimenus has joined #river
leon-p has quit [Quit: leaving]
<dimenus> where does River store / load the monitors (outputs) from?
<ifreund> dimenus: Are you talking about default modes and whatnot? Pretty sure wlroots gets that from the kernel
<dimenus> ifreund: apologies. no, i'm talking about the orientation of the outputs
<dimenus> by default, River sees my right monitor as my left one
<ifreund> dimenus: ah, river doesn't persist any of that config across sessions, you probably want to use kanshi or similar
<dimenus> ifreund: i'm actually just looking for how to change it XD.
<dimenus> i'll look through github issues
<ifreund> all river does is implement wlr-output-management and leave things up to clients
<ifreund> wlr-randr is the tool I use for one off output config changes
<dimenus> ah, i didn't realize Kanshi supported something other than Sway
<dimenus> nevermind, i get it now. it's using the standard protocol so it works with any wlr compositor
<dimenus> good to know
<ifreund> well, any compositor that implements wlr-output-management
<dimenus> good point
<ifreund> river didn't support it for a while, you can thank maringuu :)
<dimenus> do you use waybar or something else to display tags?
<ifreund> yeah, I added support to waybar a while back
gspe has quit [Quit: gspe]
<dimenus> ifreund: thanks
dimenus has quit [Quit: WeeChat 3.1]
dimenus has joined #river
dimenus has quit [Quit: WeeChat 3.1]
dimenus has joined #river
<dimenus> i've never used bspwm but i already like the idea of being able to make my own layouts easily