05:51wlb: wayland Issue #377 closed \o/ (Some games (specially source and tf2c) dont run under wayland https://gitlab.freedesktop.org/wayland/wayland/-/issues/377)
07:07wlb: weston Merge request !1232 opened by Marius Vlad (mvlad) meson.build: Bump to version 11.0.92 for the beta release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1232
07:09wlb: weston/main: Marius Vlad * meson.build: Bump to version 11.0.92 for the beta release https://gitlab.freedesktop.org/wayland/weston/commit/ce111061de79 meson.build
07:09wlb: weston Merge request !1232 merged \o/ (meson.build: Bump to version 11.0.92 for the beta release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1232)
07:20wlb: weston New tag: 11.0.92 https://gitlab.freedesktop.org/wayland/weston/tags/11.0.92
07:32wlb: wayland.freedesktop.org Merge request !53 opened by Marius Vlad (mvlad) releases: add weston 11.0.92 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/53
07:32wlb: wayland.freedesktop.org Merge request !53 merged \o/ (releases: add weston 11.0.92 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/53)
07:32wlb: wayland.freedesktop.org/main: Marius Vlad * releases: add weston 11.0.92 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/a0d51ed2f001 releases/weston-11.0.92.tar.xz releases/weston-11.0.92.tar.xz.sig releases.html
07:41wlb: weston Issue #751 opened by Marius Vlad (mvlad) Add/enforce pointer constraint to kiosk-shell https://gitlab.freedesktop.org/wayland/weston/-/issues/751 [kiosk-shell]
08:22pq: 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.
08:23pq: or what swick[m] said, I think that matches what Weston does
08:23emersion: pq, the issue is that compositors just use EGL in general, and who knows what EGL does
08:23emersion: i suppose weston has shaders? sounds like a pain to reverse-engineer
08:24pq: then just keep on using EGL without knowing what it does - I would guess that your users would like the continuity of behavior
08:25emersion: ah, there are comments in yuva2rgba()
08:25emersion: ITU-R BT.601 & BT.709 quantization (limited range)
08:25pq: yeah, I RE'd that once upon a time :-)
08:25emersion: and ITU-R BT.601 encoding coefficients
08:26pq: initially it had no comments for years
08:26pq: IIRC
08:26JEEB: I rewrote the color range docs for FFmpeg, and thank goodness BT.2100 finally writes down the full range stuff
08:26JEEB: https://ffmpeg.org/doxygen/trunk/pixfmt_8h.html#a3da0bf691418bc22c4bcbe6583ad589a
08:27JEEB: BT.709 and BT.2020 only wrote down the limited range side
08:29pq: ah yes, the chroma values :-)
08:29JEEB: yup :D
08:31pq: hmm...
08:31pq: wasn't JPEG different from the "usual" full/limited range encoding?
08:32JEEB: not that I recall. it's "just" full range YCbCr, often expected to be BT.601 matrix and AVCHROMA_LOC_CENTER
08:33pq: oh, I remember: JPEG defines full-range 1.0 value to be encoded as 256u8, doesn't it?
08:33pq: not 255
08:34pq: effectively not being able to represent 1.0, but up to 255/256
08:35JEEB: 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
08:35pq: I'm pretty sure JPEG had *something* different from "everyone" else...
08:35JEEB: chroma location is the main thing I think, middle|center chroma citing
08:36JEEB: which might have been defined for MPEG-1 Video as well
08:36JEEB: but MPEG-2 Video+ go for left chroma citing by default
08:41pq: wish I remembered where I raed about it
08:47pq: JEEB, I suppose it was this: https://registry.khronos.org/DataFormat/specs/1.3/dataformat.1.3.html#QUANTIZATION_LEGACY_FULL
08:47pq: hopefully nothing to care about today
08:48JEEB: yea
08:48JEEB: at least I don't see that being a setting in any of the color space libraries around me
08:48pq: good :-)
08:50JEEB: 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)
08:51JEEB: thus it seems like everyone just decided that this stuff is already complex enough :D
08:51pq: maybe one should care if one was a jpeg decoding library, but I'm happy I'm not.
08:53haasn: Yeah I deliberately ignore it and treat jpeg full range as identical to itur full range
08:53haasn: Because that works in practice
08:53pq: haha, ok
08:54haasn: And avoids a bunch of issues
08:54haasn: Like inability to represent pure white
08:55haasn: If you apply the khronos recommended correction to account for that, then the result you end up with is almost identical anyways
08:55JEEB: yup
08:57haasn: “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.”
08:57haasn: So they only respect it during ycbcr -> rgb conversion
08:58haasn: But ycbcr conversion is linear except for an offset which is explicitly normalized to make black map to black
08:58haasn: So the difference here is almost imperceptible
08:58haasn: Or perhaps even literally identical
08:59pq: yeah, started wondering if that's mathematically identical, but cannot bother to write it out
08:59JEEB: :)
09:00JEEB: same for me, just made my decision due to no-one else seemingly caring about the possible difference
09:01pq: 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.
09:03JEEB: yea, I dislike that name myself, too. want to at some point switch it to more generic naming
09:03JEEB: also that is another reason why the documentation now specifically explains them
09:04pq: :-)
09:41emersion: daniels, yeah, i'd be in favor of installing generated headers in w-p…
09:41emersion: a consequence is that people won't need to integrate wayland-scanner with their build system
09:42emersion: ah, generated code
09:42emersion: hrm
09:42emersion: then we get mismatch between headers and code potentially
09:42emersion: unless we ship thin static libs
09:43emersion: pq argued in the other direction the other day iirc, saying that shipping generated core headers+code was a mistake (?)
09:43jadahl: how'd that work? libwayland-protocols-xdg-shell.so?
09:43emersion: probably just libwayland-protocols.a?
09:43emersion: with all generated code in there? (and the unused stuff is optimized away)
09:44jadahl: whats the reason to install to begin with? I missed yesterdays discussions
09:44emersion: jadahl: libweston and wlroots want to use the generated enums in their public API
09:44jadahl: aha
09:45jadahl: can we add a enum-only/opaque-struct arg to wayland-scanner to make it less risky?
09:45jadahl: then install only that
09:46jadahl: and I guess a no-enum version too :|
09:46emersion: here's the discussion i was referring to https://github.com/swaywm/wlroots/pull/1134#issuecomment-405403712
09:47emersion: the enums are guarded by #ifdef iirc so we can have some leeway but…
09:49pq: emersion, yes, I've felt that shipping the generated symbols in libwayland-{server,client}.so and the generated (marshalling) headers was a mistake.
09:49jadahl: ah, there are already guards, then shouldn't a enum only installed header be safe enough?
09:49pq: but I also thought that maybe wayland-protocols could install generated headers containing *only* enums.
09:49emersion: we've considered shipping /usr/include/wlr/wayland-protocols/*.h…
09:50emersion: i wonder if enums are the only thing one might need
09:50emersion: in client code, maybe object structs, but these are opaque so no big deal
09:51jadahl: exactly
09:51emersion: enums are common between client and server, so that's why there's the #ifdef i imagine
09:51pq: I can't think of what else you'd need. structs are trivial to declare, and they are opaque anyway.
09:51daniels: 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
09:51emersion: yeah, it should be safe, but also it's trivial for a library to just forward-declare the ones it needs
09:52emersion: enums are much more annoying to deal with
09:52pq: daniels, where would they not be forward declarations? Nothing ever actually defines them I think, they are simply cast to wl_proxy.
09:54emersion: hm sadly C23 adds a way to specify the underlying type for an enum
09:54emersion: but still no way to forward-declare
09:57jadahl: 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)
09:58emersion: no, it's not an issue, i think the enum-only header is a good solution
09:58emersion: i was just looking at an easy way out with C23
09:59daniels: pq: they're never not forward declarations
09:59pq: daniels, huh?
09:59emersion: they'are always forward decls ;)
10:00pq: damn double-negatives
10:00daniels: heh yeah, sorry
10:00emersion: daniels is a repeat offender
10:01pq: Is everyone now in favor of or at least not against the idea of adding XML enums for all the CICP values defined today?
10:01pq: 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.
10:02emersion: the maintenance burden is about keeping them up-to-date with new specs?
10:02pq: yup
10:02emersion: how often do specs appear?
10:02emersion: i'm guessing it's pretty rare?
10:02pq: I suppose so
10:02jadahl: seems like a light burdon
10:02daniels: emersion: Commonwealth English teaches that a double negative is better than a positive ... or should I say, not worse than a positive :P
10:03emersion: lol
10:03pq: "not worse" allows "not better" too
10:03jadahl: daniels: no wonder the common wealth collapsed
10:04pq: if we agree to pay the maintenance burden on enums, then we have no reason to allow unlisted values
10:05emersion: i think my main concern with not having enums for CICP is that magic constants will pop up everywhere in clients and compositors
10:05emersion: so i'd prefer to have either enums in XML, or enums in a header somewhere
10:05jadahl: pq: that depends on whether the enums we add are for convenience or strict
10:05pq: jadahl, what would be the difference?
10:05daniels: 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
10:05pq: they would use the same CICP defined numbers
10:06jadahl: pq: if its for convenience, using new code points without them being added to the xml is fine
10:06daniels: (no double negatives in that sentence! free of ambiguity!)
10:06pq: daniels, but there are multiple valid names for many of the CICP values...
10:06emersion: yeah, i'd prefer allowing values outside of enum…
10:06jadahl: me too
10:06emersion: the value is a uint32_t anyways
10:06daniels: pq: you mean that there's a 1:n mapping between codepoint and name, or?
10:07JEEB: also CICP might get its own registration authority
10:07emersion: pq, can we prefix the name with the relevant standard?
10:07emersion: where it's ambiguous
10:07JEEB: which would then mean that adding a new value would become as simple as adding a codec identifier to mp4 ra
10:07pq: daniels, yes, because the same code point is used for N different standrards that just happen to agree on this one detail.
10:07daniels: pq: gotcha
10:07emersion: ah
10:08pq: and another details may as well be very different
10:08emersion: "fun"
10:08daniels: JEEB: I wonder if that doing that will end up in CICP being as awesome as FourCC :)
10:08emersion: aha
10:08JEEB: daniels: at least it would have an official registration authority and vendors seem to be utilizing it for mp4 as well
10:09JEEB: https://mp4ra.org/#/codecs
10:09JEEB: and thankfully there is no similar historical baggage with CICP like there is with AVI or MOV/MP4
10:09pq: It sounds like you haven't looked at the transfer characteristics table of H.273 yet. :-P
10:09pq: you should look at it before demanding names
10:10pq: you can find the link from https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/cicp_h273.md and it's just a few clicks away
10:10emersion: wow, it even has CSV definitions
10:13pq: btw. any IEC spec is basically behind a paywall
10:13JEEB: seems like the new additions to CICP on jvet-experts haven't received a new draft
10:15pq: I can do those enums for color-management if you really want them.
10:16pq: 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.
10:16pq: so it won't be a CICP-only enum but include also our own
10:17pq: like set_tf_power token
10:17emersion: i don't really understand
10:17emersion: this would end up with conflicts potentially
10:17pq: no, because we have uint32_t, and H.273 says it uses only 0-255
10:18pq: so we have a few billion values that cannot conflict with H.273
10:19wlb: wayland Merge request !312 opened by Simon Ser (emersion) scanner: add new enum-header mode https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/312 [Scanner]
10:21pq: I can reserve the first 16-bit range for CICP in case CICP decides it needs more than 8 bits.
10:22emersion: i still don't understand the upside of requiring to be inside the enum
10:23pq: Why should we allow that if it cannot be needed?
10:23pq: Language bindings people always complain about open enums.
10:23zamundaaa[m]: emersion: it's so that you can add things like scRGB to the enum, which aren't in H.273
10:23emersion: pq, it's too late to fix that
10:23pq: zamundaaa[m], we won't add scRGB. It's not needed in order to use scRGB.
10:24emersion: language bindings need to allow values outside of the enum anwyays
10:24pq: emersion, wasn't the enum XML attribute added to make enums closed?
10:25emersion: that's not the case, wl_shm allows values outsiode of the enum for instance
10:25pq: wl_shm is a special case, not the rule
10:25zamundaaa[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)?
10:25emersion: by default, enums are not closed, and compositors/clients need to add manual checks to make it closed
10:26pq: 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.
10:26emersion: IOW, if i design a new protocol and don't mention anything about enums, then it's not closed by default
10:26emersion: thus language bindings cannot enforce closed enums
10:27pq: 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.
10:27pq: *than any nits number
10:28pq: 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.
10:29pq: received rather than transmitted, because sender can always be anything
10:30emersion: well, it's not like saying that the enum must be closed will prevent compositors from sending values outside anyways
10:30pq: 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.
10:31pq: zamundaaa[m], you might drive a monitor in HLG or traditional SDR, too.
10:31JEEB: 1.0 in scrgb is hdr graphics white which is usually mapped to 203 nits
10:32JEEB: so if your output is hdr you handle it as hdr graphucs white, if output is sdr you habdle it as sdr full value
10:32JEEB: sorry for touchscreen typos
10:32pq: right, which means the actual nits values are kind of irrelevant on their own
10:34pq: 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.
10:36pq: emersion, no, but it makes it clear it's a compositor bug, intentional or accidental.
10:36pq: all protocol requirements of compositors are equally unenforceable, a client cannot send an error to a compositor
10:38zamundaaa[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?
10:38emersion: maybve magic numbers aren't so bad in the end lol
10:39JEEB: zamundaaa[m]: scrgb from app to compositor is usually linear float
10:39pq: zamundaaa[m], scRGB uses the extended sRGB transfer function. It is not defined in nits at all.
10:39pq: ..or linear, but that is not in nits either
10:39JEEB: yup
10:39pq: nits only exist in PQ transfer function
10:40emersion: so there is a way to say that content is linear and not encoded? nice
10:40emersion: (in the proto)
10:40pq: and there they are related to the respective reference viewing environment, which makes them not actual nits but some relative quantity
10:40JEEB: and even there the nits from the screen may be higher or lower based on environment, yup
10:42pq: 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.
10:42emersion: yeah, makes sense
10:43emersion: i feel like i've asked this before but
10:43emersion: is 10-bit enough for linear?
10:43JEEB: no
10:43emersion: so 12 or 16?
10:43pq: 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.
10:43JEEB: fp16 at least I would guess?
10:44emersion: ah, so not even 12
10:44JEEB: i haven't done the math, but that is what vendors seem to utilize behind the scenes
10:44pq: emersion, depends on what kind of range your content has.
10:45pq: emersion, IIRC for traditional 8-bit per color channel stuff, 10 bits might be almost enough, maybe 11.
10:45JEEB: 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
10:51pq: yeah, that's useful. For PQ we have similar metadata, but for any other coding I haven't seen much.
10:51zamundaaa[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
10:52pq: 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.
10:53pq: zamundaaa[m], they don't, all others use a relative luminance, more or less between 0 and 1.
10:53JEEB: 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
10:53pq: zamundaaa[m], and even PQ luminance is relative to that mentioned reference viewing environment, so the unit cd/m² gives a false impression.
10:54JEEB: 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
10:55pq: or just in a regular office with lights on :-)
10:55JEEB: (500 is what iphone seems to write into the files it outputs since I implemented reading the reference viewing environment SEI in FFmpeg)
10:56JEEB: and yes, just a regular office is enough to be higher than the reference viewing environment :D
10:58JEEB: 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.
11:00pq: 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.
11:00pq: e.g. https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/108
11:02pq: 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?
11:02emersion: iirc i wanted to use it in mesa
11:02emersion: and mesa just defined it
11:02emersion: in the meantime
11:02pq: why didn't mesa use drm_fourcc.h instead?
11:04emersion: i don't remember
11:04emersion: maybe libdrm wasn't guaranteed to be there for the shm path
11:04pq: about the CICP enums, I guess you want names like _TF_BT709 instead of _TF_CICP_1 ?
11:04emersion: i think mesa has an internal copy of drm_fourcc.h now
11:05emersion: value = xxx_TF_CICP_1 wouldn't be better than value = 1
11:06swick[m]: pq and I been through this conversation multiple times already and every solution is kind of bad
11:06pq: I wasn't sure what you wanted. BT709 conveys little more.
11:06pq: CICP_1 does say it comes from CICP
11:06emersion: the whole protocol comes from CICP
11:07pq: CICP_1 does not attempt to mislead the reading thinking about BT.709 spec
11:07swick[m]: eh, no
11:07pq: *reader
11:07emersion: i was thinking about color-repr btw
11:07emersion: where there's no ambiguity
11:07swick[m]: even then we have alpha which is not from CICP
11:07pq: emersion, MatrixCoefficients does have the same ambiguity, just look at the table.
11:08pq: e.e code point 5 lists 6 different standards
11:08swick[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
11:09swick[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...
11:12swick[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...
11:12pq: 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.
11:13jadahl: pq: multiple enum names can have the same value can they not?
11:14pq: jadahl, they can, but how do you write code with those and confuse the hell out of everything? :-)
11:14pq: *not confuse
11:15pq: I also suspect a compiler might not like if multiple case statements have the same value...
11:15swick[m]: for rust that's also not true for example
11:16swick[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...
11:17pq: swick[m], yeah, PQ encoding is not special, it just pretends to be and causes confusion with its use of absolute units. :-)
11:18JEEB: 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
11:18pq: JEEB, but will people take the hint?
11:18swick[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...
11:19pq: I mean, completely unrelatedly, one can use resolution to decide between MatrixCoefficients...
11:19pq: swick[m], I meant the TF definition
11:22pq: I'll probably have to write the enum addition just to have something concrete for people to fight over.
11:23swick[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.
11:23JEEB: yea
11:24pq: yes, and it's so confusing
12:02jadahl: swick[m]: rust needs to handle that anyway since the xml allows it
12:04emersion: various languages have various limitations, trying to handle all of them doesn't fly
12:58kchibisov: 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).
13:01kchibisov: 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.
13:17emersion: just means you need to use something else
13:17emersion: e.g. in Rust, the newtype pattern
13:19kchibisov: 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?
13:20kchibisov: Like aliases don't provide any value other than "one more name", so it's safe to drop them.
13:22emersion: 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
13:23kchibisov: Given that enums with duplicated values weren't seen in the wild yet, languages like rust are mapping them to `enum` directly.
13:23emersion: for instance, bitfields don't work too well with rust enums
13:24kchibisov: They are mapped to bitflags.
13:24emersion: which is a newtype kind of thing
13:24kchibisov: Yeah, but they are annotated.
13:24emersion: if wayland's enum don't map too well with rust enums, you can do the same for regular enums
13:26emersion: IOW, just because rust doesn't have bitflag enums, doesn't mean we should stop using these in wayland XML
13:27kchibisov: I'm not arguing that you shouldn't use them. I'm more interested what is the value of 'enum { A = 1, B = 1, }'.
13:28emersion: here's an example https://git.sr.ht/~emersion/go-kdf/tree/master/item/kdf.go#L369
13:28emersion: Khronos Data Format changes the meaning of channels depending on the color model
13:28emersion: so there is overlap
13:29emersion: if you love programming types, you maybe are horrified by this, and would prefer separate types for each color model
13:31kchibisov: Well, you simply want to define some constants for your code.
13:31kchibisov: You'll write the same const thing in rust though.
13:31kchibisov: it's just in C you don't have real enums, it's more like "yet another way to define const".
13:32emersion: no, it really is an enum
13:32emersion: go happens not to have the concept of enum, instead you define a type and constants
13:32emersion: translating this idiomatic Go into idiomatic Rust would end up with an enum, not constants
13:33kchibisov: You can't have enum { A = 1, B = 1 } in rust though.
13:34kchibisov: What you'll likely write is enum Foo { } impl Foo { const A: i32 = 1; const B: i32 = 1; }.
13:34emersion: the same in C https://github.com/KhronosGroup/dfdutils/blob/master/KHR/khr_df.h#L313
13:34emersion: right, and wayland XML enums are no different from C enums
13:35emersion: and are different from rust enums
13:35emersion: (rust enums don't even have a value)
13:35kchibisov: emersion: you can have a value.
13:35kchibisov: You simply define it as repr(u32) and assign it.
13:36emersion: this is essentially adding a helper function to convert to a value
13:36emersion: it'a not the same as C
13:36emersion: it's*
13:38emersion: you can always accomodate for the differences
13:38emersion: for instance, to handle the open enum problem, you could add an Other(u32) entry to your Rust enum
13:40kchibisov: I'm just saying that this problem is not unique to rust in the first place.
13:40emersion: i completely agree
13:44kchibisov: Hm, so it's not actually an issue in rust from dipper testing.
13:44kchibisov: You just write it a bit differently.
13:45emersion: you could also just define a constant equal to the enum entry?
13:45kchibisov: https://paste.rs/7VZ.png
13:45emersion: yup, exactly what i had in mind
13:48ifreund: 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
13:49ifreund: 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
13:50ifreund: all wayland-scanner does with it is enforce that the enum is only sent as a uint on the wire not an int
13:50emersion: rust does generate different code depending on bitfield
13:50ifreund: so does zig-wayland
13:51ifreund: but it ignores duplicates in bitfields currently
13:54ifreund: 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
13:55ifreund: there's already the annoying case of wl_shm adding values to the enum without bumping the protocol version
13:55pq: ifreund, what you'r view on incomplete Wayland enums? Arguments that allow other values than listed in the enum.
13:55pq: *what is your
13:56ifreund: 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
13:57pq: wl_shm formats are a prime example of that, even without adding new values in the enum
13:57kchibisov: pq it's fine, because you can't make things forward compat otherwise.
13:57pq: would you prefer complete enums instead?
13:57kchibisov: But it will require bumping the interface?
13:58pq: yes, and we can do that
13:58emersion: but old interface needs to support values outside enum still
13:58ifreund: I would prefer an annotation in the xml of whether an enum is complete or not
13:58emersion: and a client can bind to v1 forever
13:58pq: it will be a bit useless from a C perspective, but if that's highly desirable for others, then sure
13:59kchibisov: 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 ¯\_(ツ)_/¯
13:59pq: I'm talking about color-representation and color-management enums now, these are new interfaces.
14:00emersion: maybe we should just drop the enum attr for wl_shm
14:00emersion: keep the enum, drop just the attr on the <arg>
14:01emersion: that would make zig unhappy, i suppose
14:02ifreund: it would be a breaking change for zig code but only require adding a single @enumToInt() cast
14:04ifreund: 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
14:04pq: alright
14:05ifreund: 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
14:07ifreund: 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
14:09pq: 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.
14:11ifreund: 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
14:12ifreund: i.e. the state argument to wl_pointer_send_button() would be the appropriate enum type instead of a plain uint
14:13pq: If it leaves the meaning to be defined by scanners, then how do I as a protocol designer know when to use it?
14:13ifreund: The problem is that there are not really any clear guidelines on what source-level forwards compatility should look like here
14:14ifreund: I'd say it's intended to be used to annotated any arg where values from exactly one enum are expected
14:15pq: ok, so if that enum is not exhaustive, enum attribute should not be added to the arg?
14:16kchibisov: Just fwiw, the person working on wayland-rs (Elinor) will tune/check later on.
14:17ifreund: pq: For zig at least I would rather have the enum added to the arg even if it is not exhaustive
14:18ifreund: thats what current protocols do already and the zig scanner will generate nicer code that way
14:18emersion: i'm not a fan of introducing an explicit concept of exhaustive attr to the XML
14:18ifreund: why not?
14:19pq: ifreund, ok
14:25wlb: wayland Merge request !313 opened by Simon Ser (emersion) build: override wayland-scanner dep https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/313 [Build system]
14:27wlb: wayland-protocols Merge request !208 opened by Simon Ser (emersion) build: install headers with enums https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/208
19:13wlb: wayland/main: Manuel Stoeckl * protocol: add new shm formats https://gitlab.freedesktop.org/wayland/wayland/commit/d40052e083be protocol/wayland.xml
19:13wlb: wayland Merge request !307 merged \o/ (protocol: add new shm formats https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/307)
19:17wlb: wayland Merge request !314 opened by Simon Ser (emersion) util: simplify wl_fixed_to_double() https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/314
19:18wlb: wayland Issue #346 closed \o/ (tests/fixed-benchmark.c is misleading / hides some of the cost of wl_fixed_to_double https://gitlab.freedesktop.org/wayland/wayland/-/issues/346)
19:18wlb: wayland/main: Manuel Stoeckl * tests: drop misleading fixed-benchmark https://gitlab.freedesktop.org/wayland/wayland/commit/b1b97e8d348e tests/ meson.build fixed-benchmark.c
19:18wlb: wayland Merge request !296 merged \o/ (Drop fixed-benchmark https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/296)
19:23wlb: wayland/main: Yang Wang * event-loop: optimize timer check logic https://gitlab.freedesktop.org/wayland/wayland/commit/11b17c1286af src/event-loop.c
19:24wlb: wayland Merge request !302 merged \o/ (event-loop: optimize timer check logic https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/302)