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/
skuzzymiglet has quit [Remote host closed the connection]
waleee-cl has quit [Quit: Connection closed for inactivity]
maringuu has quit [Read error: Connection reset by peer]
maringuu has joined #river
yyp has joined #river
leon-p has joined #river
leon-p has quit [Quit: leaving]
yyp has quit [Quit: have a great day]
c7s has joined #river
<daurnimator> ifreund: so anything I can do to get river working again?
<ifreund> daurnimator: does sway start for you?
<ifreund> what graphics hardware do you have?
<ifreund> still the same error that you pasted the other day?
<ifreund> oh yeah, proprietary nvidia drivers aren't gonna work
<daurnimator> they did before...
<ifreund> really? are you sure it wasn't falling back to software rendering?
<daurnimator> I guess it might have been? but if so software rendering wasn't bad
<ifreund> noveau should work fine as far as river/wlroots is concerned
<daurnimator> Last time I tried noveau lots of things stopped working
<ifreund> nivida also seems to (finally) be moving towards supporting the APIs wayland needs and literally everyone else has supported since forever
<daurnimator> I'd buy an AMD card if stock existed.
<ifreund> I bought a cheap old one on ebay
<daurnimator> Downgrading to wlroots 0.12 sounds like a better idea :P
<ifreund> wlroots 0.12 doesn't support nivida proprietary drivers either
<ifreund> wlroots never has and never will support them, though they may be usable once nivida supports the required APIs
<daurnimator> well river used to start until when I tried this weekend. It might not be wlroots, though that's likely the only thing that changed
<ifreund> note that wlroots 0.13 isn't backwards compatible, you'll be stuck on an old river commit
<daurnimator> :/ should I just give up on wayland for another couple of years?
<daurnimator> okay I downgraded to wlroots 0.12 and river r577.3c1f1df... how can I confirm its using software rendering? (I'm currently inside of X... let me know if I should open a TTY to get correct results)
<ifreund> simplest might be to look at river's threads in htop
<ifreund> if you see a lot of llvmpipe threads it's software
<daurnimator> I do not.
<daurnimator> and debugging at startup suggests its using nvidia
<ifreund> hmm, I don't really know much about how the X11 backend works tbh, could you check on a tty?
<daurnimator> k, brb
<ifreund> the x11 backend may not need GBM
<ifreund> oh but it does now on wlroots 0.13 due to internal changes
<daurnimator> okay yeah from a tty it failed http://sprunge.us/shg1wp
<ifreund> yep, so I assume the x11 backend used to not require GBM but now does due to the work to move rendering out of the backends and unify code paths/improve abstractions
<ifreund> (this is part of the requirements for pixman and vulkan renderers)
<ifreund> so yeah, your options are to either use noveau, wait for nivida to add support, or use a different card
<ifreund> though actually the pixman software renderer coming in the next wlroots release might be pretty usable
<daurnimator> even crappy cards cost a lot right now
<daurnimator> and if I did use one, I would no longer be able to play games
<daurnimator> so that's a no-go
leon-p has joined #river
<daurnimator> okay yeah; and I just tried nouveau.... nothing seems to work :/
<novakane[m]> maybe you should try with the wlroots master branch, it look like there is a lot of new commits about this
<novakane[m]> at least till there is no breaking change
waleee-cl has joined #river
<ifreund> too late for that :D
<novakane[m]> oops that was fast
snakedye has joined #river
<snakedye> ifreund From what I understood instead of setting a null value to an option you would unset it? Am I correct?
<ifreund> snakedye: what value an option has is irrelevant, you must declare it before creating the handle
<ifreund> rivertile has been updated as well if you're looking for an example
<snakedye> hmm thanks, I'll look into rivertile.
snakedye has quit [Ping timeout: 240 seconds]
ifreund has quit [Quit: WeeChat 3.1]
ifreund has joined #river
<ifreund> leon-p: we can get rid of the advertise_done event if I'm not mistaken, do you see any reason not to do that?
<ifreund> we tell the client how many views are in the layout and send exactly that many advertise_view events
<ifreund> (I'm currently going through the protocol tweaking wording and stuff)
<leon-p> it was never strictly necessary. I just kept it to make writing content aware clients a bit easier.
<leon-p> if you want to remove it, go for it
<ifreund> I think that the part it makes slightly easier is already one of the simplest parts of writing a client
<ifreund> I'm going to delete it
<ifreund> though I guess by the same argument we don't need commit either...
yyp has joined #river
<ifreund> ok I'm going to keep both, the commit is nice to have because it allows us to have a protocol error for too many/too few views pushed, which should make clients a lot easier to debug when they screw that up
<ifreund> and the other one should stay for symmetry
<ifreund> we don't implement protocol errors for too many views yet, but that doesn't have to block merge
<ifreund> I just want to get this in master asap at this point
<leon-p> yeah the protocol certainly could use a few more errors. I remember there being a few areas where errors are implied but not specified. But that can't always be added later, especially since it won't actually change the (intended) functionality.
<leon-p> s/can't/can
<ifreund> I don't actually see any places we can define more errors in the protocol without it being racy
<ifreund> I was just saying that we don't enforce the one error we do have strictly enough in the server implementation
skuzzymiglet has joined #river
<ifreund> oh there is one for "layout already committed"
<ifreund> I'll add that
<leon-p> what about timeout? Currently river just discards the laoyut demand if the client times out and I think that is the right thing to do. But a layout client hanging may be an issue. Should there eventually be a ping event with a pong request, like in the XDG-Shell? Although I don't even know if any compositor other than mutter actually uses xdgshells ping pong.
<ifreund> the timeout is an implementation detail I think, we already say the server can ignore the proposed layout if it chooses
<ifreund> I don't think a ping/pong would really be useful here, if the client is hanging it wont respond and if it's not hanging it'll send us the dimensions before any timeout
yyp_ has joined #river
yyp has quit [Ping timeout: 260 seconds]
yyp_ is now known as yyp
<ifreund> leon-p: alright, pushed the hopefully final round of wording bikeshedding
<ifreund> did you start the updating the C example client yet? if not I might just do that
<leon-p> I started, but I got distracted. I'll be returning home today, so I'll have another 3h on a train and I might do it then.
<ifreund> cool, there's probably other cleanup I can do on the branch. The example init for example
<ifreund> or I could go fix the glibc linking issues upstream...
leon-p has quit [Quit: leaving]
ifreund_ has joined #river
leon-p has joined #river
<leon-p> ifreund: since we are now in bikeshedding mode: there is both "32bit bitfield" and "32-bit bitfield" in the protocol
<ifreund> oh whoops, thansk
jaafarrc has joined #river
<jaafarrc> So, I compiled river again, and, it's being really buggy.
<leon-p> define "really buggy"
<jaafarrc> I start river from my TTY directly, everything seems to work well, but then, the whole compo freezes.
<leon-p> yeah, that's a known issue
<jaafarrc> For real?
<jaafarrc> Is there a fix?
<leon-p> It will probably disappear when damage tracking is imlemented eventually, but we don't exactly know what causes it.
<ifreund> I'm 90% sure it's a bug in the wlroots drm backend
<leon-p> jaafarrc: there is an (abandoned?) PR with a workaround. It has been reverted because it introduces a different bug, but maybe it works for you
<ifreund> it's a pretty bad workaround, I wouldn't recommend it
<jaafarrc> I regret underestimating the README when it said river was experimental.
<jaafarrc> "Aw, c'mon; it can't be that bad!"
<ifreund> well, I have never been able to reproduce that issue on my machine
<ifreund> it seems to be hardware dependant
<leon-p> fwiw it apparently affects other compositors as well, so its not just us
<jaafarrc> Well, I've been using Sway, and this did not happen at all.
<ifreund> it affects all wlroots compositors that don't implement damage tracking
<ifreund> sway has damage tracking, which masks the bug
<jaafarrc> So river doesn't have that yet, right?
<jaafarrc> Btw, river seems to be fine, now.
<jaafarrc> But I'll keep a close eye.
<ifreund> no river doesn't have damage tracking yet
<jaafarrc> Graphical SDL games (like SuperTux, which is what I have) might be too much for river.
<jaafarrc> Because the glitch happens seconds after I start said games.
<ifreund> it's the next large thing on my todo list after the current layout PR is merged (in the next day or so)
<leon-p> another workaround could be running river in cage, but note that there'll be a slight overhead
<jaafarrc> Yup, river is totally fine, regardless if SuperTux is running, I just tested.
<jaafarrc> Strange.
<jaafarrc> I'll keep you guys posted if you notice any other weird stuff.
novakane has joined #river
jaafarrc has quit [Quit: Quit]
novakane has quit [Quit: Connection closed]
leon-p has quit [Quit: leaving]
yyp has quit [Quit: now it's safe to turn off your computer]
yyp has joined #river
yyp has quit [Quit: now it's safe to turn off your computer]
c7s has quit [Ping timeout: 252 seconds]
snakedye has joined #river
<snakedye> ifreund you were right that the content of the option doesn't matter but I'm noticing another bug. Normally if I set an option on an event, it triggers another layout request. If I do this now, the layout generator blocks.
<ifreund> setting an option never directly triggers a layout_demand unless you are setting the layout option
<ifreund> and define "blocks"
<snakedye> I call `parameters_change()` each time I receive an option event https://gitlab.com/snakedye/kile/-/blob/river-layout-unstable-v1/src/client.rs#L265
<snakedye> by block I mean the layout generator becomes unresponsive to anything
<ifreund> sonuds like a bug in your layout generator then
<ifreund> I'd attach gdb and get a backtrace
<snakedye> I might have done something wrong but this part of the code didn't changed and that bug didn't exist until I migrated to river-options-v2.
<ifreund> snakedye: if you paste the WAYLAND_DEBUG log of your client here I'll take a look