ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
nerdopolis has joined #wayland
Son_Goku has quit [Remote host closed the connection]
ovf has quit [Remote host closed the connection]
Son_Goku has joined #wayland
rockzx124458 has quit []
ovf has joined #wayland
Psi-Jack has quit [Remote host closed the connection]
karenw has quit [Ping timeout: 480 seconds]
ryanneph has quit [Ping timeout: 480 seconds]
rockzx124458 has joined #wayland
bim9262 has quit [Remote host closed the connection]
overholts has quit [Quit: Ping timeout (120 seconds)]
bim9262 has joined #wayland
Satan has quit [Quit: Ping timeout (120 seconds)]
Satan has joined #wayland
overholts has joined #wayland
Psi-Jack has joined #wayland
karenw has joined #wayland
nerdopolis_ has joined #wayland
nerdopolis is now known as Guest8086
nerdopolis_ is now known as nerdopolis
ryanneph has joined #wayland
Guest8086 has quit [Ping timeout: 480 seconds]
e84a525bc04 has quit [Ping timeout: 480 seconds]
karenw has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
mohit815822635306 has quit [Quit: mohit815822635306]
mohit815822635306 has joined #wayland
kestrel has quit [Ping timeout: 480 seconds]
MrCooper_ has joined #wayland
MrCooper has quit [Ping timeout: 480 seconds]
kestrel has joined #wayland
nerdopolis has joined #wayland
Moprius has quit [Quit: bye]
rgallaispou has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
rgallaispou has joined #wayland
feaneron has joined #wayland
MrCooper_ is now known as MrCooper
MrCooper_ has joined #wayland
MrCooper has quit [Ping timeout: 480 seconds]
mohit815822635306 has quit [Remote host closed the connection]
mohit815822635306 has joined #wayland
glennk has quit [Read error: Connection reset by peer]
tokyo4j has quit [Ping timeout: 480 seconds]
tokyo4j has joined #wayland
glennk has joined #wayland
karenw has joined #wayland
yrlf has quit [Ping timeout: 480 seconds]
yrlf has joined #wayland
<soreau>
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?
MrCooper__ has joined #wayland
kts has joined #wayland
<emersion>
sounds like this could create some funny situations
<emersion>
e.g. /run/user/XXX/1 exists
<soreau>
no
<emersion>
i don't really see the upside, too
<soreau>
I mean libwayland-client would interally prefix it
<soreau>
so it would be wayland-1
<soreau>
still
<emersion>
you need to figure out when to prefix
<soreau>
well yea but leave that to me ;)
<soreau>
but really, if it's not acceptable, then forget it
<emersion>
other libs and older libwayland won't be able to parse it, and debugging is harder
<emersion>
it's a no from me, sorry
<soreau>
ok
<emersion>
maybe others have a different opinion
<soreau>
yea I didn't consider backward compatability, but in that case, either use the full string or upgrade
<soreau>
but I'm not sure how it would make debugging more difficult
<soreau>
if anything, for my work flow, it would make it easier, since I'd have to type less :P
MrCooper_ has quit [Ping timeout: 480 seconds]
MrCooper__ is now known as MrCooper
<soreau>
emersion: for the 'when', I was thinking probably check for 'wayland-' and if it's not the prefix, then try with the 'wayland-' prefix
rgallaispou has quit [Read error: Connection reset by peer]
<kennylevinsen>
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.
<soreau>
kennylevinsen: really? I thought libwayland-server did
<soreau>
or -client
* soreau
greps around
<emersion>
gamescope uses gamescope-$n
<kennylevinsen>
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
<kennylevinsen>
(probably most at this point as I think everybody agreed to explicitly skip wayland-0, the client's hardcoded default)
rgallaispou has joined #wayland
<soreau>
well that's a good reason to forget about this scheme I suppose
<soreau>
maybe for my case (if I wanted it that bad), I probably could write some script or something
<kennylevinsen>
fast forward to wayfire using `wf-N` :P
<soreau>
heh
<soreau>
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
<davidre>
<kennylevinsen> "(probably most at this point..." <- Huh? Mutter and KWin for sure use wayland-0. What is the argument against it?
<soreau>
gtk
<kennylevinsen>
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
<kennylevinsen>
e.g., running a Wayland server on VT 1 and trying to run an X11 session on VT 2
<soreau>
yea, gtk will start on its decisively chosen server even if you tell it otherwise (because dbus or something)
<soreau>
if the server is using wayland-0
<kennylevinsen>
That's related to GApplication though
<davidre>
Well the session needs to make sure the activation environemt of the session bus and it's systemd session are correct ofc
eroc1990 has joined #wayland
<soreau>
davidre: but WAYLAND_DISPLAY should work even without that
<davidre>
Yes
<davidre>
if you set WAYLAND_DISPLAY it works
<davidre>
but if you don't set WAYLAND_DISPLAY in the dbus environment and an app starts via dbus then ofc it doesnt work
<davidre>
Or am I misunderstanding?
<soreau>
I think it's more about multiple display servers running and choosing which
<davidre>
they should have all their own session
<soreau>
but details are fuzzy since wlroots defaults to wayland-1+n
<davidre>
Or are you thinking about nested?
<soreau>
any multi-display-server situation
<kennylevinsen>
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
<davidre>
but how? just running something from a plain tty?
<davidre>
inside the session of the compositor WAYLAND_DISPLAY will be set to the correct value
<davidre>
* inside the session of the compositor WAYLAND_DISPLAY will be set to the correct value everywhere
<soreau>
but it tries wayland-0 first?
<soreau>
I can't recall the details sadly
<davidre>
not fi WAYLAND_DISPLAY is set
<davidre>
* not if WAYLAND_DISPLAY is set
<kennylevinsen>
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
<kennylevinsen>
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
<kennylevinsen>
and servers cannot be expected to use wayland-0, so it's not behavior you can rely on in general either
<davidre>
the first sounds like an problem, XDG_SESSION_TYPE is a thing
<davidre>
*app problem
<kennylevinsen>
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
<kennylevinsen>
the problem is libwayland-client having odd historical default behavior, but to not break behavior the wayland-1 approach was taken
<soreau>
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)
<soreau>
I think I solved it by not running X anymore xD
<kennylevinsen>
*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
<soreau>
as an unrelated side note, gtk has officially deprecated x11 support
<kennylevinsen>
(that, combined with systemd-logind sharing a single session bus across all logins of a single user, leading to no isolation)
<soreau>
kennylevinsen: sounds about right
<soreau>
it's always dbus making the magic happen :P
<davidre>
that's why you run a new dbus session if you start another session on another tty
<kennylevinsen>
as a hack to solve it, sure
<davidre>
that's not a hack
<emersion>
foot does this the correct way by adding WAYLAND_DISPLAY to its socket path
iomari891 has joined #wayland
<kchibisov>
you can also add a pid just in case.
<kchibisov>
like we have suffixes like -wayland-1-568458.sock, since you may have multiple instances.
MrCooper_ has joined #wayland
<emersion>
the PID is omitted by design: foot wants a single instance per Wayland compositor
<kchibisov>
idk, good for testing.
<kchibisov>
though, you can likely set a socket for it.
<kchibisov>
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.
<kchibisov>
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.
MrCooper has quit [Ping timeout: 480 seconds]
<emersion>
the socket with WAYLAND_DISPLAY without the PID is used for the daemon
<emersion>
not sure what you mean
<kchibisov>
I mean, can you set arbitrary socket for the daemon?
<emersion>
yes
<kchibisov>
yeah, so pid just gives an option to not mess with it if you want to test.
<kchibisov>
since user will unlikely to hit a case where they have more than one instance.
<emersion>
if you're testing, you can just pass "test" as the socket name
<kchibisov>
yeah, I'm just saying that having pid changes nothing other than easier development.
nerdopolis has joined #wayland
coldfeet has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
MrCooper__ has joined #wayland
coldfeet has joined #wayland
nerdopolis has joined #wayland
MrCooper_ has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
tzimmermann has quit [Quit: Leaving]
nerdopolis has quit [Ping timeout: 480 seconds]
iomari891 has quit [Quit: WeeChat 4.3.1]
iomari891 has joined #wayland
ryanneph has joined #wayland
MrCooper__ is now known as MrCooper
yshui has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
<MrCooper>
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)
<ezzieyguywuf>
ah, WAYLAND_DISPLAY does that, I thought that would specify which display to use
<ezzieyguywuf>
after launching e.g. sway, is there a way to query from sway which WAYLAND_DISPLAY it is?
<emersion>
compositors set it in the environment
<emersion>
"query from sway" usually just means reading environment
<ezzieyguywuf>
but I'd have to be in the local shell that launched the compositor to get that though, right?
<ezzieyguywuf>
if I access the machine remotely e.g. via ssh, is there another way to query this from the compositor?
<emersion>
there might be multiple running compositors
<emersion>
you need to select one somehow
<emersion>
WAYLAND_DISPLAY is a way to select a compositor
<emersion>
if sway is started twice, how would you "query from sway", without any other information to select one of the two?
fmuellner has quit [Remote host closed the connection]
<ezzieyguywuf>
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
<emersion>
so, you want to connect to any compositor, doesn't matter which?
<emersion>
there's no reliable way to do this
<emersion>
(by design)
<emersion>
a hack would be to look for $XDG_RUNTIME_DIR/wayland-*
<ezzieyguywuf>
is the first compositor always wayland-1, or is that just a convention?
<emersion>
sometimes wayland-0, sometimes wayland-1, sometimes something else
<emersion>
it can be any string
<emersion>
many other edge cases, e.g. start sway twice, close the first, then you'll get only wayland-2