01:03 <snakedye> Yeah pretty much

04:28 <ifreund> almost finished working through the bugs valgrind has been kind enough to inform me of, last actually UB one is this ttps://0x0.st/-9qS.txt

04:28 <ifreund> which only happens once on startup

04:29 <ifreund> I really wish valgrind could tell me exactly which values were uninitialized

04:33 <ifreund> hrm, running valgrind on sway gives the same output on this machine

04:33 <ifreund> must be wlroots or something lower in the graphics stack

04:33 <ifreund> time to fix the leaks

05:16 <ifreund> man, none of the leaks seem to be river's fault either :/

05:17 <ifreund> maybe some are, will have to look more closely when I have the time

08:04 <novakane> hmm I have a lot of `> Internal error: Could not resolve keysym XF86BrightnessAuto` in river log now

08:05 <novakane> not like it cause bug but it writes hundreds of lines which is a bit annoying

08:06 <novakane> I think that all the keys I dont have on my keyboard

10:25 <leon-p> ifreund: ot may actually be libwayland fualt. I have a 40 bit leak in LavaLauncher I could never track down that definitely does not come from my code

10:25 <leon-p> s/fualt/fault

10:33 <leon-p> btw, direct scanout does work with mpv. I only have to fix some damage related bugs when entering / exiting fullscreen and that PR is ready

10:35 <novakane> leon-p: what is direct scanout?

10:37 <leon-p> novakane: it's a way to avoid compositing for fullscreen views. Currently river still copies a fullscreen views buffer to a compositing buffer and then attaches that to the output. But in some (rather rare) cases, this step can be skipped and a views buffer attached directly to the output

10:38 <novakane> oh nice, interesting thanks

10:40 <leon-p> note that most clients will not be able to tak advantage of this. For example if they render using a format the output does not support, there has to be compositing. But certain advanced clients, like mpv, can make their buffer viable for direct scanout, which makes displaying them fullscreen a little bit more efficient

10:41 <leon-p> after that I'll probably look at presentation time, since apparently mpv needs that as well for good video playback

10:43 <novakane> well I think I only use mpv in fullscreen

10:44 <leon-p> novakane: btw, I saw in your dotfiles repo a lot of interesting mpv lua scripts. Gave me a lot to play with :D

10:48 <novakane> haha yeah, didn't modified my mpv config since a long time, the setup is good, and with youtube-dl I can play youtube or twitch too, it's cool

10:48 <novakane> a bit ressource friendly than using firefox

11:00 <leon-p> "connector HDMI-A-1: Atomic commit failed (pageflip): Device or resource busy"

11:00 <leon-p> wasn't that what caused our freezes?

11:01 <leon-p> I am hitting it with direct scanout

11:01 <novakane> yep

11:11 <leon-p> sofar I have flickering in mpv and freezing in all other fullscreen views. Probably missed a condition

11:23 <novakane> is it not a problem with damage tracking?

11:28 <novakane> oh they talks about direct scanout in wlr_presentation_time.h

11:28 <novakane> maybe you already needs that

11:29 <novakane> leon-p: ^

11:31 <leon-p> novakane: direct scanout ignores damage tracking

11:35 <novakane> oh ok

11:47 <novakane> leon-p: need some fix but it's a starting point if you want wlr_prentation_time.h bind https://0x0.st/-9cP.patch

19:49 <leon-p> novakane: thanks, I'll have a look later