<leon-p>
ifreund: am currently fixing the integer underflow due to substraction in the layer shell implementation.
<leon-p>
what should river do when margin.top + margin.bottom > bound.height?
<leon-p>
because we can demand a new surface size of the client, but not new margins
<leon-p>
since this may also be just a temporary thing, like when outputs are rotated/have a mode change, can we temporarily disable layer surfaces until their next configure?
waleee-cl has quit [Quit: Connection closed for inactivity]
yyp has joined #river
londoed has quit [Quit: Leaving]
waleee-cl has joined #river
skuzzymiglet has joined #river
<leon-p>
also, while I am already in river hacking mood, I'd like to improve the UX of riverctl a bit. Currently it throws error traces at common user mistakes, which I think should be replaced with human friendly error messages.
<leon-p>
apparently all the plumbing is already there in printErrorExit().
<ifreund>
leon-p: nicer error messages sounds good to me
<ifreund>
give me a minute to take a look at the layer shell stuff
<ifreund>
we'd end up sending a width/height of 0 to the client which I think is ok?
<leon-p>
would that not start en endless loop? Client requests too large size, because its margins are huge river calculates 0, sends client configure event with 0, which means client can choose its own size, so client again chooses the way too large size, starting the cycle again
<ifreund>
ah right
<ifreund>
forgot that 0 has special meaning there
<leon-p>
maybe we could just mark layer shell surfaces so that river ignores its margins until the next configure
<ifreund>
looks like sway just closes the layer surface in this case
<ifreund>
which is also not correct
<ifreund>
wayfire also closes them
<leon-p>
certainly better than the compositor crashing.
<ifreund>
agreed
<leon-p>
so let's close the surface, but add a TODO that a better solution is needed in the future
<leon-p>
it is not a case that should be encountered very often anyway
<ifreund>
fine with me
<leon-p>
I'll update the PR then
<ifreund>
cool, thanks for working on this
<ifreund>
I really need to get back to river-options, Should have time tomorrow if I'm productive today
<leon-p>
I am just happy to work on something fun again, after spending the last three weeks learning for a math exam...
<ifreund>
oof, I'm supposed to be studying for a really brain dead "software engineering" exam, which is full java/OOP oriented right now
<ifreund>
also still have a compiler construction exam to take, which should be more fun though it is pure theory of course
<leon-p>
You have the more fun exams I think, mine was the end-boss of analysis and linear algebra
<leon-p>
I definitely prefer term papaers, but barely any professor accepts those as exam-replacement though...
<ifreund>
I already finished all the pure math stuff including analysis and linear algebra, though idk if it was at the same level as your courses :D
<leon-p>
I made the mistake of pushing all the maths stuff back a few semesters, so now I have to do it all at once -_-
<leon-p>
but at least it'll help me if I ever decide to pick up learning OpenGL again.
<leon-p>
I am really liking that technique of inserting a function between the real main and _root to intercept errors and print error messages. You could even wire it up to just return the error on debug builds.
<ifreund>
indeed, just add an if (std.builtin.mode == .Debug)
yyp has quit [Quit: now it's safe to turn off your computer]
<leon-p>
maybe we should add some sort of "please attacth the following error trace to your bug report"-message though.
<ifreund>
hmm, I don't think they would really be that helpful for riverctl tbh
<leon-p>
also is it really right to use std.debug.print?
<leon-p>
in printErrorExit() I mean
<ifreund>
I mean we could use stderr and discard the error manually if you like, I was just being lazy and std.debug.print does exactly that
<leon-p>
I see. If there are no advantages in using stderr directly, let's just leave it as is
<ifreund>
well, std.debug.print uses a mutex and we aren't currently building in --single-threaded mode which would make that mutex a noop
<ifreund>
if you want to copy the printErrorExit() from river/main.zig that's probably an improvement
<leon-p>
ok, I'll do so
<ifreund>
leon-p: CI says printErrorExit() needs to stay pub :P
<leon-p>
yeah, just noticed, I'll fix it in a sec
<leon-p>
also pushed the layer shell fix, btw
<novakane[m]>
well yesterday I asked where the errors was, I should have waited one day ^^
gspe has joined #river
yyp has joined #river
gspe has quit [Quit: gspe]
gspe has joined #river
<novakane[m]>
2 hours without any freeze, that's a record
<novakane[m]>
a 3 lines commits really impove my live :p
<ifreund>
wonderful :)
<leon-p>
Although it should be added that those 3 lines are not really a fix. They are just a workaround. Commiting an output buffer can still fail.
<leon-p>
A nice workaround though.
<novakane[m]>
sure but atleast I can watch a video without having to switch to an other tty every 2 seconds
<leon-p>
yeah, it is definitely an improvement
<ifreund>
I'm impressed by your dedication to using river that you put up with that level of annoyance
<ifreund>
I would've went back to some other wm :D
<ifreund>
would have fixed this sooner but it never affected me for whatever reason
<novakane[m]>
haha yeah well tbh I want to use wayland and I don't like sway tilling so I try river and dwl and both have this problem
<novakane[m]>
you're lucky
<leon-p>
you'd be surprised what people can get used to. I still haven't fixed the issue of one of my computers not havint the right permissions for the graphics cards in about half of the boots.
<novakane[m]>
yeah now Ctrl+Alt+F2 Ctrl+Alt+F1 is like using insert/normal mode on vim for me ^^
<ifreund>
novakane[m]: the other workaround of taking a 1x1 pixel screenshot could have made things a little less painful :D
<ifreund>
honestly I'm pretty sure the need for this workaround is a wlroots bug
<ifreund>
but I'm not familiar enough with the internals of wlr_output to be 100% sure
<leon-p>
well, technically the workaround from the PR is generally nice, even if wlroots did not have those issues.
<ifreund>
seems like it's only an issue if the compositor doesn't implement damage tracking
<novakane[m]>
ifreund: yeah I tried that but my cpu didn't like it :p
<leon-p>
maybe some weird difference between output.frame and output_damage.frame
<novakane[m]>
yep when I tried sway I didn't have this problem, only on river and dwl, so damage tracking could be a good reason
<ifreund>
I think it's just that if you use damage tracking, any damage will cause a new frame to be scheduled
<ifreund>
while if you don't implemented damage tracking, a new frame is never scheduled for some reason
<leon-p>
not sure about that, since AFAIK output_damage.frame fires the same time output.frame fires, so why would damage schedule a frame?
<ifreund>
grep for wlr_output_schedule_frame()
<ifreund>
whenever damage is added it's called
<leon-p>
interesting
<ifreund>
emersion might be able to shed some light here, should wlr_output_commit() failing automatically call wlr_output_schedule_frame()?
<emersion>
hm, no, a failed wlr_output_commit() should do nothing
<leon-p>
we also need to solve why it fails at all, don't we?
<ifreund>
yeah maybe it shouldn't be failing in the first place
<emersion>
but yeah, if you aren't doing anything out of the ordinary, it shouldn't fail