00:08whot: pq: https://gitlab.freedesktop.org/whot/touchmouse - makes our mouse pretend to be a touchscreen. haven't touched it for a while but should still work in theory
00:09whot: pq: if you need something more specific send me an email, that gets more reliably read than the irc backlog :)
03:20orowith2os[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?
03:21orowith2os[m]: I don't see anything like WL_COMPOSITOR_VERSION in wayland-server-protocol.h
03:21danieldg: I suspect the standard pkg-confg version check will work
03:22orowith2os[m]: yeah, that's what I have in meson right now, but just wanted to be sure
03:22danieldg: the package provides wayland-protocols.pc
03:23orowith2os[m]: would be nice to have WL_IFACENAME_VERSION macros so I can be a bit more async with it, but oh well
04:10orowith2os[m]: urk
04:10orowith2os[m]: I would just use wl_client_post_implementation_error if a client requests a version newer than what we provide, right?
04:12orowith2os[m]: disconnect them entirely, since they obviously ran outside their boundaries
08:09vyivel: orowith2os[m]: libwayland uses WL_DISPLAY_ERROR_INVALID_OBJECT for that
08:46pq: orowith2os[m], libwayland-server does that version check for you already and disconnects the client.
14:52orowith2os[m]: pq: didn't know that, neat. okay then.
14:52orowith2os[m]: so I can just strip all version checks, only worry about implementing it
15:33danieldg: you still need to handle clients coming in with lower versions than the latest
15:34orowith2os[m]: does wl_compositor change in any major way from v1 to v6?
15:34orowith2os[m]: I don't see anything on it
15:35orowith2os[m]: I see some more explicit listing of what should be expected to happen in stuff like xdg-popup
15:37danieldg: orowith2os[m]: yes; the changes are in surface - new events, different handling of attach, etc
15:39orowith2os[m]: oh, I think I see it?
15:39orowith2os[m]: so when a wl_surface version bump happens, so does wl_compositor?
15:39orowith2os[m]: so if someone requests a wl_compositor of version 1, they should only see a wl_surface with the initial version capabilities
15:39orowith2os[m]: and if version 2, everything with a SINCE of 2, and so on
15:52danieldg: yes, you can't specify the version number of wl_surface in any way other than binding compositor with a particular version
15:54wlb: wayland Issue #520 closed \o/ (Trying to build wayland gives issues https://gitlab.freedesktop.org/wayland/wayland/-/issues/520)
15:56emersion: orowith2os[m]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/389
15:59orowith2os[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
15:59orowith2os[m]: which, apparently, can cause problems if that ends up being the case
16:00emersion: it's effectively the same as a libwayland version check
16:02orowith2os[m]: well, I also require C++23, and I don't doubt that somebody is going to patch out that
16:02orowith2os[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
16:04orowith2os[m]: mmmm.... is it valid to pass nullptr to wl_display_destroy()?
16:06orowith2os[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
16:08vyivel: unfortunately not
16:15orowith2os[m]: oh well
16:15orowith2os[m]: I'll just do the if check and leave it at that, then
16:15orowith2os[m]: the only time I should get there would be in the case of a super early SIGINT
16:22orowith2os[m]: hmm... has the idea of a wayland-validation-layer been proposed anywhere?
16:24orowith2os[m]: that + Certified Test Clients that make sure things work right
16:26vyivel: what would it do?
16:39orowith2os[m]: make sure events get sent in the right orders, that the compositor behaves accordingly in response to events, stuff of that sort
16:40orowith2os[m]: go through all the available features of a compositor and make sure they all work right, like drm leasing and different buffer formats
16:41orowith2os[m]: like the Vulkan validation layers and CTS
16:43orowith2os[m]: making sure clients behave properly, and that compositors don't do anything wrong
16:46vyivel: haven't seen such a proposal yet personally
16:48orowith2os[m]: should I maybe file one in wayland/wayland if I can't find an issue for it?
17:01zamundaaa[m]: Oro (any/all): well, the difference between Vulkan and Wayland is that with Vulkan, the driver itself fully trusts the application
17:01zamundaaa[m]: Validation layers are there to fill that gap, but when you do illegal things with Wayland you just get a protocol error
17:06orowith2os[m]: what if in the case of a misbehaving compositor?
17:06orowith2os[m]: would still be useful, just less so
17:10llyyr: rather than a validation layer, it'd make more sense for it to be a test suite to run your compositor against
17:32orowith2os[m]: that would work too, I guess
17:33orowith2os[m]: I'd like both, just to be safe
19:21wlb: weston Merge request !1710 opened by gpotter2 (gpotter2) Add snapping mechanism: maximize/unmaximize https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1710
19:33nickdiego[m]: <llyyr> "rather than a validation layer..." <- there is https://github.com/canonical/wlcs
19:33nickdiego[m]: don't know actively developed it is though
20:31orowith2os[m]:sent a code block: https://matrix.org/oftc/media/v1/media/download/AX6USmZDFPMYJhmEF8BUR2YwenkM2RDhi3KSaxgIhmUN8rvj4Pcl4gtZSgSD_YiiNodYiPBeWTfSaEvBILOUWthCeWK7NAJwAG1hdHJpeC5vcmcvSmVSaG51ZUFlVE9IbVdTZWVXZWdpcEhK
20:31orowith2os[m]: hell yeah?