ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
gallo has quit [Remote host closed the connection]
Company has quit [Ping timeout: 480 seconds]
Company has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
is there a compile-time version check I can do for wayland protocols, or am I expected to deal with that myself, by either including them or requiring a new enough wayland-protocols and wayland-server?
<orowith2os[m]>
I don't see anything like WL_COMPOSITOR_VERSION in wayland-server-protocol.h
<danieldg>
I suspect the standard pkg-confg version check will work
<orowith2os[m]>
yeah, that's what I have in meson right now, but just wanted to be sure
<danieldg>
the package provides wayland-protocols.pc
<orowith2os[m]>
would be nice to have WL_IFACENAME_VERSION macros so I can be a bit more async with it, but oh well
kts has joined #wayland
psykose has quit [Remote host closed the connection]
psykose has joined #wayland
Moprius has quit [Quit: bye]
Brainium has quit [Quit: Konversation terminated!]
glennk has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
urk
<orowith2os[m]>
I would just use wl_client_post_implementation_error if a client requests a version newer than what we provide, right?
<orowith2os[m]>
disconnect them entirely, since they obviously ran outside their boundaries
nerdopolis has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
kasper93 has quit [Remote host closed the connection]
karenw has joined #wayland
vincejv has quit [Remote host closed the connection]
kasper93 has joined #wayland
vincejv has joined #wayland
crazybyte4 has quit [Quit: Bye]
crazybyte4 has joined #wayland
karenw has quit [Ping timeout: 480 seconds]
karenw has joined #wayland
glennk has joined #wayland
Company has quit [Quit: Leaving]
coldfeet has joined #wayland
<vyivel>
orowith2os[m]: libwayland uses WL_DISPLAY_ERROR_INVALID_OBJECT for that
<pq>
orowith2os[m], libwayland-server does that version check for you already and disconnects the client.
garnacho has joined #wayland
slim has joined #wayland
mclasen has joined #wayland
andyrtr_ has joined #wayland
Net147_ has joined #wayland
Net147 has quit [Read error: Connection reset by peer]
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
karenw has quit [Remote host closed the connection]
<orowith2os[m]>
that is what I want, yeah. Just some compile-time guarantees so I can be sure that the interfaces I'm providing aren't newer than what the libwayland I'm building against provides
<orowith2os[m]>
which, apparently, can cause problems if that ends up being the case
<emersion>
it's effectively the same as a libwayland version check
<orowith2os[m]>
well, I also require C++23, and I don't doubt that somebody is going to patch out that
<orowith2os[m]>
and if they do that, I have reason to believe they won't care what version libwayland is, and will downgrade it to what they have
<orowith2os[m]>
mmmm.... is it valid to pass nullptr to wl_display_destroy()?
yrlf has joined #wayland
<orowith2os[m]>
I'm doing some signal handling, and if it can, that makes it simpler, because I can omit a if (server.display) and just goto destructors in my signal handler
<vyivel>
unfortunately not
<orowith2os[m]>
oh well
<orowith2os[m]>
I'll just do the if check and leave it at that, then
<orowith2os[m]>
the only time I should get there would be in the case of a super early SIGINT
<orowith2os[m]>
hmm... has the idea of a wayland-validation-layer been proposed anywhere?
<orowith2os[m]>
that + Certified Test Clients that make sure things work right
<vyivel>
what would it do?
<orowith2os[m]>
make sure events get sent in the right orders, that the compositor behaves accordingly in response to events, stuff of that sort
<orowith2os[m]>
go through all the available features of a compositor and make sure they all work right, like drm leasing and different buffer formats
<orowith2os[m]>
like the Vulkan validation layers and CTS
<orowith2os[m]>
making sure clients behave properly, and that compositors don't do anything wrong
<vyivel>
haven't seen such a proposal yet personally
<orowith2os[m]>
should I maybe file one in wayland/wayland if I can't find an issue for it?
___nick___ has joined #wayland
kts has joined #wayland
kts has quit []
<zamundaaa[m]>
Oro (any/all): well, the difference between Vulkan and Wayland is that with Vulkan, the driver itself fully trusts the application
<zamundaaa[m]>
Validation layers are there to fill that gap, but when you do illegal things with Wayland you just get a protocol error
kts has joined #wayland
<orowith2os[m]>
what if in the case of a misbehaving compositor?
<orowith2os[m]>
would still be useful, just less so
<llyyr>
rather than a validation layer, it'd make more sense for it to be a test suite to run your compositor against
<orowith2os[m]>
that would work too, I guess
___nick___ has quit []
<orowith2os[m]>
I'd like both, just to be safe
___nick___ has joined #wayland
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
alarumbe has quit [Remote host closed the connection]