<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