06:18 dviola: soreau: so I tried older mesa, then compiled sway against it with PKG_CONFIG_PATH, no luck
06:18 soreau: you don't need to do that really..
06:19 soreau: since GL API doesn't really change, you can just set LD_LIBRARY_PATH to point sway to the new mesa
06:19 soreau: and in fact, if you didn't set LD_LIBRARY_PATH, it probably uses system mesa
06:19 soreau: check the logs
06:25 dviola: the logs say that it's using my mesa build, but it's still using libglvnd from the system, etc
06:26 dviola: I guess that's ok
06:28 dviola: when doing ldd on the sway binary only libgbm.so.1 points to my mesa build
06:34 dviola: I'll try an older qemu version next, it's apparently not the kernel and not mesa either
06:39 dviola: oldest mesa version I tried: 24.1.7 -- it was working back then
06:53 llyyr: dviola: you don't need to do that, just do meson devenv -C build in your mesa directory and start sway from that shell
06:53 llyyr: it should just automatically use the mesa inside your build folder
06:57 dviola: ok, I'll try that next, thanks
06:59 dviola: a nested sway compositor right?
06:59 llyyr: depends if you can reproduce your bug in a nested compositor I guess? I imagined you'd want to do it in tty
07:00 dviola: right, it's reproducible in both scenarios
07:00 llyyr: I wonder if the parent compositor running under system mesa would affect that but who knows
07:01 dviola: I'll try your suggestions soon enough, thanks
08:02 dviola: tried latest qemu git and 9.0.0, no difference
08:15 dviola: neither does different versions of virglrenderer
08:34 dviola: I'm really out of ideas, will try your mesa suggestion
09:21 wlb: weston Merge request !1641 opened by () gitlab-ci: Add a CI job for building with a C++ compiler https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1641 [Build system]
09:32 dviola: llyyr: I tried your suggestion, it didn't make any difference unfortunately
09:32 dviola: thanks for your help though
09:33 dviola: I guess I will go back to bisecting the kernel since 6.6.x seemed to work
09:34 dviola: but yes, setting up LD_LIBRARY_PATH seems to be enough, no need for the PKG_CONFIG_PATH stuff
09:35 dviola: really nice to learn about that meson devenv
11:20 wlb: weston Merge request !1642 opened by () Draft: pixel-formats: Add P030 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1642
13:03 wlb: wayland Issue #507 opened by () protocol: clarify whether wl_keyboard.key and wl_keyboard.modifiers serials must be the same when corresponding to the same physical action https://gitlab.freedesktop.org/wayland/wayland/-/issues/507
13:32 wlb: weston Merge request !1643 opened by () shared/helpers.h: Migrate helpers.h to libweston https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1643 [Build system], [Core compositor]
17:18 mvlad: kennylevinsen, any chance we could get back (implicit) session activation as an option? Using chvt seems a bit hacky...
17:21 kennylevinsen: mvlad: hmm, there’s some conflicting requirements as it was specifically for Weston where someone wanted to run in the background. Login managers issue a chvt on their own so it’s not *that* hacky, but I definitely didn’t expect this to have this many conflicting cases.
17:22 kennylevinsen: Problem with adding an option to select is that it would be new API, so not 0.9.2 material :/
17:23 kennylevinsen: If 0.9 is too big an issue, the only real option is reverting it in 0.9.2 and trying again later - tbf it seemed like only a single person asked about the feature of staying in the background so probably not a huge deal to revert if we go that way for now
17:26 mvlad: kennylevinsen, oh, no need to revert, whenever you can do a new release. I suppose that's basically (potentially) 1.x?
17:26 kennylevinsen: 0.10, 1.0, potato tomato
17:26 mvlad: ah, yeah :p
17:27 kennylevinsen: But if it’s wrecking havoc everywhere, a revert is an option - but for 0.10 having a nice way to explicitly request activation at the start would be a goal
17:28 kennylevinsen: E.g. by just having an easy way to do a switch_session to self
17:36 mvlad: on my side this depends if yocto/OE picked that version that up or not (idk if they did at this point). Even so, you've already mentioned how to do handle that from the systemd unit. I think we're fine at the moment, and if you do a 0.10 release with an option to do that implicitly would be great.
17:37 kennylevinsen: Sure - and keep me up to date if things go sour :)
17:38 mvlad: will do, thanks kennylevinsen!
22:31 Consolatis: is there anything speaking against using the global id (or "name") for output_enter/leave events in new protocols? E.g. same question as https://gitlab.freedesktop.org/wayland/wayland/-/issues/412
22:32 Consolatis: using wl_output object ids is pretty hacky (e.g. waiting for a bind in the future) and breaks synchronization points in case a client hasn't bound the output global. It also causes the client to receive events on *all* bound object ids of a given wl_output (e.g. shared wayland connection with for example libraries)