ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
<d_ed[m]>
>hmm, is mpv's resize behavior not technically a protocol error?
Fxzxmic has quit [Remote host closed the connection]
pochu has joined #wayland
Fxzxmic has joined #wayland
kts has quit [Quit: Konversation terminated!]
<pq>
JoshuaAshton, that's kind of the whole problem: scRGB *cannot* be used without more information, either explicit or assumed. As a protocol designer I cannot assume, so I require explicit, and leave the guessing for the apps.
<JEEB>
yea so the content color volume should be known by the app. for example if I'm trying to pass Display P3 wide gamut SDR as scRGB, then I should be able to flag that and then the compositor can decide how to show that content
<ifreund>
d_ed[m]: thanks for the link
devilhorns has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
invertedoftc096 has quit []
<emersion>
daniels, feel free to merge !309 if you like it
<pq>
swick[m], emersion, as we are talking about the H.273 enums, and putting those in XML, one more aspect comes to mind: headers generated from XML are hard to use in library public API. Would you need to define an identical enum anyway just to expose public API?
<pq>
do you have such libraries?
<emersion>
pq, btw the kernel patch is exactly the same situation: defines for values in the specs
Fxzxmic has quit [Ping timeout: 480 seconds]
<pq>
emersion, but it's not generated, and the names are unambiguous.
<emersion>
not sure what difference that makes…
<emersion>
the generated header issue is annoying to handle
<emersion>
historically wlroots just expects compositors to run the generator and include the file before wlr headers
<emersion>
which is … not nice
<emersion>
if we had widely available headers with the defines, it would be easier
<pq>
Most H.273 enum values list several standards. Which one to use for the name is somewhat arbitrary. It could be confusing for someone implementing the-other-spec, why is it using seemingly wrong value.
Fxzxmic has joined #wayland
<pq>
If I need to invent my own enum in libweston, I can use it for both internals and public API, and I can choose the naming most appropriate for Weston.
<pq>
of course, it doesn't hurt if XML defined another enum I just don't use
Fxzx_mic has quit [Ping timeout: 480 seconds]
<pq>
so I suppose the arguments of "generated headers are annoying" and "which name to pick" are moot, then?
<pq>
in that case, we can certainly have those enums in XML
<pq>
...with the caveat that also values outside of the enum are allowed, which means the argument is not actually an enum
<pq>
which I think language bindings people don't like?
<pq>
maybe language bindings would just ignore that XML enum too
dcz has quit [Ping timeout: 480 seconds]
dcz has joined #wayland
<pq>
as long as we rely on H.273 for the value definitions, I don't really care
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
nerdopolis has joined #wayland
dcz_ has joined #wayland
dcz has quit [Read error: Connection reset by peer]
invertedoftc096 has joined #wayland
dcz has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<swick[m]>
honestly, I really dislike having potentially non-exhausting enums... but if people really want it then I won't stop it
<swick[m]>
we can add those enums at any point in the future though so maybe try without them first?
<emersion>
wayland enums are non-exhaustive, and we can't change that'
<swick[m]>
usually if you send values which are not covered by an enum that results in a protocol error. having both the enum and the CICP spec to choose values from is just adding complexity.
<emersion>
"usually", it's totally manual
<emersion>
and there are cases where it's not an error
<emersion>
e.g. wl_shm formats
<kchibisov>
Given that you can add enums to wl_shm without bumping any version you have non-exhaustive enums handling in every library around wayland protocol.
<emersion>
the issue with not having the enum is that then users need to hardcode constants