ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
Guest6330 has quit [Ping timeout: 480 seconds]
d42 has joined #wayland
Moprius has quit [Quit: bye]
bodicceaII has quit [Remote host closed the connection]
bodicceaII has joined #wayland
daz has quit [Ping timeout: 480 seconds]
MrCooper_ has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
MrCooper has quit [Ping timeout: 480 seconds]
molinari has quit [Ping timeout: 480 seconds]
julio7359 has joined #wayland
systwi has joined #wayland
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
julio7359 has quit [Remote host closed the connection]
julio7359 has joined #wayland
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
kts has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
Dami_Lu has quit [Remote host closed the connection]
molinari has joined #wayland
Dami_Lu has joined #wayland
dcz_ has joined #wayland
ofourdan has joined #wayland
shoragan has quit [Remote host closed the connection]
<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.
MrCooper_ is now known as MrCooper
<emersion>
pq, I don't think I understand your comment
B-| has joined #wayland
<emersion>
why does the old API need to work when the compositor opts in with the new API?
<pq>
emersion, I'm talking from library ABI stand-point, not from a single library user stand-point.
<emersion>
hm, yes?
<pq>
there may and will be other library users that still do use the old ABI
<emersion>
sure
<emersion>
they continue to work fine>
<emersion>
?
<pq>
this all depends on what your actual goal is
<pq>
no, they won't work fine on FreeBSD, if FreeBSD drops the implementation of the old ABI.
<pq>
whether your goal is to only let the old ABI be unused, or to actually drop its implementation, that's up to you.
<pq>
my comment only applied to the goal of dropping the implementation, as that other commenter alluded to
<emersion>
hm, so you're saying we can't ever build-time disable the old ABI if we offer libwayland-server.so?
<pq>
correct - if following the library stable ABI rules
<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
<emersion>
right
<emersion>
a new library sounds like too much work tbh
<pq>
and that distributions can trivially see if they need the old big ABI to work for any particular program
<pq>
sure, that may be
<emersion>
easier to just re-implement libwayland in wlroots even
<pq>
that's your choice
<pq>
if you can live with that, go for it
<pq>
I do also see merits with not dropping the event loop ABI and just allowing it to become unused.
<pq>
and that goal I believe was in your mind, right?
<emersion>
i was planning to just add a build-time switch and #define to disable the event loop API
<pq>
it's just that other commenter that jumped to dropping ABI
<emersion>
but later
<emersion>
hm, i wonder how much work we are talking about
<pq>
you could do that, but then anyone disabling the event loop ABI would be getting a "ABI broken" library
<emersion>
we can probably make libwayland-server-no-event-loop.so be a dep of libwayland-server.so, with the latter adding new functions
<pq>
I guess you could push that responsibility onto distributions
<emersion>
yeah, e.g. FreeBSD would turn that on when all compositors have migrated
<emersion>
all compositors they have in repos
<pq>
yes, libwayland-server-no-event-loop.so is exactly what I was describing
<pq>
I have a feeling that a C library that changes its ABI based on build options is... not quite welcome in general.
<emersion>
it's kind of tempting to also throw type safety for wl_resource into the mix but then the scope grows much larger
<pq>
indeed
<emersion>
hm, ok, i guess i'll try and see if it can be done easily
<pq>
it's just an option that came to my mind
<emersion>
do you know why we have wl_client_flush() btw?
<emersion>
it surprised me a bit
<pq>
not really, I guess... could be legacy
<pq>
it's going to be necessary for you without the event loop stuff, right?
<emersion>
> Reviewed-by: Jason Ekstrand
<emersion>
ah the good old days
<pq>
yeah, the pre-stable days, I guess
<emersion>
pq, yes, but the function signature isn't quite right
<pq>
looks like it might actually be the very first flush
<emersion>
ofourdan: have you seen my question about !188?
<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...
tagr has quit [Remote host closed the connection]
tagr has joined #wayland
<emersion>
it depends how much fixing we're talking about
<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.
<pq>
yeah... all the things that irritate whoever does the work
<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
<emersion>
with both libraries using the same types as before
<pq>
that could work, yeah, if it solves all you care to solve
<emersion>
but yeah, if we want to fix more stuff, then… i think a completely new library might be good
<emersion>
but then who will port compositors?
<pq>
the compositor devs themselves, on their own decision
<emersion>
i don't see that ever happening tbh
<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.
<emersion>
at least not without a gradual migration path
<pq>
nor to even to get everyone migrated to your libwayland-server-smol.so either
<emersion>
i mean, migrating to smol.so is easier: it's just a matter of doing the event loop stuff manually
<emersion>
proto impls remain largely untouched
<jadahl>
didn't we manually flush due to just queuing frame callbacks many many years ago?
<emersion>
jadahl: aha, that rings a bell
<pq>
oh right, generated protocol bindings, changing those would be bit, I did not event consider that.
<pq>
*big
GentooPhysicist393542 has quit []
GentooPhysicist393542 has joined #wayland
<emersion>
pq, if we're talking about a reasonable amount of breaking changes, what would these be?
<emersion>
would the changes touch wl_resource and wl_client?
<pq>
anyone needing EGL_WL_bind_wayland_display might have a problem, proprietary libEGL particularly
<emersion>
and wl_global?
<emersion>
yeah, i don't use EGL_WL_bind_wayland_display anymore, but i understand some compositors still want it
<pq>
Hard to say.
<emersion>
i think that if we can leave the proto impls largely untouched, it'd be workable
<pq>
perhaps, or maybe a gradual migration path could be found
<pq>
Personally and with Weston, I don't really have any pressing desires on this topic. Not time to work on anything.
<pq>
*Nor
<emersion>
okay
<ofourdan>
emersion: nope, where?
<emersion>
ah, rip
<emersion>
yesterday
<emersion>
hm, iirc i was asking about the bits thing
<emersion>
why do we store number of bits, instead of the actual size?
<ofourdan>
on irc?
<emersion>
yea
<ofourdan>
unfortunately, oftc has the weird habit of kicking me off
<ofourdan>
so the connection was dead
<emersion>
eh
<ofourdan>
I think that's how it was done, we just kept the logic, not wanting to break too much I guess
<ofourdan>
the original patch is from mstoeckl_ so maybe he knows better
<emersion>
i understand the desire to round to POT, but it's a bit weird to store the number of bits
<ofourdan>
it's internal only though, the api uses a size.