11:07 <daurnimator> ifreund: so anything I can do to get river working again?

11:18 <ifreund> daurnimator: does sway start for you?

11:18 <ifreund> what graphics hardware do you have?

11:18 <ifreund> still the same error that you pasted the other day?

11:18 <daurnimator> http://sprunge.us/vAyTs7

11:19 <ifreund> oh yeah, proprietary nvidia drivers aren't gonna work

11:19 <daurnimator> they did before...

11:20 <ifreund> really? are you sure it wasn't falling back to software rendering?

11:20 <daurnimator> I guess it might have been? but if so software rendering wasn't bad

11:20 <ifreund> noveau should work fine as far as river/wlroots is concerned

11:21 <daurnimator> Last time I tried noveau lots of things stopped working

11:21 <ifreund> nivida also seems to (finally) be moving towards supporting the APIs wayland needs and literally everyone else has supported since forever

11:21 <daurnimator> I'd buy an AMD card if stock existed.

11:22 <ifreund> I bought a cheap old one on ebay

11:22 <daurnimator> Downgrading to wlroots 0.12 sounds like a better idea :P

11:23 <ifreund> wlroots 0.12 doesn't support nivida proprietary drivers either

11:23 <ifreund> wlroots never has and never will support them, though they may be usable once nivida supports the required APIs

11:23 <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

11:24 <ifreund> note that wlroots 0.13 isn't backwards compatible, you'll be stuck on an old river commit

11:25 <daurnimator> :/ should I just give up on wayland for another couple of years?

11:27 <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)

11:28 <ifreund> simplest might be to look at river's threads in htop

11:28 <ifreund> if you see a lot of llvmpipe threads it's software

11:29 <daurnimator> I do not.

11:30 <daurnimator> and debugging at startup suggests its using nvidia

11:30 <ifreund> hmm, I don't really know much about how the X11 backend works tbh, could you check on a tty?

11:30 <daurnimator> http://sprunge.us/KdT5lo

11:30 <daurnimator> k, brb

11:30 <ifreund> the x11 backend may not need GBM

11:31 <ifreund> oh but it does now on wlroots 0.13 due to internal changes

11:32 <daurnimator> okay yeah from a tty it failed http://sprunge.us/shg1wp

11:35 <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

11:35 <ifreund> (this is part of the requirements for pixman and vulkan renderers)

11:36 <ifreund> so yeah, your options are to either use noveau, wait for nivida to add support, or use a different card

11:36 <ifreund> though actually the pixman software renderer coming in the next wlroots release might be pretty usable

11:37 <daurnimator> even crappy cards cost a lot right now

11:37 <daurnimator> and if I did use one, I would no longer be able to play games

11:37 <daurnimator> so that's a no-go

12:41 <daurnimator> okay yeah; and I just tried nouveau.... nothing seems to work :/

12:46 <novakane[m]> maybe you should try with the wlroots master branch, it look like there is a lot of new commits about this

12:46 <novakane[m]> at least till there is no breaking change

13:44 <ifreund> too late for that :D

13:45 <novakane[m]> oops that was fast

15:06 <snakedye> ifreund From what I understood instead of setting a null value to an option you would unset it? Am I correct?

15:07 <ifreund> snakedye: what value an option has is irrelevant, you must declare it before creating the handle

15:08 <ifreund> rivertile has been updated as well if you're looking for an example

15:14 <snakedye> hmm thanks, I'll look into rivertile.

16:37 <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?

16:37 <ifreund> we tell the client how many views are in the layout and send exactly that many advertise_view events

