ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
sally has quit [Quit: sally]
Flat_ has joined #wayland
slattann has joined #wayland
Flat has quit [Ping timeout: 480 seconds]
Plasm0duck has quit [Quit: Konversation terminated!]
Plasm0duck has joined #wayland
sally has joined #wayland
slattann has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
garnacho has joined #wayland
exxxxkc has quit [Remote host closed the connection]
<riteo>
Hi people, I'm in the process of adding "game embedding" to godot on wayland, which needs to hijack the running game's surface and slap it into the main editor window
<riteo>
from what I can tell I need to implement a mini compositor inside the editor and run the game through it
<riteo>
the question is, should I use wlroots for this? Is there a known path from there or should I figure out things as I go?
<riteo>
there's actually another very dumb idea I had which is to make a protocol proxy that intercepted new_id arguments and remapped them on-the-fly, all while running from the same connection of the editor
<riteo>
and then intercepting xdg-toplevel messages and "translating" them to subsurfaces
leon-anavi has quit [Quit: Leaving]
<riteo>
but I guess that the proper approach would be to implement a real compositor with some library, wouldn't it?
pavlushka has quit [Ping timeout: 480 seconds]
<kchibisov>
is it an arbitrary game? Generally one could just support subsurface or toplevel as main surface.
<kchibisov>
and when you embed you ask to draw on subsurface.
<kchibisov>
where toplevel and subsurface both wrapped.
<riteo>
they are arbitrary games yes, but they are guaranteed to run on godot engine, since it is a "preview" of the project you're modifying
<kchibisov>
I mean, then they are not arbitrary.
<kchibisov>
it's whatever you've created with godot.
<riteo>
yes
<riteo>
that's what I meant sorry
<kchibisov>
thus, you can just have enum { subsurface, toplevel } and pass an option when you embed.
<riteo>
thing is, how should I go forwards implementing this?
<kchibisov>
I mean, you have xdg_toplevel somewhere and drawing, you should wrap?
<zamundaaa[m]>
riteo: does the game run in the same process, or in a different one in this case?
<emersion>
riteo: wlroots has an "embedded" exemple fwiw
<kchibisov>
Like the end handle that will be passed to the graphics API will be the same.
<riteo>
zamundaaa: it's a different process
<emersion>
example*
<kchibisov>
ah, different process, then yeah, won't work.
<zamundaaa[m]>
Then you need to implement that nested compositor, no way around it
<riteo>
emersion: oh I missed that, it would help me considerably
<riteo>
zamundaaa: would proxying the protocol be too dumb of an approach?
<riteo>
I actually was playing around with the idea but it feels wrong while I wrote it
<zamundaaa[m]>
I think you'd just end up with a less reliable nested compositor if you do that
<zamundaaa[m]>
As the game may try to use protocols that only apply to xdg toplevels on the subsurface, and then get a protocol error for it
<emersion>
it uses a subsurface so that all interactions with the parent compositor are managed by wlroots - it's also possible to render to a buffer and then paint it yourself, but it's more work
<kchibisov>
I think it'll be fine actually?
<kchibisov>
The proxy approach.
<riteo>
I did not do any remapping but I could make a very dumb proxy in very little time and it seems to work surprisingly well, as long as it does not get protocol errors and put everything down :P
<kchibisov>
it works good for xwayland at least.
<riteo>
but yea I'm definitely gonna take a look at the embedded example anyways, thank you emersion :D
<kchibisov>
so don't see why proxing another game won't be good.
<riteo>
kchibisov: well xwayland stuff I think would need special treatment anyways
<riteo>
as in, I don't think I can intercept it
<kchibisov>
there's a wayland proxy to proxy xwayland.
<riteo>
uh
<kchibisov>
so you can have xwayland outside of compositor.
<riteo>
I must admit, the whole reason I even thought of the proxy setup is that making a whole compositor sounds like a chore
<kchibisov>
I mean, if wlroots has a good API then probably will be fine.
<riteo>
but my rational part says that I should probably just really just bite the bullet
<riteo>
yea it has, looking at tinywl
<riteo>
it does _everything_ for you already
<riteo>
I just have to wire up some event handlers I think, and there's already an "embedded" example
<kchibisov>
but for this case, you need to hijack things a bit, which you know how they work.
<kchibisov>
since you embed only godot games.
<riteo>
sorry for the proxy case or the wlroots case
<riteo>
ok I'm sold, the embedded example i 244 lines long
<riteo>
biting the bullet it is
<kchibisov>
I mean, you pull entire compositor lib.
<kennylevinsen>
does Godot games use subsurfaces or just a single toplevel surface that is pre-composited?
<riteo>
kennylevinsen: they don't use subsurfaces
<kchibisov>
it's just a single surface, which is easy to proxy, from what I understood.
<riteo>
is the proxy solution really that viable
<riteo>
I mean I don't see why subsurfaces wouldn't be easy to proxy
<riteo>
I can just filter in-out interface I need to know about anyways to parse their signatures
<kennylevinsen>
then you just need to get a hold of the buffer - if you can integrate with the game you're previewing's Godot implementation, you could just have it send the buffer on whatever side channel you want
<riteo>
I mean I have a working simple proxy which does not do any remapping/embedding yet
<riteo>
kennylevinsen: yea but what about input and stuff?
<kchibisov>
just pass through.
<riteo>
I should've specified that other platforms cheat by teleporting the child window into the designated space
<riteo>
so there's no input passing mechanism already implemented
<kchibisov>
they are all in surface coords.
<kennylevinsen>
do you also want all input routed through the preview window? or is it fine that it is the game's main window for that?
<riteo>
I also need all input routed through there
<riteo>
it's basically like unity's game preview
<riteo>
where the game itself is spawned into a "preview" subwindow in the editor
<kennylevinsen>
so you don't expect there to be a "real" window, you only want the preview?
<riteo>
yes
<riteo>
that's why the proxy approach seems so alluring
<riteo>
I'm sorry if this became somewhat of a "please convince me that a proxy is a bad idea", there's very little previous art in regarding to wayland embedding compositors
<kchibisov>
cosmic-panel iirc
<kchibisov>
or was it something else, it's some cosmic element that does embedding iirc.
<kennylevinsen>
your options are: custom separate Godot backend (no Wayland), embedded compositor, or a stripped down embedded compositor that proxies a few things
<kennylevinsen>
the last one is a bit funky as you need to re-advertise globals, translate input coordinates, etc.
<riteo>
wait why do I have to translate input coordinates
<riteo>
it's all per-surface
<kennylevinsen>
hmm maybe it's fine if you use a subsurface
<kennylevinsen>
but you can't make a new display connection
<riteo>
that's the only bad thing with proxying I think
<riteo>
as if there's a protocol error from the game it all goes down
<riteo>
that's why I'm really 50/50 with option no.2 and option no.3
<kennylevinsen>
so you need to act as a Wayland server that implements all the relevant interfaces as calls to your own display connection
<riteo>
well I guess that's really proxying with more steps though, isn't it
<kennylevinsen>
and you'll have to mimick some xdg-shell stuff
<kennylevinsen>
yeah
<riteo>
so it's really either "make a whole compositor and blit the thing out" or "proxy everything and trust the client"...
<riteo>
I think there's no way around it
<riteo>
welp, the wlroots example opened another path, which is reassuring at least
<kennylevinsen>
well you can't proxy it directly - you don't have access to the connection buffer, and even if you did you'd have object ID collisions, and you want an xdg toplevel to become a subsurface
<riteo>
well yea I can remap ids
<kennylevinsen>
so it's "make a whole compositor" or "make a gutted compositor" - can't really say if 2 is easier
<riteo>
I actually have a broken prototype that parses the message signature from the generated headers, finds the `n` argument and then can do stuff with it
<riteo>
the plan is to make a wl_proxy from the editor in response to a proxied new id and then switch to its id instead
<riteo>
maybe i'm really making an extremely low level gutted compositor
<riteo>
i'm literally playing with the wire here
<kchibisov>
I mean, you need to write a proxy compositor.
<kchibisov>
and not e.g. directly deal with wire.
<riteo>
why not?
<kchibisov>
well, you can, but probably more error prone.
<riteo>
i'm doing wayland<->wayland stuff
<riteo>
the proxy interfaces would ideally do the same identical thing than relaying the wire format
<kchibisov>
yeah, but proxy compositor just means that you use wayland server and communicate forward with client api.
<riteo>
yes but that's a real chore
<riteo>
at that point I'd rather go with a full wlroots compositor, which does everything for me
<kchibisov>
you'd still need to hijack the toplevel.
<riteo>
well yea
<kchibisov>
to the point where you resize itc, etc.
<riteo>
I can't see why I can't do that with the wire either
<kchibisov>
I mean, wayland-server means that you parse the wire.
<kchibisov>
Though, I guess you need a custom parser.
<riteo>
I tried using wayland-server but unfortunately it did not give enough info
<riteo>
Anyways, thank you everybody for all the knowledge! You were lightning fast as usual to respond :DDDDD
pavlushka has joined #wayland
<riteo>
I'll definitely keep the wlroots embedded example in mind, that's undeniably the most bullet-proof solution.
<riteo>
... I can't stop wondering about the proxy approach though, it's terribly alluring.
<kchibisov>
people tried to load balance with proxies in wayland.
<kchibisov>
and iirc kennylevinsen has a debugger in go that introspects the wire.
<riteo>
I'm actually a bit confused on why the firefox folks chose to do the proxy thing
<riteo>
as in, why not do everything on another thread?
<riteo>
There's surely an architectural reason behind, no judgment obviously, just curiosity
<riteo>
the wire is extremely easy to parse BTW
<riteo>
especially when you're looking for a single thing
<riteo>
I think waypipe did a similar thing
<kchibisov>
just don't get cursor while at it.
<kchibisov>
though, maybe you don't create it in godot.
<riteo>
I'm sorry I having trouble parsing the phrase
<riteo>
get cursor as in wl_cursor?
<kchibisov>
wl_surface for cursor.
<riteo>
why not?
<riteo>
the hijacked surface is still a different surface, isn't it?
<kchibisov>
Yeah, but you need to hijack the right one.
<riteo>
tbh I've never worked with subsurfaces, maybe I'm missing something very important
<riteo>
kchibisov: well I think that's easy though, isn't it?
<kchibisov>
yeah, should be easy to track.
<kchibisov>
it'll be passed in set_cursor.
<kchibisov>
just need to track that.
<riteo>
or I could track directly get_xdg_surface and get_xdg_toplevel
<riteo>
and ignore everything else
<kchibisov>
yeah, that as well.
<riteo>
all right, fair :D
<kchibisov>
then you'd need to hijack `attach` and change to which surface you attach.
<riteo>
yea doesn't sound too hard either
<riteo>
it's the most cursed thing I ever thought
<riteo>
If the proxy works I'll feel forever dirty
<riteo>
lol
<kchibisov>
And not forward toplevel stuff up, only reply back.
<riteo>
yeah you can actually skip packets quite fine
<kchibisov>
some xdg_toplevel requests mandate a reply.
<riteo>
like, I tried skipping global events for interfaces I don't have signatures for
<riteo>
and it just worked
<colinmarc>
<
<riteo>
oh right
<kchibisov>
but it shouldn't be that hard.
<riteo>
yeah it's been surprisingly easy to do simple proxying and snooping with some hacked-up c code
<riteo>
I'm not even using any fancy library (godot has its own stuff so I'm keeping things terribly dumb)
<riteo>
the protocol is /clean/
<riteo>
there's also a whole elegance to it, don't you think? The only reason I can proxy so much stuff is that basically everything is surface-local
<riteo>
so all it takes is to swap ids and emulate a single interface, I think
<riteo>
welp, time to keep going ig, armed now with my wlroots parachute for when stuff gets serious
<kennylevinsen>
re: Firefox, they don't control their Wayland display connection - gtk3 does
<kennylevinsen>
which increases complexity quite a bit - but with dynamic connection buffers on the server side the need for their proxy hack is minimized
<riteo>
ohhh all right that explains everything
<riteo>
ty
FreeFull has joined #wayland
<kennylevinsen>
they also have a lot of stuff that gets sent to the main thread for some reason, but it's been a while since I've been down there - it's also a lot easier to point out flaws than it is to fix them, so won't throw too much shade over it
<riteo>
that's perfectly fair yeah
<riteo>
as I said before, no judging, platform stuff is tricky every single time
<kennylevinsen>
btw if you keep going the proxy route, you could consider having your proxy expose a godot specific she'll protocol to make things easier with less xdg mimicry and such
<kennylevinsen>
could also be used as general side channel comms
<riteo>
that's a really nice idea
<kennylevinsen>
... shell you dumb phone
<riteo>
lol
<riteo>
We'll see how it goes ig
<riteo>
I'm here in the first place following the path of least resistance after all ;)
<riteo>
I'm unfortuntately a really-hard headed sometimes and my curiosity is too strong to not keep going anyways
<kennylevinsen>
it's fine, as long as you're okay occasionally discovering dead ends :)
<riteo>
ye I'm ok with that :D
pavlushka has quit [Ping timeout: 480 seconds]
funderscore is now known as Guest9651
Guest9651 is now known as funderscore
rasterman has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
CME has quit []
CME has joined #wayland
sima has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
Flat_ has quit [Quit: Rip internet]
Flat has joined #wayland
nerdopolis has joined #wayland
rasterman has joined #wayland
avu has quit [Quit: avu]
avu has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
tlwoerner has quit [Ping timeout: 480 seconds]
<DemiMarie>
Is a nested rootless compositor generally considered feasible to implement? I’m not aware of any implementations but it would be nice to know.
<emersion>
waypipe is such a compositor
<DemiMarie>
How big is the performance hit compared to a protocol-level proxy?
<emersion>
oh, waypipe is a proxy of sorts
<DemiMarie>
I know you take a hit from the extra blits and I know that is bad when one is pushing a system to its limits, but most users don’t push a system to its limits
<emersion>
you don't need to blit
<emersion>
gamescope doesn't blit, for instance
<DemiMarie>
what about subsurfaces & damage?
<emersion>
these can be forwarded as sub-surfaces to the parent compositor
<DemiMarie>
how complex is it to keep all of the coordinates in sync?