ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
karenw has quit [Quit: Deep into that darkness peering...]
karenw has joined #wayland
<orowith2os[m]>
I... am really struggling to make libwayland work nicely with C++, in a C++ kinda way.
<orowith2os[m]>
it's unnverving to jam whatever into a void *, and have to cast that where I need to.
karenw has quit [Quit: Deep into that darkness peering...]
feaneron has quit [Ping timeout: 480 seconds]
akimoto has quit [Remote host closed the connection]
<Ermine>
crazy proposal: write a library which implements wayland protocol but in idiomatic way
<Ermine>
(e.g. with s/void*/std::any/)
narodnik has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
if I did that, I might as well just use wayland-rs, I think
<orowith2os[m]>
would rather it use templates/generics than std::any
<Consolatis>
the wire protocol is extremely simple to parse, generating C++ code based on the protocol XMLs seems like the actual challenge
<orowith2os[m]>
it might be doable... though I'd like to have someone with C++ experience guide me, if not do most of the heavy work
<orowith2os[m]>
though, passing std::any to every instance of a void * and checking for nullptr then the type might actually be the best way to handle it
feaneron has joined #wayland
garnacho has joined #wayland
narodnik has joined #wayland
narodnik has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit [Quit: Konversation terminated!]
narodnik has joined #wayland
narodnik has quit [Ping timeout: 480 seconds]
narodnik has joined #wayland
narodnik has quit [Remote host closed the connection]
narodnik has joined #wayland
narodnik has quit [Remote host closed the connection]
narodnik has joined #wayland
narodnik has quit [Remote host closed the connection]
sally has quit []
narodnik has joined #wayland
sally has joined #wayland
narodnik has quit [Remote host closed the connection]
garnacho has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
karenw has joined #wayland
narodnik has joined #wayland
<orowith2os[m]>
ugh, now I wait for the core wayland repo to go to 1.24, and Arch to get it...
<orowith2os[m]>
I need to implement wl_fixes
<orowith2os[m]>
actually, wonder if core can implement wl_fixes itself, how it does shm?
<orowith2os[m]>
if they're just wl_resource_destroys under the hood.
narodnik has quit [Remote host closed the connection]
narodnik has joined #wayland
dcz has joined #wayland
glennk has joined #wayland
Brainium has quit []
karenw has quit [Ping timeout: 480 seconds]
riteo has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
dcz has quit [Quit: Konversation terminated!]
bindu has joined #wayland
bindu_ has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
dcz has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
narodnik2 has joined #wayland
narodnik has quit [Read error: Connection reset by peer]
<orowith2os[m]>
The biggest thing I'd have an issue with, I think, is figuring out what C++ stuff should map to what C stuff, but it shouldn't be TOO bad, I don't think?
<orowith2os[m]>
(I mean that, I, as a human, know what maps, but the generator wouldn't)
<davidre>
server side it also includes strongly typed Resources
<davidre>
instead of one wl_resource
<davidre>
* instead of one generic wl_resource type
glennk has quit [Read error: Connection reset by peer]
glennk has joined #wayland
Calandracas_ has quit [Ping timeout: 480 seconds]
<Consolatis>
note that the whole concept of wl_resource / wl_proxy + *_set_user_data() and so on are libwayland specific implementation details that don't have to be used on a OOP based implementation
<Consolatis>
the wire protocol only knows about object ids and events / requests (later ones expressed in a number following the order of events/requests defined in a protocol xml)
<orowith2os[m]>
Wouldn't I want to support libwayland, even if I do my own oop one without relying on it, in the case of needing to link to EGL or something or other?
<ifreund>
yes, probably
<Consolatis>
if egl needs some specific libwayland arguments to create a window then yes, likely
<orowith2os[m]>
I figured, since I read at some point that wayland-rs also needed to link to it for egl iirc
<orowith2os[m]>
If any of the smithay folks are reading this, they can probably comment on it
<Consolatis>
i think mesa is doing some libwayland things internally, not quite sure what exactly and if its required or not
fmuellner has joined #wayland
Moprius has joined #wayland
dcz has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
nerdopolis has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
iconz has joined #wayland
<orowith2os[m]>
Consolatis looks like it uses it for wsi, and tearing control & stuff
<orowith2os[m]>
I wonder if passing it a foreign top-level handle works?
<orowith2os[m]>
Can you bind a wl-surface you get via xdg-foreign to globals?
<emersion>
that's not what xdg-foreign is for
<orowith2os[m]>
I know, but *can* you?
<emersion>
no
<orowith2os[m]>
I don't see any errors anywhere for that in xdg-foreign
dcz has quit [Read error: No route to host]
<emersion>
zxdg_imported_v2 can only set the parent
<emersion>
nothing else
<emersion>
more generally, two connections sharing the same wl_surface is a recipe for disaster
dcz has joined #wayland
<emersion>
and a single FD can't be shared between two Wayland implementations (e.g. only one connection gets to read, among other things)
<emersion>
one implementation*
<orowith2os[m]>
I see
<orowith2os[m]>
So xdg-foreign, or another protocol, would be needed for wsi to not make any egl users rely on libwayland?
<orowith2os[m]>
(an updated xdg-foreign, to clarify)
<emersion>
"more generally, two connections sharing the same wl_surface is a recipe for disaster"
<emersion>
IOW: i don't think it would work
<emersion>
what you can do is not use the EGL/Vulkan WSI, and write your own
<emersion>
but that's more work than one might think
<emersion>
also, other libraries might take libwayland objects as input
<emersion>
(like libdecor)
___nick___ has joined #wayland
<orowith2os[m]>
Yeah...
<orowith2os[m]>
I know there's some features wayland-rs has that libwayland doesn't (per-client flushing, iirc?) but it would probably be easier to have libwayland implement that than, whatever you'd do without it
<orowith2os[m]>
And wayland-rs can't flush per-client if wrapping libwayland
<emersion>
libwayland-server has wl_client_flush()
<orowith2os[m]>
Oh. Huh. I'll have to go double check what was missing, then.