00:14 gitautas: Hi! I wanted to ask for some advice, I'm working on a project that needs to start a very minimal compositor that runs steam big picture and any games that it might launch. There is a minimal X11 window manager called steamcompmgr that does this, but since I killed my only other X11 dependency, I thought I could try targeting wayland for this. Is there anything that exists that I could use with the hope of getting the minimal possible latency? If not - w
00:14 gitautas: worth the effort of implementing my own minimal compositor that would handle this?
00:14 Sachiel: checked gamescope?
00:15 gitautas: Oh!
00:15 gitautas: That's...exactly what I wanted!
00:15 gitautas: Awesome :)
03:45 DemiMarie: daniels: why is QML so inefficient?
08:40 naveenk2: Hi
11:23 ii8: emersion: nice, thanks! I still have to have the aliases in my client anyway I think for the sake of other legacy themes.
13:57 wlb: wayland-protocols Merge request !189 opened by Simon Ser (emersion) xdg-output-unstable-v1: deprecate name and description https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/189 [xdg-output]
14:14 davidre: d_ed: Your are not visivle on irc
14:21 zubzub: is there a case where events can disappear, that is, the server sends out event(s) and the client never sees them? the qbq is that I'm advertizing linux dmabuf formats, I see them going out in the compositor (with WAYLAND_DEBUG), but I never see them coming in on the client... 🤯
14:22 kennylevinsen: zubzub: if the client dies before it gets to read it, or the server fails to flush
14:22 emersion: broken client event loop?
14:22 zubzub: whe weird af thing is that this seems to happen with both gtk & qt, while if I use the weston dmabuf demo client, I *do* see the format events coming in...
14:23 zubzub: all other events also works just fine it seems
14:24 kennylevinsen: Do you see events that follow? What clients do you use for test?
14:25 zubzub: example of gtk4-demo: https://pastebin.com/raw/dsmtkc85
14:26 zubzub: I don't see format events, however it still seems to pick a (valid) format...?
14:29 zubzub: This is what happens on the server side (lots of events missing because they don't go through the generated c lib functions so the debug logger doesn't see them): https://pastebin.com/raw/jUBgDw8Z
14:48 zubzub: https://i.giphy.com/media/iAYupOdWXQy5a4nVGk/giphy.webp
14:50 daniels: zubzub: yeah, that's quite special, as you don't even see zwp_linux_dmabuf_v1@19 get created
14:51 zubzub: hmmmm
14:53 zubzub: I mean, there's the bind call right? should something extra be visible too?
14:57 daniels: ah yes, I see the bind, sorry
14:57 daniels: the only thing I can think of is that it doesn't actually listen to any of the events, and just YOLOs something in
14:58 zubzub: to make it extra weird, it does show up if I run the clients against weston
15:01 zubzub: ancient aliens in my code
15:01 zubzub: only explanation
15:02 ManMower: are some things queued for a different thread that never dispatches?
15:02 zubzub: and it's not even my code, but a very minor modification of wlroots
15:04 zubzub: ManMower: you mean on the server side where it might accidentally run on the wrong thread?
15:05 ManMower: oh, I misunderstood. I thought the server was known to be sending them
15:09 zubzub: on firefox I see the format events coming in o_O
15:31 pq: zubzub, https://lists.freedesktop.org/archives/wayland-devel/2014-April/014121.html has a list of the pitfalls of WAYLAND_DEBUG. I don't think the pitfalls have changed since then, but protocol dumpers exists nowadays.
15:32 pq: a list of protocol dumpers: https://wayland.freedesktop.org/extras.html
15:54 SardemFF7: (FTR, I added the “no hook action is "open" action” to the webhook handler for MRs)
17:13 wlb: wayland-protocols Issue #130 opened by i509VCB (i509VCB) Guidance for designing new protocols https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/130
18:25 bl4ckb0ne: are the logical events from xdg-output used somewhere?
18:26 emersion: in xwayland
18:26 emersion: also in e.g. grim
18:27 emersion: ideally we shouldn't expose it to regular clients
18:27 bl4ckb0ne: with the deprecation of the name and description event in xdg-output-unstable, would it make sense to move the logical stuff somewhere else or merge them in wl_output?
18:28 emersion: not in wl_output
18:29 emersion: i'm not sure where else it would make sense
18:29 bl4ckb0ne: ext-logical-output-v1 :p
18:30 emersion: it's not really ext- material
18:30 bl4ckb0ne: its fine in xdg-output tbh