11:11 <dottedmag> What's the semantics of "good frame" in wl_surface::frame "Request a notification when it is a good time to start drawing a new frame"? Should the compositor send the event as early as possible after flip, or as late as possible? How does compositor know how much time a client needs to draw its frame?

11:12 <dottedmag> *"good time"

11:19 <kennylevinsen> Compositor defined

11:20 <kennylevinsen> After flip, delayed from flip, entirely disconnected, throttled, all are options

11:20 <dottedmag> Interesting, thanks.

11:20 <kennylevinsen> If you write general GUI applications you're supposed to not care and just use it, while very sensitive stuff use presentation feedback

11:28 <dottedmag> Hah. I wonder what "nanoseconds till next refresh" in wp_presentation_feedback::present means on VRR displays. 0?

11:29 <dottedmag> Oh, nevermind, it's in the next sentence: "If the output does not have a constant refresh rate, explicit video mode switches excluded, then the refresh argument must be zero"

11:54 <wlb> wayland Issue #86 closed \o/ (Race with destroying of wayland object https://gitlab.freedesktop.org/wayland/wayland/-/issues/86)

11:55 <wlb> wayland/main: Derek Foreman * client: Refactor wl_proxy_destroy critical section https://gitlab.freedesktop.org/wayland/wayland/commit/942f1d88431d src/wayland-client.c

11:55 <wlb> wayland/main: Derek Foreman * client: Add new proxy marshalling functions with flags https://gitlab.freedesktop.org/wayland/wayland/commit/23e4a7060080 src/ wayland-client-core.h wayland-client.c

11:55 <wlb> wayland/main: Derek Foreman * scanner: Use the new atomic marshal/destroy function https://gitlab.freedesktop.org/wayland/wayland/commit/0e0274af0c9f src/scanner.c tests/data/example-client.h tests/data/small-client-core.h tests/data/small-client.h

11:55 <wlb> wayland Merge request !162 merged \o/ (Fix race condition when destroying proxies https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/162)

14:13 <vv221> Currently running a X server, I’m once again wondering if switching to Wayland could be a good idea. But my current custom-made environment is defined by a ~/.xinitrc file, and I could not find the alternative for that on Wayland side.

14:13 <vv221> I guess it would depend on my compositor of choice?

14:33 <soreau> you can write a wrapper script to set environment before executing a wayland compositor

15:04 <vv221> soreau, this is only about environment variables, not running applications?

15:04 <vv221> My .xinitrc is not only used to set up some env variables, it includes running some desktop applets, a keybord shortcuts daemon, etc.

15:05 <soreau> vv221: right, usually the compositor is responsible for triggering app startup

15:05 <vv221> It might be clearer with the actual file as an example: https://paste.debian.net/plain/1206891

15:06 <vv221> OK, so it would be split into two parts, one for setting the environment, called *before* the compositor, and the application autostars would be handled by the compositor itself?

15:06 <vv221> *the applications autostart

15:41 <soreau> vv221: yes

15:43 <soreau> the difference is that in X, where you can specify the display number when starting it, wayland compositors using libwayland get WAYLAND_DISPLAY picked for them, so there's no way of knowing up front

15:54 <LaserEyess> another viable option, though slightly more complicated, is to use systemd user services if your distro supports systemd

15:55 <LaserEyess> both gnome and KDE have targets where you can do WantedBy=graphical-session.target (or whatever equivalent) and they'll start

15:55 <LaserEyess> environment is not managed that way though, you'd need to handle that yourself

15:59 <vv221> I kind of like the systemd approach, if it can work despite not using a graphical session manager.

16:00 <vv221> (the current way to start my desktop environment is with startx)

16:01 <LaserEyess> well, startx does not exist on wayland, as explained above

16:02 <vv221> I know, that’s why I’m asking for pointer on how to emulate its behaviour with Wayland ;)

16:02 <LaserEyess> I know GNOME, and maybe KDE, have some hooks to pass some env stuff to systemd when it starts the user service manager

16:02 <LaserEyess> and yes the systemd approach can work without a login manager

16:03 <LaserEyess> you need to use a wrapper script to do something like `systmed --user start graphical-session.target`

16:03 <vv221> OK, I think I get it.

16:05 <vv221> It might actually be smarter for me to start by replacing my startx + xinitrc with systemd user services, then only after that I would try to replace X-specific services with new Wayland ones.

16:06 <vv221> So I don’t get messing up with two migrations at once.