06:55wlb: wayland/main: Daniel Stone * build: Add -lm to pkg-config dependencies https://gitlab.freedesktop.org/wayland/wayland/commit/02ad102e2d2d src/meson.build
06:55wlb: weston Issue #991 closed \o/ (Odd linker error in Debian Testing https://gitlab.freedesktop.org/wayland/weston/-/issues/991)
06:55wlb: wayland Merge request !452 merged \o/ (build: Add -lm to pkg-config dependencies https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/452)
07:40Ermine: Should i write on xkbcommon stuff here? If so, libxkbcommon-1.8.0 tarball is missing
07:51vyivel: Ermine: that's intentional, see the announcement mail
08:02Ermine: oh, missed that one
08:02Ermine: so I should git clone it?
08:30wlb: wayland Merge request !453 opened by David Redondo (davidre) Make wayland-util.h -Wundef safe when compiled by a C++ compiler https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/453
14:34soreau: I am wondering if there's any reason why libwayland-client can't accept WAYLAND_DISPLAY as a single number without the 'wayland-' prefix. It could potentially save a lot of typing. The idea would be that both e.g. 'wayland-1' and '1' would mean the same thing. Would such a patch be acceptable?
14:36emersion: sounds like this could create some funny situations
14:36emersion: e.g. /run/user/XXX/1 exists
14:37soreau: no
14:37emersion: i don't really see the upside, too
14:37soreau: I mean libwayland-client would interally prefix it
14:37soreau: so it would be wayland-1
14:37soreau: still
14:37emersion: you need to figure out when to prefix
14:37soreau: well yea but leave that to me ;)
14:38soreau: but really, if it's not acceptable, then forget it
14:38emersion: other libs and older libwayland won't be able to parse it, and debugging is harder
14:38emersion: it's a no from me, sorry
14:38soreau: ok
14:38emersion: maybe others have a different opinion
14:39soreau: yea I didn't consider backward compatability, but in that case, either use the full string or upgrade
14:39soreau: but I'm not sure how it would make debugging more difficult
14:40soreau: if anything, for my work flow, it would make it easier, since I'd have to type less :P
14:45soreau: emersion: for the 'when', I was thinking probably check for 'wayland-' and if it's not the prefix, then try with the 'wayland-' prefix
14:52kennylevinsen: soreau: For reference, my own toy compositor does *not* call its socket "wayland-N", and I see no reason to dictate this. It's just a name, can be anything unique.
14:53soreau: kennylevinsen: really? I thought libwayland-server did
14:53soreau: or -client
14:54soreau:greps around
14:54emersion: gamescope uses gamescope-$n
14:54kennylevinsen: client uses the name provided verbatim, `wl_display_add_socket_auto` defaults to making a wayland-N where N is between 0 and 32, but many servers do not use _auto
14:55kennylevinsen: (probably most at this point as I think everybody agreed to explicitly skip wayland-0, the client's hardcoded default)
14:55soreau: well that's a good reason to forget about this scheme I suppose
14:57soreau: maybe for my case (if I wanted it that bad), I probably could write some script or something
14:58kennylevinsen: fast forward to wayfire using `wf-N` :P
14:58soreau: heh
14:59soreau: I don't think there's much reason to change it, I just had this rolling around in my head for a bit and wanted to gague the consensus
15:00davidre: <kennylevinsen> "(probably most at this point..." <- Huh? Mutter and KWin for sure use wayland-0. What is the argument against it?
15:01soreau: gtk
15:01kennylevinsen: libwayland-client's use of it as a default leads to unwanted behavior when WAYLAND_DISPLAY isn't set in the form of finding parent or even adjacent wayland servers it was not explicitly told to use
15:02kennylevinsen: e.g., running a Wayland server on VT 1 and trying to run an X11 session on VT 2
15:02soreau: yea, gtk will start on its decisively chosen server even if you tell it otherwise (because dbus or something)
15:02soreau: if the server is using wayland-0
15:02kennylevinsen: That's related to GApplication though
15:03soreau: just another hysterical raisin :P
15:03davidre: Well the session needs to make sure the activation environemt of the session bus and it's systemd session are correct ofc
15:04soreau: davidre: but WAYLAND_DISPLAY should work even without that
15:04davidre: Yes
15:04davidre: if you set WAYLAND_DISPLAY it works
15:05davidre: but if you don't set WAYLAND_DISPLAY in the dbus environment and an app starts via dbus then ofc it doesnt work
15:05davidre: Or am I misunderstanding?
15:05soreau: I think it's more about multiple display servers running and choosing which
15:05davidre: they should have all their own session
15:05soreau: but details are fuzzy since wlroots defaults to wayland-1+n
15:05davidre: Or are you thinking about nested?
15:06soreau: any multi-display-server situation
15:06kennylevinsen: The WAYLAND_DISPLAY thing is not about dbus - it's about what happens when a server is running somewhere with wayland-0 that the client *wasn't* meant to reach out to
15:06davidre: but how? just running something from a plain tty?
15:07davidre: inside the session of the compositor WAYLAND_DISPLAY will be set to the correct value
15:07davidre: * inside the session of the compositor WAYLAND_DISPLAY will be set to the correct value everywhere
15:07soreau: but it tries wayland-0 first?
15:07soreau: I can't recall the details sadly
15:07davidre: not fi WAYLAND_DISPLAY is set
15:07davidre: * not if WAYLAND_DISPLAY is set
15:08kennylevinsen: Anywhere. You might run a nested Wayland compositor under X11 and suddenly all your apps try to start in that, you might run Wayland on another VT and either X11 or nothing elsewhere, you might run Wayland with Xwayland and want to run an app under X11 rather than Wayland, but it keeps reaching out no matter what you do
15:09kennylevinsen: in general, WAYLAND_DISPLAY is always set whenever a wayland connection is expectd, and the default behavior is therefore never helpful, yet if triggered, possibly confusing and/or outright problematic
15:09kennylevinsen: and servers cannot be expected to use wayland-0, so it's not behavior you can rely on in general either
15:10davidre: the first sounds like an problem, XDG_SESSION_TYPE is a thing
15:10davidre: *app problem
15:11kennylevinsen: XDG_SESSION_TYPE is not a standardized control, and it communicates what session the user logged in to - not what environment the app is running in, in case of e.g. nested servers
15:12kennylevinsen: the problem is libwayland-client having odd historical default behavior, but to not break behavior the wayland-1 approach was taken
15:13kennylevinsen: See https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/486 for the weston change
15:16soreau: I think my problem was different but somehow solved now.. if I had some gtk client running in an X session and then started wayland on tty and run the same gtk app there, it would somehow start in X (with DISPLAY set to Xwayland or otherwise, not the 'real' xserver)
15:16soreau: I think I solved it by not running X anymore xD
15:16kennylevinsen: *That* is likely caused by GApplication, whereby the first instance of the app is a server and each new "start" just reaches out to said server over dbus to open a new window, rather than running a new process
15:17soreau: as an unrelated side note, gtk has officially deprecated x11 support
15:17kennylevinsen: (that, combined with systemd-logind sharing a single session bus across all logins of a single user, leading to no isolation)
15:17soreau: kennylevinsen: sounds about right
15:18soreau: it's always dbus making the magic happen :P
15:18davidre: that's why you run a new dbus session if you start another session on another tty
15:19kennylevinsen: as a hack to solve it, sure
15:21davidre: that's not a hack
15:22emersion: foot does this the correct way by adding WAYLAND_DISPLAY to its socket path
15:31kchibisov: you can also add a pid just in case.
15:32kchibisov: like we have suffixes like -wayland-1-568458.sock, since you may have multiple instances.
15:36emersion: the PID is omitted by design: foot wants a single instance per Wayland compositor
15:37kchibisov: idk, good for testing.
15:37kchibisov: though, you can likely set a socket for it.
15:37kchibisov: like pid doesn't make things worse if you have only use client to connect, like it's not like if you'll end up with with multiple sockets unless you've explicitly asked for it.
15:38kchibisov: and iirc foot has separation between client/daemon thus, I'm not sure you can get a multiple instances unless you've really wanted it, so not allowing sounds strange.
15:40emersion: the socket with WAYLAND_DISPLAY without the PID is used for the daemon
15:40emersion: not sure what you mean
15:44kchibisov: I mean, can you set arbitrary socket for the daemon?
15:46emersion: yes
15:46kchibisov: yeah, so pid just gives an option to not mess with it if you want to test.
15:46kchibisov: since user will unlikely to hit a case where they have more than one instance.
15:46emersion: if you're testing, you can just pass "test" as the socket name
15:46kchibisov: yeah, I'm just saying that having pid changes nothing other than easier development.
17:33MrCooper: davidre: e.g. if you SSH to a machine where the same user has a wayland-0 server running, any GTK app will show up on that wayland-0 server by default (and yes I consider this a GTK issue, doesn't really affect me anymore with waypipe though)
19:58wlb: wayland-protocols Issue #241 opened by Nicolas Fella (nicolasfella) Build error due to 'struct timespec' warning https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/241
20:08ezzieyguywuf: if I have a compositor nested inside another compositor, how can I start a client application and tell it to use the nested server?
20:09wlb: wayland-protocols Merge request !381 opened by Nicolas Fella (nicolasfella) Don't build tests with -Werror https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/381
20:13ezzieyguywuf: ah, WAYLAND_DISPLAY does that, I thought that would specify which display to use
20:13ezzieyguywuf: after launching e.g. sway, is there a way to query from sway which WAYLAND_DISPLAY it is?
20:14emersion: compositors set it in the environment
20:15emersion: "query from sway" usually just means reading environment
20:15ezzieyguywuf: but I'd have to be in the local shell that launched the compositor to get that though, right?
20:15ezzieyguywuf: if I access the machine remotely e.g. via ssh, is there another way to query this from the compositor?
20:15emersion: there might be multiple running compositors
20:15emersion: you need to select one somehow
20:16emersion: WAYLAND_DISPLAY is a way to select a compositor
20:16emersion: if sway is started twice, how would you "query from sway", without any other information to select one of the two?
20:18ezzieyguywuf: emersion: I dunno that's what I'm asking. I can blindly try WAYLAND_DISPLAY=wayland-1, WAYLAND_DISPLAY=wayland-2, but I'd expect there to be a better approach than brute forcing it
20:18emersion: so, you want to connect to any compositor, doesn't matter which?
20:19emersion: there's no reliable way to do this
20:19emersion: (by design)
20:19emersion: a hack would be to look for $XDG_RUNTIME_DIR/wayland-*
20:22ezzieyguywuf: is the first compositor always wayland-1, or is that just a convention?
20:23emersion: sometimes wayland-0, sometimes wayland-1, sometimes something else
20:24emersion: it can be any string
20:24emersion: many other edge cases, e.g. start sway twice, close the first, then you'll get only wayland-2
20:25emersion: the naming scheme is in sway itself
20:44wlb: wayland Merge request !454 opened by Vlad Zahorodnii (zzag) Forward declarate timespec struct https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/454