16:37 <ifreund> (I'm currently going through the protocol tweaking wording and stuff)

16:38 <leon-p> it was never strictly necessary. I just kept it to make writing content aware clients a bit easier.

16:38 <leon-p> if you want to remove it, go for it

16:49 <ifreund> I think that the part it makes slightly easier is already one of the simplest parts of writing a client

16:49 <ifreund> I'm going to delete it

16:50 <ifreund> though I guess by the same argument we don't need commit either...

17:18 <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

17:18 <ifreund> and the other one should stay for symmetry

17:20 <ifreund> we don't implement protocol errors for too many views yet, but that doesn't have to block merge

17:20 <ifreund> I just want to get this in master asap at this point

17:34 <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.

17:34 <leon-p> s/can't/can

17:41 <ifreund> I don't actually see any places we can define more errors in the protocol without it being racy

17:42 <ifreund> I was just saying that we don't enforce the one error we do have strictly enough in the server implementation

17:43 <ifreund> oh there is one for "layout already committed"

17:43 <ifreund> I'll add that

17:46 <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.

17:48 <ifreund> the timeout is an implementation detail I think, we already say the server can ignore the proposed layout if it chooses

17:51 <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

17:55 <ifreund> leon-p: alright, pushed the hopefully final round of wording bikeshedding

17:56 <ifreund> did you start the updating the C example client yet? if not I might just do that

18:02 <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.

18:03 <ifreund> cool, there's probably other cleanup I can do on the branch. The example init for example

18:04 <ifreund> or I could go fix the glibc linking issues upstream...

18:25 <leon-p> ifreund: since we are now in bikeshedding mode: there is both "32bit bitfield" and "32-bit bitfield" in the protocol

18:27 <ifreund> oh whoops, thansk

19:18 <jaafarrc> So, I compiled river again, and, it's being really buggy.

19:19 <leon-p> define "really buggy"

19:19 <jaafarrc> I start river from my TTY directly, everything seems to work well, but then, the whole compo freezes.

19:20 <leon-p> yeah, that's a known issue

19:20 <jaafarrc> For real?

19:21 <jaafarrc> Is there a fix?

19:21 <ifreund> https://github.com/ifreund/river/issues/153

19:21 <leon-p> It will probably disappear when damage tracking is imlemented eventually, but we don't exactly know what causes it.

19:22 <ifreund> I'm 90% sure it's a bug in the wlroots drm backend

19:22 <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

19:22 <ifreund> it's a pretty bad workaround, I wouldn't recommend it

19:23 <jaafarrc> I regret underestimating the README when it said river was experimental.

19:23 <jaafarrc> "Aw, c'mon; it can't be that bad!"

19:23 <ifreund> well, I have never been able to reproduce that issue on my machine

19:23 <ifreund> it seems to be hardware dependant

19:24 <leon-p> fwiw it apparently affects other compositors as well, so its not just us

19:24 <jaafarrc> Well, I've been using Sway, and this did not happen at all.

19:24 <ifreund> it affects all wlroots compositors that don't implement damage tracking

19:24 <ifreund> sway has damage tracking, which masks the bug

19:27 <jaafarrc> So river doesn't have that yet, right?

19:27 <jaafarrc> Btw, river seems to be fine, now.

19:27 <jaafarrc> But I'll keep a close eye.

19:28 <ifreund> no river doesn't have damage tracking yet

19:28 <jaafarrc> Graphical SDL games (like SuperTux, which is what I have) might be too much for river.

19:28 <jaafarrc> Because the glitch happens seconds after I start said games.

19:28 <ifreund> it's the next large thing on my todo list after the current layout PR is merged (in the next day or so)

19:30 <leon-p> another workaround could be running river in cage, but note that there'll be a slight overhead

19:32 <jaafarrc> Yup, river is totally fine, regardless if SuperTux is running, I just tested.

19:32 <jaafarrc> Strange.

19:32 <jaafarrc> I'll keep you guys posted if you notice any other weird stuff.

23:30 <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.

23:33 <ifreund> setting an option never directly triggers a layout_demand unless you are setting the layout option

23:33 <ifreund> and define "blocks"

23:37 <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

23:38 <snakedye> by block I mean the layout generator becomes unresponsive to anything

23:39 <ifreund> sonuds like a bug in your layout generator then

23:40 <ifreund> I'd attach gdb and get a backtrace

23:43 <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.

23:52 <ifreund> snakedye: if you paste the WAYLAND_DEBUG log of your client here I'll take a look