ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
navi has quit [Quit: WeeChat 4.0.4]
glennk has joined #wayland
Guest4722 has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
pounce has quit [Ping timeout: 480 seconds]
pounce has joined #wayland
whot has quit [Read error: Connection reset by peer]
Plagman has quit [Remote host closed the connection]
JoshuaAshton_ has joined #wayland
bbhtt- has joined #wayland
whot has joined #wayland
JoshuaAshton has quit [Read error: Connection reset by peer]
Plagman has joined #wayland
bbhtt has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
carlos_ has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
co1umbarius has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
kts has quit [Quit: Konversation terminated!]
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
bim9262_ has joined #wayland
bim9262- has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262- is now known as bim9262
bim9262_ has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
nerdopolis has quit [Ping timeout: 480 seconds]
crazybyte has quit [Quit: Bye]
crazybyte has joined #wayland
Fischmie- has joined #wayland
Fischmiep has quit [Read error: Connection reset by peer]
Fischmie- has quit [Read error: Connection reset by peer]
Fischmiep has joined #wayland
mxz has quit [Quit: cya]
mxz has joined #wayland
overholts has quit [Quit: overholts]
overholts has joined #wayland
pochu has quit [Quit: leaving]
cool110 has joined #wayland
cool110 is now known as Guest4795
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
sima has joined #wayland
pochu has joined #wayland
Guest4795 has quit [Remote host closed the connection]
vova has quit [Remote host closed the connection]
vova has joined #wayland
cool110_ has joined #wayland
cool110_ is now known as Guest4799
Kerr has quit [Quit: Bye.]
kts has joined #wayland
vova has quit [Remote host closed the connection]
vova has joined #wayland
vova has quit [Remote host closed the connection]
vova has joined #wayland
vova has quit [Remote host closed the connection]
vova has joined #wayland
vova has quit [Remote host closed the connection]
vova has joined #wayland
vova has quit [Remote host closed the connection]
vova has joined #wayland
glennk has joined #wayland
<MrCooper>
huh, can't remember the last time I got any PM spam
NotTheBees has joined #wayland
carlos_ has joined #wayland
iomari892 has joined #wayland
MajorBiscuit has joined #wayland
<NotTheBees>
I don't know if this is the right place to report this, but if I try to download the latest alpha from the releases page it only downloads a signature file
mvlad has joined #wayland
<ofourdan>
not sure, latest alpha for which project? Best for you would be to post here the link you're trying to use to download, se people here can figure this out.
<Company>
pq, swick[m]: Does the color management protocol concern itself with the question of when two colorspaces are equal, ie when you don't need to transform to go from one to the other?
<Company>
or is that implementation defined?
<pq>
Company, what do you mean?
<Company>
say, if some people hardcode primaries to 5 digits and somebody else to 7 digits
<Company>
is that the same colorspace?
<pq>
ah
<JEEB>
(that's why CICP/H.273 enum values are <3)
<Company>
JEEB: that's what made me think about it, yes
<pq>
we need some recommendations on how much tolerance to use, if you actually need to compare numbers
<Company>
enums vs copy/paste
<pq>
that's won't be in the protocol spec, though
<Company>
obviously I have the same problem in GTK when somebody hands me a colorspace - or some icc profile
<pq>
JEEB, btw. it seems people do not like H.273 and want to invent new enums.
<JEEB>
huh
<JEEB>
having matrix/primaries/transfer separately just made sense to me at least, and APPL apparently wants to make it easier to extend the list
<Company>
the problem you run into with that is compatibility
<Company>
if somebody adds a new format, how do you know if the compositor is expected to support it?
<pq>
my approach to ICC profiles is to handle them as opaque boxes and use some capable CMM to spit out the mathematics.
<Company>
or vice versa, if the compositor wants to advertise a format
<pq>
Company, the color-management protocol already explicitly advertises all supported enum values with events.
<Company>
yeah, but you want the CMM to spit out "this is Rec 2020 HLG"
i509vcb has joined #wayland
<pq>
Company, no I don't.
<Company>
well, you might want to decide that yourself
<Company>
I'm happy if some smarter entity can decide that for me
<JEEB>
pq: yea for wayland unspecified might be indeed a value you want to block. and yes, the BT.2020 stuff got added into transfer twice
<JEEB>
of course the current state is that effectively unspecified/unspecified/unspecified is how compositing is happening and compositors just expect it to be *something* :)
<JEEB>
but yea, as you add an explicit protocol you might want to disallow unspecified
<pq>
Company, that's my point: I don't want to try to out-smart the ICC profile. I want a capable CMM to tell me what it wants to happen to pixel values.
<pq>
JEEB, the thing is, the protocol does not force anyone to implement any CICP value.
<JEEB>
sure
<pq>
compositors can simply choose to not support the "no idea what this is" code point.
<JEEB>
yup
<Company>
which means apps need to hardcode stuff anyway
<Company>
so they can fallback?
<JEEB>
just noted that it might be a recommendation as well, since I expect the protocol to want to limit itself to explicitness? (we already have enough implicit guessing in various parts of multimedia). of course application not utilizing this protocol would still effectively be "unspecified", but can't do much about that
<pq>
Company, the fallback should not be another enum value, but a completely different request, or just fail.
<Company>
pq: I was thinking that it'd be an ICC profile
<pq>
or before outright failure, do the color stuff yourself
<pq>
Company, I think I lost track here
Dami_Lu has quit [Ping timeout: 480 seconds]
<Company>
all the enum values can just be represented by constructing an icc profile encoding the matrices and primaries, no?
<JEEB>
apparently HDR transfers require some never-seen-in-wild ICC profile version, but otherwise I guess yes? although not sure how well something like reversible YCgCo would work?
<Company>
so the client would just fall back to that if the compositor doesn't know an enum value
<pq>
Company, no, not at all.
<Company>
yeah, the transfer functions might be tricky
Dami_Lu has joined #wayland
<pq>
ICC v2 and v4 profiles always use the profile connection space (PCS) which is kinda undefined for any HDR workflow, and the ICC model also makes assumptions that do not hold for standard WCG or HDR video.
<Company>
I thought there was an ICC version by now that does HDR
<Company>
is that still not out?
<pq>
iccMAX could represent anything and everything probably, but it's also unicorn-ware
<Company>
meh okay
<Company>
then that approach doesn't work
<pq>
iccMAX spec is so complicated they had write specs for each use case on how to use iccMAX
<pq>
*had to
<pq>
yeah, I would not attempt to describe any HDR video with an ICC file any year soon, even though ICCv4 did add CICP
<pq>
you could use an ICC file as a container to deliver CICP, but what's the point for us?
<Company>
it would be a kinda neat way to handle fallbacks in an app
<Company>
1. try the specific thing
<Company>
2. if the compositor doesn't know about it, send an icc profile
<pq>
except it's actually more complicated than the first way they are the fallback for, and still require the same or more complicated support in compositors as the first way
<pq>
as/than
<pq>
if a compositor cannot understand CICP, then wrapping CICP into an ICC file doesn't make it better
<Company>
that wasn't what I was thinking
<pq>
you were thinking to use the ICC math blocks instead?
<Company>
I was thinking that if a compositor supported CICP 2019 but not CICP 2021, then those new enums could be put in an icc profile instead
<pq>
pipelines, what do you call them... AToB etc. elements
<pq>
I don't understand how that's any different.
pounce has quit [Remote host closed the connection]
pounce has joined #wayland
<pq>
In the end, I see the color enum support question as identical to e.g. pixel format support. Either the compositor supports the format, or it doesn't. If the compositor doesn't, the client needs to use something else.
<JEEB>
yup
<JEEB>
in theory you may attempt to hack around by trying to generate a "close enough, maybe" ICC profile. but that's not exactly what you're trying to present
<Company>
I suppose it doesn't buy you anything anyway
<pq>
things might be different if clients could send shader programs to the compositor to decode their contents, and that's... not too far away from iccMAX
<Company>
all you do is make the compositor do a suboptimal color conversion when you could do a better one
<Company>
though I guess you would save a copy of the pixels
<pq>
yeah
<pq>
yup
pochu_ has quit []
<pq>
that's what HDR with ICCv4 is AFAIU: if the CMM handles the HDR specifics explicitly, you get ok result. If the CMM handles only the "usual" ICC stuff, you get a pretty bad approximation.
<pq>
also AFAIU, those HDR specifics are pretty much the same we carry in color-management extension explicitly
<pq>
however, given how the "fallback" is built in to ICC profiles (the spec says: do this, or if not then this, and then this, in descending order of correctness/precision), the client wouldn't even know which part of the ICC profile is even used by the compositor.
<pq>
at least with color-management parametric image descritions, there is no "silent degradation"
<pq>
everything supported is explicitly advertised
<Company>
right, so the fallback should not be "try to convince the compositor some other way" but "do it on the client"
<JEEB>
yea
<pq>
indeed
<pq>
zamundaaa[m], did you forget to reply to list when you emailed me? :-)
<zamundaaa[m]>
yes. Gmail really doesn't handle mailing lists well
<pq>
zamundaaa[m], the classification could be like "definitely < 0.5 ms", "< 10 ms surely", and "long", but I didn't want to spin off on that tangent there.
<zamundaaa[m]>
yeah something like that would be ok. That could also be put into the API as a property on the colorop (max microseconds this operation may take), then the compositor can properly work with it
<zamundaaa[m]>
Only situation that would still be tricky is if a colorop gets programmed over a bus that's shared with multiple other colorops
<pq>
I would just assume that all programming is strictly serial.
<pq>
IOW, sum, not max, of all changed colorops
lordmzte has joined #wayland
<lordmzte>
Hello! I'm having a bit of an issue with EGL on wayland: I've got a custom event loop set up which constantly polls the wayland FD, dispatching events immediately as they come in. Now I'm also rendering some stuff using EGL and when I'm done I cann eglSwapBuffers. This function however (at least on the nvidia driver) ends up ALSO poll()ing the wayland socket FD. As my event loop is
<lordmzte>
already doing this though, it causes my whole program to deadlock after rendering one frame, as eglSwapBuffers never returns. What do I do about this?
bindu_ has quit [Remote host closed the connection]
<DemiMarie>
Is there interest in a windows-shell protocol for use with Wine? Without it Wine will be stuck on Xwayland forever.
<DemiMarie>
The Wayland driver being worked on cannot handle all applications without this protocol. Virtual desktop can, but it is very bad UX.
<emersion>
maybe
<DemiMarie>
Would a read-only “where am I?” protocol be accepted? What about one that provided read-only access to the relative position of two windows?
<emersion>
i don't think that's a good idea
<DemiMarie>
I have it on good authority (Qubes OS’s UX person) that there are legitimate reasons for applications to know this information, and it does not seem anywhere near as problematic as a protocol that allows writing.
<emersion>
a shell which implements the exact win32 semantics would be way better
<DemiMarie>
emersion: why is it a bad idea?
<DemiMarie>
This is for a different use-case.
<emersion>
i don't believe there is a legitimate use-case
<DemiMarie>
One is for Wine, the other is for complex multi-window GUI applications.
<DemiMarie>
Did I violate some unwritten netiquette rule by starting two conversations at once?
<emersion>
no, i didn't realize the two were not connected
<DemiMarie>
Anyway, the legitimate use-case is so that if I have more than one window, I can have one window e.g. draw an arrow pointing to another or something like that.
<emersion>
that sounds a lot like xeyes
<emersion>
… which isn't very compelling use-case to me
<ids1024>
One thing with wine-specific protocols: how can the compositor restrict the protocol to only wine? With XWayland it can since it starts XWayland.
<emersion>
one way would be to somehow store the bit "needs win32 APIs" in .desktop or something
<emersion>
then security-context
<DemiMarie>
ids1024: good point, and it also runs into another problem, which is that some people want to sandbox Wine.
<ids1024>
If the protocol does things that non-wine apps may want to do, but is universally available and not just available to wine, it ceases to really be a wine specific protocol.
<emersion>
it would completely replace xdg-shell, so not _that_ easy to use
<ids1024>
True. Switching shell protocol for one particular feature isn't all that practical.
<DemiMarie>
For me, virtual desktop would be an acceptable fallback for applications that cannot be supported with xdg-shell, but I suspect many users would disagree and for good reasons.
<Company>
as a toolkit person, this is also tricky
<Company>
because the app devs come to me and say "wine can do that, why can't you?"
rgallaispou has left #wayland [#wayland]
<MrCooper>
are they doing so with s/wine/Xwayland/ ?
gspbirel5687340886706131448762 has joined #wayland
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
IMTheNachoMan has joined #wayland
vaxry has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest4847
Guest4847 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest4848
lordmzte has quit [Quit: WeeChat 4.1.0]
Guest4848 has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
cool110- has joined #wayland
MrCooper has joined #wayland
cool110- has quit [Remote host closed the connection]
cool110- has joined #wayland
kts has joined #wayland
kts has quit [Remote host closed the connection]
kts has joined #wayland
mohit8158 has quit [Quit: mohit8158]
mohit8158 has joined #wayland
mohit8158 has quit []
mohit8158 has joined #wayland
<YaLTeR[m]>
Demi: what relative position do you give in compositors without a global 2d coordinate space for windows?
cool110- has quit [Ping timeout: 480 seconds]
cool110- has joined #wayland
marbol has joined #wayland
cool110- has quit [Remote host closed the connection]
gspbirel5687340886706131448762 has quit [Ping timeout: 480 seconds]
cool110- has joined #wayland
<DemiMarie>
MrCooper: Right now Wine relies on Xwayland. As per their XDC2023 talk the Wine devs don’t think they can support every application natively on Wayland.
iomari892 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
marbol has quit [Quit: Quit]
<MrCooper>
DemiMarie: my point was if app devs are going to ask for Wine's privileges, they should be asking for Xwayland's now