08:58 pq: swick[m], indeed, ST 2086 metadata is very much specific to the PQ system. We'd have to generalize that somehow, or impose the PQ-only constraint.
09:30 emersion: pq, I don't think I understand your comment
09:31 emersion: why does the old API need to work when the compositor opts in with the new API?
09:34 pq: emersion, I'm talking from library ABI stand-point, not from a single library user stand-point.
09:34 emersion: hm, yes?
09:34 pq: there may and will be other library users that still do use the old ABI
09:34 emersion: sure
09:35 emersion: they continue to work fine>
09:35 emersion: ?
09:35 pq: this all depends on what your actual goal is
09:35 pq: no, they won't work fine on FreeBSD, if FreeBSD drops the implementation of the old ABI.
09:36 pq: whether your goal is to only let the old ABI be unused, or to actually drop its implementation, that's up to you.
09:36 pq: my comment only applied to the goal of dropping the implementation, as that other commenter alluded to
09:37 emersion: hm, so you're saying we can't ever build-time disable the old ABI if we offer libwayland-server.so?
09:37 pq: correct - if following the library stable ABI rules
09:38 pq: another benefit of a new library would be that it would be impossible for a user to call functions that won't work anymore after opting in to the smaller ABI
09:38 emersion: right
09:39 emersion: a new library sounds like too much work tbh
09:39 pq: and that distributions can trivially see if they need the old big ABI to work for any particular program
09:39 pq: sure, that may be
09:39 emersion: easier to just re-implement libwayland in wlroots even
09:40 pq: that's your choice
09:40 pq: if you can live with that, go for it
09:41 pq: I do also see merits with not dropping the event loop ABI and just allowing it to become unused.
09:41 pq: and that goal I believe was in your mind, right?
09:41 emersion: i was planning to just add a build-time switch and #define to disable the event loop API
09:42 pq: it's just that other commenter that jumped to dropping ABI
09:42 emersion: but later
09:42 emersion: hm, i wonder how much work we are talking about
09:42 pq: you could do that, but then anyone disabling the event loop ABI would be getting a "ABI broken" library
09:43 emersion: we can probably make libwayland-server-no-event-loop.so be a dep of libwayland-server.so, with the latter adding new functions
09:43 pq: I guess you could push that responsibility onto distributions
09:43 emersion: yeah, e.g. FreeBSD would turn that on when all compositors have migrated
09:44 emersion: all compositors they have in repos
09:44 pq: yes, libwayland-server-no-event-loop.so is exactly what I was describing
09:44 pq: I have a feeling that a C library that changes its ABI based on build options is... not quite welcome in general.
09:45 emersion: it's kind of tempting to also throw type safety for wl_resource into the mix but then the scope grows much larger
09:45 pq: indeed
09:45 emersion: hm, ok, i guess i'll try and see if it can be done easily
09:46 pq: it's just an option that came to my mind
09:46 emersion: do you know why we have wl_client_flush() btw?
09:46 emersion: it surprised me a bit
09:46 pq: not really, I guess... could be legacy
09:47 pq: it's going to be necessary for you without the event loop stuff, right?
09:47 emersion: > Reviewed-by: Jason Ekstrand
09:47 emersion: ah the good old days
09:48 pq: yeah, the pre-stable days, I guess
09:48 emersion: pq, yes, but the function signature isn't quite right
09:48 pq: I'm not surprised.
09:48 emersion: found: https://gitlab.freedesktop.org/wayland/wayland/-/commit/40b0a6bf630b45550ec1e5e62395006cbf4223aa
09:48 emersion: no motivation documented
09:49 pq: makes me wonder if that was the first implementation of flushing anything at all
09:50 emersion: sounds like an historical thing indeed
09:51 wlb: wayland Issue #362 opened by cyclo pentane (cyclopentane) SEGFAULT in Debug::log https://gitlab.freedesktop.org/wayland/wayland/-/issues/362
09:52 pq: looks like it might actually be the very first flush
09:55 emersion: ofourdan: have you seen my question about !188?
09:56 pq: emersion, I suppose there are many such things that are slightly off, that might perhaps be fixable by introducing a new library, and implement libwayland-server.so by means of calling into that library. If someone was up for that long work...
09:58 emersion: it depends how much fixing we're talking about
09:58 pq: or, a whole new and different wayland server library altogether, if things like EGL, Vulkan and other libs do not really need to call into libwayland-server.so.
09:58 pq: yeah... all the things that irritate whoever does the work
09:59 emersion: the easy way for me would be to create an empty libwayland-server-smol.so, move over a few functions, link it from libwayland-server.so, and be done
10:00 emersion: with both libraries using the same types as before
10:00 pq: that could work, yeah, if it solves all you care to solve
10:01 emersion: but yeah, if we want to fix more stuff, then… i think a completely new library might be good
10:01 emersion: but then who will port compositors?
10:02 pq: the compositor devs themselves, on their own decision
10:02 emersion: i don't see that ever happening tbh
10:02 pq: of course, there is no way to get the whole world to migrate so we could just delete whole libwayland-server.so, no way.
10:03 emersion: at least not without a gradual migration path
10:03 pq: nor to even to get everyone migrated to your libwayland-server-smol.so either
10:04 emersion: i mean, migrating to smol.so is easier: it's just a matter of doing the event loop stuff manually
10:04 emersion: proto impls remain largely untouched
10:04 jadahl: didn't we manually flush due to just queuing frame callbacks many many years ago?
10:04 emersion: jadahl: aha, that rings a bell
10:05 pq: oh right, generated protocol bindings, changing those would be bit, I did not event consider that.
10:05 pq: *big
10:06 emersion: pq, if we're talking about a reasonable amount of breaking changes, what would these be?
10:06 emersion: would the changes touch wl_resource and wl_client?
10:07 pq: anyone needing EGL_WL_bind_wayland_display might have a problem, proprietary libEGL particularly
10:07 emersion: and wl_global?
10:08 emersion: yeah, i don't use EGL_WL_bind_wayland_display anymore, but i understand some compositors still want it
10:10 pq: Hard to say.
10:10 emersion: i think that if we can leave the proto impls largely untouched, it'd be workable
10:11 pq: perhaps, or maybe a gradual migration path could be found
10:11 pq: Personally and with Weston, I don't really have any pressing desires on this topic. Not time to work on anything.
10:12 pq: *Nor
10:12 emersion: okay
10:14 ofourdan: emersion: nope, where?
10:14 emersion: ah, rip
10:14 emersion: yesterday
10:15 emersion: hm, iirc i was asking about the bits thing
10:15 emersion: why do we store number of bits, instead of the actual size?
10:15 ofourdan: on irc?
10:15 emersion: yea
10:15 ofourdan: unfortunately, oftc has the weird habit of kicking me off
10:15 ofourdan: so the connection was dead
10:16 emersion: eh
10:16 ofourdan: I think that's how it was done, we just kept the logic, not wanting to break too much I guess
10:18 ofourdan: the original patch is from mstoeckl_ so maybe he knows better
10:19 emersion: i understand the desire to round to POT, but it's a bit weird to store the number of bits
10:21 ofourdan: it's internal only though, the api uses a size.
10:30 wlb: wayland Issue #362 closed \o/ (SEGFAULT in Debug::log https://gitlab.freedesktop.org/wayland/wayland/-/issues/362)
11:42 wlb: wayland Issue #357 closed \o/ (Clarify the intended semantics of attach vs offset in version >= 5 https://gitlab.freedesktop.org/wayland/wayland/-/issues/357)