ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
xaizone4 has joined #wayland
xaizone has quit [Read error: Connection reset by peer]
dcz has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
caveman has quit [Ping timeout: 480 seconds]
caveman has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
tzimmermann has joined #wayland
kts has joined #wayland
psykose has quit [Remote host closed the connection]
iomari891 has quit [Read error: Connection reset by peer]
<pq>
emersion, when color-repr is not used, just do what you did before you supported color-repr. Or if you didn't do anything, look at some other popular compositor that did. I have no idea beyond that.
<pq>
or what swick[m] said, I think that matches what Weston does
<emersion>
pq, the issue is that compositors just use EGL in general, and who knows what EGL does
<emersion>
i suppose weston has shaders? sounds like a pain to reverse-engineer
<pq>
then just keep on using EGL without knowing what it does - I would guess that your users would like the continuity of behavior
<JEEB>
BT.709 and BT.2020 only wrote down the limited range side
<pq>
ah yes, the chroma values :-)
<JEEB>
yup :D
<pq>
hmm...
<pq>
wasn't JPEG different from the "usual" full/limited range encoding?
<JEEB>
not that I recall. it's "just" full range YCbCr, often expected to be BT.601 matrix and AVCHROMA_LOC_CENTER
<pq>
oh, I remember: JPEG defines full-range 1.0 value to be encoded as 256u8, doesn't it?
<pq>
not 255
<pq>
effectively not being able to represent 1.0, but up to 255/256
<JEEB>
I'm not seeing that being reflected in the zimg sw scaling/colorspace library either, so I expect if that is the case, it is being effectively ignored
<pq>
I'm pretty sure JPEG had *something* different from "everyone" else...
slattann has joined #wayland
<JEEB>
chroma location is the main thing I think, middle|center chroma citing
<JEEB>
which might have been defined for MPEG-1 Video as well
<JEEB>
but MPEG-2 Video+ go for left chroma citing by default
<JEEB>
at least I don't see that being a setting in any of the color space libraries around me
<pq>
good :-)
devilhorns has joined #wayland
<JEEB>
yeh, double-checked libplacebo and it does not have a special color levels value for pl_color_repr_jpeg (which is BT.601 + full range)
<JEEB>
thus it seems like everyone just decided that this stuff is already complex enough :D
<pq>
maybe one should care if one was a jpeg decoding library, but I'm happy I'm not.
<haasn>
Yeah I deliberately ignore it and treat jpeg full range as identical to itur full range
<haasn>
Because that works in practice
<pq>
haha, ok
<haasn>
And avoids a bunch of issues
<haasn>
Like inability to represent pure white
<haasn>
If you apply the khronos recommended correction to account for that, then the result you end up with is almost identical anyways
<JEEB>
yup
<haasn>
“After the model conversion matrix has been applied, the R′, G′ and B′ values should be scaled by 256/255, restoring the ability to represent pure white.”
<haasn>
So they only respect it during ycbcr -> rgb conversion
<haasn>
But ycbcr conversion is linear except for an offset which is explicitly normalized to make black map to black
<haasn>
So the difference here is almost imperceptible
<haasn>
Or perhaps even literally identical
<pq>
yeah, started wondering if that's mathematically identical, but cannot bother to write it out
<JEEB>
:)
<JEEB>
same for me, just made my decision due to no-one else seemingly caring about the possible difference
<pq>
JEEB, the thing that hit my eye was naming that enum value JPEG in your docs, which made me curious if it was literal JPEG old-school.
<JEEB>
yea, I dislike that name myself, too. want to at some point switch it to more generic naming
<JEEB>
also that is another reason why the documentation now specifically explains them
<pq>
:-)
iomari891 has joined #wayland
<emersion>
daniels, yeah, i'd be in favor of installing generated headers in w-p…
<emersion>
a consequence is that people won't need to integrate wayland-scanner with their build system
<emersion>
ah, generated code
<emersion>
hrm
<emersion>
then we get mismatch between headers and code potentially
<emersion>
unless we ship thin static libs
<emersion>
pq argued in the other direction the other day iirc, saying that shipping generated core headers+code was a mistake (?)
<jadahl>
how'd that work? libwayland-protocols-xdg-shell.so?
<emersion>
probably just libwayland-protocols.a?
<emersion>
with all generated code in there? (and the unused stuff is optimized away)
<jadahl>
whats the reason to install to begin with? I missed yesterdays discussions
<emersion>
jadahl: libweston and wlroots want to use the generated enums in their public API
<jadahl>
aha
<jadahl>
can we add a enum-only/opaque-struct arg to wayland-scanner to make it less risky?
<emersion>
the enums are guarded by #ifdef iirc so we can have some leeway but…
<pq>
emersion, yes, I've felt that shipping the generated symbols in libwayland-{server,client}.so and the generated (marshalling) headers was a mistake.
<jadahl>
ah, there are already guards, then shouldn't a enum only installed header be safe enough?
<pq>
but I also thought that maybe wayland-protocols could install generated headers containing *only* enums.
<emersion>
we've considered shipping /usr/include/wlr/wayland-protocols/*.h…
<emersion>
i wonder if enums are the only thing one might need
<emersion>
in client code, maybe object structs, but these are opaque so no big deal
<jadahl>
exactly
<emersion>
enums are common between client and server, so that's why there's the #ifdef i imagine
<pq>
I can't think of what else you'd need. structs are trivial to declare, and they are opaque anyway.
<daniels>
I can imagine clients wanting to have the proxy types, but given they're just an empty forward declaration, it should be safe (at least for C if not C++?) to ship those too
<emersion>
yeah, it should be safe, but also it's trivial for a library to just forward-declare the ones it needs
<emersion>
enums are much more annoying to deal with
<pq>
daniels, where would they not be forward declarations? Nothing ever actually defines them I think, they are simply cast to wl_proxy.
<emersion>
hm sadly C23 adds a way to specify the underlying type for an enum
<emersion>
but still no way to forward-declare
<jadahl>
is it really a problem with the macros? I can imagine wanting to use a newer w-p generated header for some new enum, but that seems like something that one can work around (include order, "upgrading" the devel package that bumped its own w-p version)
<emersion>
no, it's not an issue, i think the enum-only header is a good solution
<emersion>
i was just looking at an easy way out with C23
<daniels>
pq: they're never not forward declarations
<pq>
daniels, huh?
<emersion>
they'are always forward decls ;)
<pq>
damn double-negatives
<daniels>
heh yeah, sorry
<emersion>
daniels is a repeat offender
<pq>
Is everyone now in favor of or at least not against the idea of adding XML enums for all the CICP values defined today?
<pq>
we will be paying the maintenance burden, and if those exist, they affect how I will make set_primaries and set_tf_power optional in color-management.
<emersion>
the maintenance burden is about keeping them up-to-date with new specs?
<pq>
yup
<emersion>
how often do specs appear?
<emersion>
i'm guessing it's pretty rare?
<pq>
I suppose so
<jadahl>
seems like a light burdon
<daniels>
emersion: Commonwealth English teaches that a double negative is better than a positive ... or should I say, not worse than a positive :P
<emersion>
lol
<pq>
"not worse" allows "not better" too
<jadahl>
daniels: no wonder the common wealth collapsed
<pq>
if we agree to pay the maintenance burden on enums, then we have no reason to allow unlisted values
<emersion>
i think my main concern with not having enums for CICP is that magic constants will pop up everywhere in clients and compositors
<emersion>
so i'd prefer to have either enums in XML, or enums in a header somewhere
<jadahl>
pq: that depends on whether the enums we add are for convenience or strict
<pq>
jadahl, what would be the difference?
<daniels>
I would at least be in favour of adding the enums now with a short reference to where they're canonically defined (e.g. 'H.273 CICP xxx'), rather than the current situation where it's just a magic number you need another spec to even decode to a name
<pq>
they would use the same CICP defined numbers
<jadahl>
pq: if its for convenience, using new code points without them being added to the xml is fine
<daniels>
(no double negatives in that sentence! free of ambiguity!)
<pq>
daniels, but there are multiple valid names for many of the CICP values...
<emersion>
yeah, i'd prefer allowing values outside of enum…
<jadahl>
me too
<emersion>
the value is a uint32_t anyways
<daniels>
pq: you mean that there's a 1:n mapping between codepoint and name, or?
<JEEB>
also CICP might get its own registration authority
<emersion>
pq, can we prefix the name with the relevant standard?
<emersion>
where it's ambiguous
<JEEB>
which would then mean that adding a new value would become as simple as adding a codec identifier to mp4 ra
<pq>
daniels, yes, because the same code point is used for N different standrards that just happen to agree on this one detail.
<daniels>
pq: gotcha
<emersion>
ah
<pq>
and another details may as well be very different
<emersion>
"fun"
<daniels>
JEEB: I wonder if that doing that will end up in CICP being as awesome as FourCC :)
<emersion>
aha
<JEEB>
daniels: at least it would have an official registration authority and vendors seem to be utilizing it for mp4 as well
<pq>
btw. any IEC spec is basically behind a paywall
<JEEB>
seems like the new additions to CICP on jvet-experts haven't received a new draft
<pq>
I can do those enums for color-management if you really want them.
<pq>
But when I do, I will forbid values outside of the enum, because I don't see any reason to allow them. If we need more, we have to simply add it in the enum so it becomes also a Wayland standard.
<pq>
so it won't be a CICP-only enum but include also our own
<pq>
like set_tf_power token
<emersion>
i don't really understand
<emersion>
this would end up with conflicts potentially
<pq>
no, because we have uint32_t, and H.273 says it uses only 0-255
<pq>
so we have a few billion values that cannot conflict with H.273
<pq>
I can reserve the first 16-bit range for CICP in case CICP decides it needs more than 8 bits.
<emersion>
i still don't understand the upside of requiring to be inside the enum
<pq>
Why should we allow that if it cannot be needed?
<pq>
Language bindings people always complain about open enums.
<zamundaaa[m]>
emersion: it's so that you can add things like scRGB to the enum, which aren't in H.273
<emersion>
pq, it's too late to fix that
<pq>
zamundaaa[m], we won't add scRGB. It's not needed in order to use scRGB.
<emersion>
language bindings need to allow values outside of the enum anwyays
<pq>
emersion, wasn't the enum XML attribute added to make enums closed?
<emersion>
that's not the case, wl_shm allows values outsiode of the enum for instance
<pq>
wl_shm is a special case, not the rule
<zamundaaa[m]>
pq: How would that work? I know that for the primaries, Wine should specify the actually used ones (BT2020) but how would you do the transfer function (nits / 80)?
<emersion>
by default, enums are not closed, and compositors/clients need to add manual checks to make it closed
<pq>
zamundaaa[m], nits / 80 is not a transfer function, and scRGB primaries are the BT.709 primaries. BT.2020 has nothing to do with scRGB.
<emersion>
IOW, if i design a new protocol and don't mention anything about enums, then it's not closed by default
<emersion>
thus language bindings cannot enforce closed enums
<pq>
zamundaaa[m], scRGB (1.0, 1.0, 1.0) value should probably be handled as SDR maximum white, which defines the luminance in a more usable way any nits number.
<pq>
*than any nits number
<pq>
emersion, manual checks are necessary because we don't have automatic code to ensure only legit values can be transmitted. Enum being closed is a concept, not code.
<pq>
received rather than transmitted, because sender can always be anything
<emersion>
well, it's not like saying that the enum must be closed will prevent compositors from sending values outside anyways
<pq>
zamundaaa[m], you are thinking about converting scRGB to BT.2020/PQ and not about the definition of scRGB. It does not necessarily convert always to BT.2020/PQ.
<pq>
zamundaaa[m], you might drive a monitor in HLG or traditional SDR, too.
<JEEB>
1.0 in scrgb is hdr graphics white which is usually mapped to 203 nits
<JEEB>
so if your output is hdr you handle it as hdr graphucs white, if output is sdr you habdle it as sdr full value
<JEEB>
sorry for touchscreen typos
<pq>
right, which means the actual nits values are kind of irrelevant on their own
<pq>
graphics white or SDR max white eventually depends on the viewing environment, and it must be adjustable. If (HDR) monitors don't allow adjusting it, then we have to offer another way to end users.
<pq>
emersion, no, but it makes it clear it's a compositor bug, intentional or accidental.
<pq>
all protocol requirements of compositors are equally unenforceable, a client cannot send an error to a compositor
<zamundaaa[m]>
Maybe I'm still missing something... doesn't the client still need to tell the compositor about this vague definiton of brightness? What transfer function would the client set if it's using scRGB?
<emersion>
maybve magic numbers aren't so bad in the end lol
<JEEB>
zamundaaa[m]: scrgb from app to compositor is usually linear float
<pq>
zamundaaa[m], scRGB uses the extended sRGB transfer function. It is not defined in nits at all.
<pq>
..or linear, but that is not in nits either
<JEEB>
yup
<pq>
nits only exist in PQ transfer function
<emersion>
so there is a way to say that content is linear and not encoded? nice
<emersion>
(in the proto)
<pq>
and there they are related to the respective reference viewing environment, which makes them not actual nits but some relative quantity
<JEEB>
and even there the nits from the screen may be higher or lower based on environment, yup
kts has joined #wayland
<pq>
emersion, yes, there is a TF code for "linear". To make that actually work nicely, you either need hella lots of bits or floating-point pixel format.
<emersion>
yeah, makes sense
<emersion>
i feel like i've asked this before but
<emersion>
is 10-bit enough for linear?
<JEEB>
no
<emersion>
so 12 or 16?
<pq>
When one uses scRGB, one can also choose the TF. I suppose linear is a common choice, but if you need a non-linear encoding, then the canonical choice is extended sRGB TF.
<JEEB>
fp16 at least I would guess?
<emersion>
ah, so not even 12
<JEEB>
i haven't done the math, but that is what vendors seem to utilize behind the scenes
<pq>
emersion, depends on what kind of range your content has.
<pq>
emersion, IIRC for traditional 8-bit per color channel stuff, 10 bits might be almost enough, maybe 11.
<JEEB>
anyways just as a random note, the vendor most pushing for scrgb usage also has an api that tells the application how high the compositor will cut off at (new enough macs base this on the configured screen brightness - which also means how much "headroom" the display has at that point. since your configured max brightness is your sdr graphics white
<pq>
yeah, that's useful. For PQ we have similar metadata, but for any other coding I haven't seen much.
<zamundaaa[m]>
<pq> "nits only exist in PQ transfer..." <- ah, that explains my confusion. I thought the other transfer functions also had a brightness meaning attached
<pq>
we considered the EDR concept, but decided to leave it for later, because it's not obvious how it interacts with PQ coding and people want PQ coding first anyway.
<pq>
zamundaaa[m], they don't, all others use a relative luminance, more or less between 0 and 1.
<JEEB>
seems to just be that 1.0=SDR graphics white=HDR graphics white, which makes it easier for clients that just want to output HDR but don't care about exact PQ or whatever
<pq>
zamundaaa[m], and even PQ luminance is relative to that mentioned reference viewing environment, so the unit cd/m² gives a false impression.
<JEEB>
yea, 400 nits imagery defined for the cinema reference viewing environment should be boosted quite a bit if for example you're watching it on a screen outside where the ambient environment is already at 500 nits or whatever
<pq>
or just in a regular office with lights on :-)
<JEEB>
(500 is what iphone seems to write into the files it outputs since I implemented reading the reference viewing environment SEI in FFmpeg)
<JEEB>
and yes, just a regular office is enough to be higher than the reference viewing environment :D
<JEEB>
there are random nits being mentioned in sRGB for example (80 nits), but I think some sort of average of how bright screens showed SDR graphics white was at like 200-250 nits? and when mapping to HDR the SDR nits are not relevant since SDR graphics white "just" gets mapped to HDR graphics white.
<pq>
emersion, there must be some reason why people bother updating wl_shm format enum even though they could just use drm_fourcc without that. I don't remember why.
<pq>
Another case in point is zwp_linux_dmabuf that still does not have an enum. Do people regret it not having a pixel format enum?
<emersion>
iirc i wanted to use it in mesa
<emersion>
and mesa just defined it
<emersion>
in the meantime
<pq>
why didn't mesa use drm_fourcc.h instead?
<emersion>
i don't remember
<emersion>
maybe libdrm wasn't guaranteed to be there for the shm path
<pq>
about the CICP enums, I guess you want names like _TF_BT709 instead of _TF_CICP_1 ?
<emersion>
i think mesa has an internal copy of drm_fourcc.h now
<emersion>
value = xxx_TF_CICP_1 wouldn't be better than value = 1
<swick[m]>
pq and I been through this conversation multiple times already and every solution is kind of bad
<pq>
I wasn't sure what you wanted. BT709 conveys little more.
<pq>
CICP_1 does say it comes from CICP
<emersion>
the whole protocol comes from CICP
<pq>
CICP_1 does not attempt to mislead the reading thinking about BT.709 spec
<swick[m]>
eh, no
<pq>
*reader
<emersion>
i was thinking about color-repr btw
Szadek has quit [Ping timeout: 480 seconds]
<emersion>
where there's no ambiguity
<swick[m]>
even then we have alpha which is not from CICP
<pq>
emersion, MatrixCoefficients does have the same ambiguity, just look at the table.
Szadek has joined #wayland
<pq>
e.e code point 5 lists 6 different standards
<swick[m]>
still, if you want a mapping from standard to code point you need something where values can map to multiple names and an enum is just not the right tool for that
<swick[m]>
I feel like this conversation is a bit tiring. We've been over it. There is no good solution. Let's try with the simplest one first which also allows us to explore other solutions in the future...
<swick[m]>
pq: I really don't think PQ is special in regards to the luminance of a code point. Other standards also define the reference monitor luminances. Some don't, some are defined weakly, but the concept of having a reference monitor which produces some luminance for certain values is universal...
<pq>
I *can* pick names for each code point, but they will be kind of arbitrary. Some of them will necessarily refer to a standard, but only a small piece of the standard and not the whole of it. Things are already confusing anyway, and I think it will easy to mistake a piece of a standard for the whole standard. That's the main disadvantage I need in naming these code points.
<jadahl>
pq: multiple enum names can have the same value can they not?
<pq>
jadahl, they can, but how do you write code with those and confuse the hell out of everything? :-)
<pq>
*not confuse
<pq>
I also suspect a compiler might not like if multiple case statements have the same value...
<swick[m]>
for rust that's also not true for example
<swick[m]>
if a c compositor wants to define an enum mapping different standards to code points then that's completely fine but I don't see the advantage of having it in the spec...
<pq>
swick[m], yeah, PQ encoding is not special, it just pretends to be and causes confusion with its use of absolute units. :-)
<JEEB>
pq: thankfully you usually have the thing you're pointing at as part of the var name, like TF/TRC or PRI(M) or MATRIX
<pq>
JEEB, but will people take the hint?
<swick[m]>
the other standards also use absolute units. the only thing that makes PQ special is that people keep saying PQ is special and that's what gets us displays where you can't control the brightness in HDR modes...
<pq>
I mean, completely unrelatedly, one can use resolution to decide between MatrixCoefficients...
<pq>
swick[m], I meant the TF definition
<pq>
I'll probably have to write the enum addition just to have something concrete for people to fight over.
<swick[m]>
I know. Usually the reference monitor gets a definition of the TF and a definition of the absolute minimum and maximum luminance. PQ just puts the absolute luminance to the TF but that has exactly the same semantics. It's just a different way to write the spec.
<JEEB>
yea
<pq>
yes, and it's so confusing
nerdopolis has joined #wayland
iomari891 has quit [Read error: Connection reset by peer]
iomari891 has joined #wayland
<jadahl>
swick[m]: rust needs to handle that anyway since the xml allows it
<emersion>
various languages have various limitations, trying to handle all of them doesn't fly
kts has quit [Quit: Konversation terminated!]
jmdaemon has quit [Ping timeout: 480 seconds]
<kchibisov>
I think most modern languages don't allow enums to have the same discriminant values for multiple entries, if I managed to read the issue correctly. In C it works because it's more or less a namespace, given that you can build the enum from arbitrary values(even not a part of that enum).
<kchibisov>
Will likely result in those enum fields being dropped entirely in such languages, because it doesn't make any sense to have different names for the same value.
DodoGTA has quit [Ping timeout: 480 seconds]
<emersion>
just means you need to use something else
<emersion>
e.g. in Rust, the newtype pattern
<kchibisov>
Are you talking about general enums we have for everything in wayland.xml now? In general I don't think that it's an issue with dropping the value, because it's value is covered anyway?
<kchibisov>
Like aliases don't provide any value other than "one more name", so it's safe to drop them.
i509vcb has quit [Quit: Connection closed for inactivity]
<emersion>
i'm talking about the general problem of mapping wayland XML's enums to a specific language's enum, when they don't agree on the semantics of what an enum is
<kchibisov>
Given that enums with duplicated values weren't seen in the wild yet, languages like rust are mapping them to `enum` directly.
<emersion>
for instance, bitfields don't work too well with rust enums
<kchibisov>
They are mapped to bitflags.
<emersion>
which is a newtype kind of thing
<kchibisov>
Yeah, but they are annotated.
<emersion>
if wayland's enum don't map too well with rust enums, you can do the same for regular enums
<emersion>
IOW, just because rust doesn't have bitflag enums, doesn't mean we should stop using these in wayland XML
<kchibisov>
I'm not arguing that you shouldn't use them. I'm more interested what is the value of 'enum { A = 1, B = 1, }'.
<ifreund>
if the official wayland view of enums is just a group of loosely namespaced constants it makes me wonder why we have the bitfield annotation
<ifreund>
I believe the intent for that was to generate more ergonomic code for no-C languages but I'm not sure that's really possible with the "arbitrary namespaced constants" view of enums
<ifreund>
all wayland-scanner does with it is enforce that the enum is only sent as a uint on the wire not an int
<emersion>
rust does generate different code depending on bitfield
<ifreund>
so does zig-wayland
<ifreund>
but it ignores duplicates in bitfields currently
floof58 has quit [Ping timeout: 480 seconds]
<ifreund>
also I'm nervous about future abuses^Wodd uses of enums in wayland protocols causing me to want to break zig-wayland API if I don't stick to the plain C view of enum semantics
<ifreund>
there's already the annoying case of wl_shm adding values to the enum without bumping the protocol version
<pq>
ifreund, what you'r view on incomplete Wayland enums? Arguments that allow other values than listed in the enum.
<pq>
*what is your
<ifreund>
Right now that's handled fine by zig-wayland actually because it already uses zig's "non-exhaustive" enums to handle the wl_shm case
<pq>
wl_shm formats are a prime example of that, even without adding new values in the enum
<kchibisov>
pq it's fine, because you can't make things forward compat otherwise.
<pq>
would you prefer complete enums instead?
<kchibisov>
But it will require bumping the interface?
<emersion>
but old interface needs to support values outside enum still
<ifreund>
I would prefer an annotation in the xml of whether an enum is complete or not
<emersion>
and a client can bind to v1 forever
<pq>
it will be a bit useless from a C perspective, but if that's highly desirable for others, then sure
<kchibisov>
I don't mind to be honest, it doesn't add anything extra from the rust point of view. Though, I don't work on the rust scanner directly ¯\_(ツ)_/¯
<pq>
I'm talking about color-representation and color-management enums now, these are new interfaces.
Company has joined #wayland
<emersion>
maybe we should just drop the enum attr for wl_shm
<emersion>
keep the enum, drop just the attr on the <arg>
<emersion>
that would make zig unhappy, i suppose
floof58 has joined #wayland
<ifreund>
it would be a breaking change for zig code but only require adding a single @enumToInt() cast
<ifreund>
the incomplete enum thing is most annoying for simple stuff like wl_pointer.button_state where it's realistically never going to have more than 2 values
<pq>
alright
<ifreund>
but because of how we treat wl_shm zig users are required to handle the 3rd case where the value is not in range everywhere
alatiera has joined #wayland
<ifreund>
I'm also not a huge fan of duplicate enum values/overlapping bitfield enum values but I think those are less annoying that the exhaustiveness/completeness issue
<pq>
what is the exact meaning of the enum attribute in <arg>? I'm not sure I understand the doc, it doesn't seem to really say anything.
<ifreund>
It means nothing on the wire, it's only meaningful with regards to how the generated code looks and allows scanners to enforce type safety
<ifreund>
i.e. the state argument to wl_pointer_send_button() would be the appropriate enum type instead of a plain uint
<pq>
If it leaves the meaning to be defined by scanners, then how do I as a protocol designer know when to use it?
<ifreund>
The problem is that there are not really any clear guidelines on what source-level forwards compatility should look like here
<ifreund>
I'd say it's intended to be used to annotated any arg where values from exactly one enum are expected
<pq>
ok, so if that enum is not exhaustive, enum attribute should not be added to the arg?
<kchibisov>
Just fwiw, the person working on wayland-rs (Elinor) will tune/check later on.
<ifreund>
pq: For zig at least I would rather have the enum added to the arg even if it is not exhaustive
<ifreund>
thats what current protocols do already and the zig scanner will generate nicer code that way
<emersion>
i'm not a fan of introducing an explicit concept of exhaustive attr to the XML