ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
al has quit [Ping timeout: 480 seconds]
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
Brainium has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
KREYREN_oftc has quit [Remote host closed the connection]
Brainium has quit [Quit: Konversation terminated!]
mxz__ has joined #wayland
mxz_ has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
mxz has joined #wayland
sima has joined #wayland
guru_ has joined #wayland
Guru_DE has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru_ has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest2101
Guest2078 has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
Guru_DE has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
lni has joined #wayland
lni is now known as looopTools
<looopTools>
Hello, is it okay to ask questions about how to test against wayland in this forum ?
guru__ has quit [Ping timeout: 480 seconds]
qyliss has quit [Ping timeout: 480 seconds]
qyliss has joined #wayland
rv1sr has joined #wayland
glennk has joined #wayland
guru_ has joined #wayland
mripard has quit [Ping timeout: 480 seconds]
Guru_DE has quit [Ping timeout: 480 seconds]
<MrCooper>
looopTools: sounds fine, worst case we can point you elsewhere :)
kts has joined #wayland
mart has joined #wayland
mripard has joined #wayland
<looopTools>
I am looking for a way to run a drawing test up against wayland in docker (potentially using weston) So I can evaluate what is drawn against what I expect
<looopTools>
However the test have to run in a docker container
<looopTools>
Is this possible at all ?
d3x0r has joined #wayland
Decker has quit [Read error: Connection reset by peer]
d3x0r is now known as Decker
andymandias has quit [Ping timeout: 480 seconds]
andymandias has joined #wayland
leon-anavi has joined #wayland
iomari891 has joined #wayland
Company has quit [Quit: Leaving]
ofourdan has joined #wayland
xantoz has quit [Read error: Connection reset by peer]
xantoz has joined #wayland
<kennylevinsen>
looopTools: Depends on requirements. sway for example can be told to run headless with software rendering, but to test the more common gles or vulkan renderer you will need to plumb a render device through to the container
<pq>
That ^ is a draft for bringing global window system coordinates to Wayland.
<pq>
No, it's not late April 1st.
<kennylevinsen>
April -1st
<pq>
kennylevinsen, it actually grew from what you said in a recent comment :-)
<kennylevinsen>
Oh, the one on the discussion for output fractional scale?
<pq>
about compatibility and practicality
<pq>
I already forgot in which discussion.
<kennylevinsen>
well, it seems it had more impact than I anticipated :)
<looopTools>
daniels: thanks :)
<looopTools>
kennylevinsen: thanks :)
<kennylevinsen>
pq: well worded proposal. I'm starting to be in favor of such more lenient, but still structured, approach to practical compatibility
<pq>
My key point there is that it is defined to be "unreliable". That's what makes any of it plausible to me.
<pq>
people need to feel "eeeew, yuck" when using those client-side :-)
<kennylevinsen>
Yeah I haven't thought too much about that aspect, but for e.g. set_position it could be a valid solution by just allowing the compositor to lie through its teeth and just use it as a hint to make something reasonable happen
<kennylevinsen>
for others, the behavior might be simpler and more clear, e.g. we don't want people to use output scale, but there's nothing difficult about offering it exactly as requested. It's just that apps using it are per definition doing something broken...
<kennylevinsen>
but the big fat "deprecated, unreliable, here be dragons and they like the taste of cross-platform developer hands" warning would help steer things in the right direction
<pq>
yeah
<kennylevinsen>
although, where unspecified, there *is* a risk of de-facto standards developing in their place. E.g., mainstream apps depending on GNOME's behavior and everyone having to follow suit to due to peer/user pressure to make stuff work (not pointing fingers at gnome, just using them as example of "big server impl")
xantoz has joined #wayland
<MrCooper>
I'd say that's more than just a risk, that's what happens when behaviour isn't clearly specified
<ifreund>
I don't think people are going to feel "eeew, yuck." I think thats what we feel, but clients will feel more "yay" i can finally tell the compositor what to do, only test with their one favorite compositor, and never stop using the legacy protocol
<kennylevinsen>
it's less of a risk if mutter, kwin and weston disagree so developers do not get a sense of reliable semantics, but yes
<swick[m]>
100% people are going to use those features rather than rewriting their code
<kennylevinsen>
another way is to require some slight degree of malicious exercise of rights from compositors. Like when Go hashmaps intentionally shuffle iteration order to avoid devs relying on it, or the kernel booting with timers close to overflow
<kennylevinsen>
e.g., "set_position result must *never* match absolute coordinates"
<swick[m]>
that is all just the definition of a slippery slope
<kennylevinsen>
either way, how to handle these issues is definitely worth some more formal (and civil) discussion.
<swick[m]>
as soon as toolkits can fill out the "set position" thing in their API they will be content and not change their abstractions anymore
<swick[m]>
I don't trust them a single bit at all
<ifreund>
yep
<kennylevinsen>
I don't think that's the attitude from Qt and Gtk at all, rather that they cannot change existing abstractions in existing frameworks for existing apps
<ifreund>
and developers using the toolkit will have no idea set_position is relying on this broken legacy protocol on wayland, nor will they care if it "works"
<swick[m]>
gtk is a bad example because it has changed its APIs accordingly
<kennylevinsen>
I don't think neiher Qt and Gtk object to offering the new APIs or making breaking revisions in later majors
<kennylevinsen>
Yeah, they did in Gtk4, and for scale, qt6 technically followed the present-day solution to scale on wayland (output scale). I'd say we were the ones that fumbled that one and had to revise it with preferred_scale...
<kennylevinsen>
some devs are certainly... not interested in supporting wayland properly, but I'd consider the big toolkits part of the wayland community. I also think our better APIs and models should be sold mainly on their merits, rather than mainly by force
<ifreund>
honestly, I don't see myself ever supporting such a "legacy" protocol in my compositor
* daniels
shrugs
<daniels>
I'm pretty relaxed about it
<swick[m]>
which API is "better" is not a big factor for most people. they have existing code and abstractions and they will choose the one which causes least friction.
<ifreund>
yeah
<kennylevinsen>
daniels: that's also the state of mind I'm arriving at
<daniels>
you can always make compat features mutually exclusive with other features - provide them a carrot rather than just a stick
<daniels>
swick[m]: the obvious counterargument is that xwayland_shell exists, and at some point win32_shell might also need to exist
<ifreund>
Xwayland is fine for the stuff that nobody wants to update, if programs want the benefits of wayland they can use the wayland protocol properly
<daniels>
those client-facing APIs are pretty unlikely to change, and those clients also need to run on Wayland systems
<swick[m]>
daniels: I mean at least the xwayland protocol can be exposed to exactly the xwayland processes
<swick[m]>
*to the
<daniels>
and wine?
<daniels>
ultimately that's going to have to be exposed to random clients
<daniels>
and if someone really wants to pretend that hard to be a win32 client ... shrug
<kennylevinsen>
swick[m]: well, you might have app from xyz dev that refuses to support wayland properly. As a result, they have glitchy scaling and weird position behavior, and their incentive to do it right is then better UX. On the other hand, users might strongly prefer the imperfect but working state over a borked state where the dev just refuses and blames wayland...
<swick[m]>
you just shrug, we have sandboxes and stuff
<swick[m]>
win32_shell would be a security risk, period
<swick[m]>
exposing it to random clients is not going to work
<kennylevinsen>
ifreund: I'd also certainly be selective where it introduced complexity or unwanted functionality, but I wouldn't have problem with the example of exposing fractional output scale
xantoz_ has joined #wayland
<daniels>
swick[m]: sure, if GNOME's plan is that win32_shell requires a sandbox with ... an authenticated version of wine? then that's totally fine
<ifreund>
kennylevinsen: I was thinking mostly about exposing an absolute positioning primitive to wayland clients with that statement
<daniels>
it's just a limitation of GNOME that Win32 clients are only supported in a blessed sandbox or whatever
<kennylevinsen>
ifreund: It was also just an example from pq, there might be lighter things we'd want to handle in this way
<daniels>
other environments can and will have different approaches
<emersion>
I think if I have a win32 shell I'd expose it to unsandboxed clients, and want to add a flatpak permission to expose it to sandboxed clients
<swick[m]>
the other obvious way to make all of that work is to make things rootful
<emersion>
i also think that a legacy positioning protocol will not be enough for all use cases (e.g. wine)
<emersion>
given that wine alreafy has trouble going from win32 to x11...
<swick[m]>
X11 and wine apps by default would be rootful and if wayland exposes xwayland or win32 protocols then it can go rootless
iomari892 has joined #wayland
<daniels>
I think we're all too hung up on legacy positioning
<daniels>
set_position(x,y) was a random low-effort strawman
<daniels>
to illustrate the wider point
<ifreund>
Rootful X11 and wine by default would actually be great in my opinion, it would mostly need some work to clean up the UX. Last time I tried rootful Xwayland there was no clipboard integration for example
<kennylevinsen>
indeed, it's more about attitude and a mechanism to aid devs with real-world problems in ways that are maybe not exactly what we want normal clients to do
iomari891 has quit [Ping timeout: 480 seconds]
xantoz has quit [Ping timeout: 480 seconds]
<daniels>
^
<swick[m]>
sure, and I would expose cmp_ protocols to clients only if they have some off-by-default permission
iomari891 has joined #wayland
<swick[m]>
they can do rootful (for X11 or wine) or just not behave exactly as the developer intended without the permission but things would still mostly work by default
<swick[m]>
but just exposing those protocols to all clients and relying on developers to not use them because their name is "cmp_*" is a bit naive
<daniels>
it depends on your priorities - if your #1 priority, above all else, is to not have non-win32 clients pretend to be win32, then yes, it would be naïve to allow that to happen
<daniels>
personally I'm not developing an all-encompassing OS+DE+toolkit+... with a goal of enforcing a very rigid world view, so it's not my #1 priority
<daniels>
so it's not naïve of me to not really care if there's a non-Wine app using win32_shell
iomari892 has quit [Ping timeout: 480 seconds]
<swick[m]>
that wasn't my point. if we can agree that those protocols should not be relied upon by random apps then it's naive to think that the name and documentation of the API someone prevents people from using the API they want to use.
<swick[m]>
and we're not "enforcing a rigid world view" but care about authenticity, something that the web, android, and iOS also all do
kts has quit [Ping timeout: 480 seconds]
<daniels>
iOS is nothing if not enforcing a rigid world view, the web defined its own everything with no native escape (let's pretend ActiveX/NaCL never happened because everyone else sure does), ditto Android
<kennylevinsen>
Well, it is naïve to think anything other than armed sentries will stop anyone from doing anything, but words would deter many uses. And if the solution is visibly suboptimal or in any way janky, there is still technical incentive to do it right even if first done wrong.
<daniels>
and that's totally fine - I'm using IRC through a web browser, on a GNOME desktop, and I'm also poking at the iOS device right next to my laptop
<swick[m]>
i.e. it's a security consideration. and you can say you don't care about it but most systems nowadays do consider security a high priority.
* daniels
rolls eyes
<daniels>
you don't need me for this conversation, since you're already constructing strawmen for me
<kennylevinsen>
Many compatibility issues are not also security issues, but just Wayland ideology issues. I'm strongly in the camp of wanting app devs to not interfere with my choices, but most of it is bad UX to me, not security concerns.
<swick[m]>
you're saying we "enforcing a rigid world view" and I find that utterly unfair
f_ has joined #wayland
* Consolatis
assumes there is a glitch in the matrix
<Consolatis>
thought for a moment that wayland-protocols is discussing specifying protocols with the goal of them not being used
<kennylevinsen>
sell, with the goal of them barely being used
<kennylevinsen>
*well
<swick[m]>
I could also claim that it's a rigid worldview that everything must be 100% backwards compatible
<daniels>
you don't think it's rigid to specify that wine apps must only be run in an authenticated sandbox and never any other way?
<Consolatis>
IMHO this sounds more like "stop asking for global positioning already. if you *really really* want that you can use this cmp protocol but be prepared that it can not be relied on, neither on it being available nor working as you want."
<daniels>
I'm not equating 'rigid' to 'unreasonable', but in the context of having been able to run Wine apps outside of a specifically-authenticated sandbox for the last 24 years I've been using Linux, yes it is quite rigid
<daniels>
I'm also not equating 'rigid' to 'dumb', because yes, I do think that sandboxing is good
<daniels>
and weirdly I'm not out here arguing that it's better for every app to be completely unsandboxed either
<kennylevinsen>
Consolatis: again, it's not specifically about global positioning, it was just meant as an example for a different way to approach these issues
<swick[m]>
the backwards compatibility you want is also a rigid worldview
<swick[m]>
it's just not a useful thing to say
f_ has quit [Remote host closed the connection]
<daniels>
find a word you like, pretend I said it, move on
f_ has joined #wayland
<daniels>
but if you think the use of the word 'rigid' is somehow objectionable and you calling people 'naïve' is not, clearly there's no point even trying
<kennylevinsen>
communication is hard and people do not always agree on how strong words are, but let's avoid intentionally lighting things on fire
<swick[m]>
the problem I have is that you make it sound like backwards compatibility is just inherently something that must be achieved but I always have to argue that authenticity is something we care about
<daniels>
swick[m]: I'm not telling you anything at all
<swick[m]>
alright, whatever
<daniels>
have a look for yourself - <daniels> swick[m]: sure, if GNOME's plan is that win32_shell requires a sandbox with ... an authenticated version of wine? then that's totally fine
<kennylevinsen>
swick[m]: you are not the only one arguing for defending our ideologic approaches over backwards compatibility (I guess that's what you mean by authenticity?). I definitely wouldn't worry that this stance is under-represented in the discussion.
mclasen has joined #wayland
<kennylevinsen>
but I think it's also healthy to consider the consequences, and in particular the value - positive *and* negative - it brings to the rest of the community, and in particular cases where the ideological approach leaves holes
<kennylevinsen>
I don't think there was any issue with your server requiring a flag to allow compatibility protocols to be used, and servers can then have different approaches and opinions on that - having them at all would be the useful part.
* kennylevinsen
goes on break
<swick[m]>
and again my goal is "ideological", your goal is not
<kennylevinsen>
it is not fair to assume my goal
<swick[m]>
this is exactly what I mean
<swick[m]>
I don't know your goal, but you're calling mine idealogical
<kennylevinsen>
I'm a wlroots maintainer, we are historically *brutally* aligned with the ideological approach :)
<daniels>
he even said 'defending our ideologic approaches'
<daniels>
you're reading personal attacks whilst none exist
<daniels>
not every conversation has to be a fucking flamewar
<kennylevinsen>
swick[m]: I merely tried to interpret what you said with "authentic". I do not consider "ideological" itself negative, it was just the term I udnerstood it as.
mvlad has joined #wayland
<pq>
ifreund, the "yuck" comes from "a compositor can just ignore this??"
<Consolatis>
I'd like to see some more examples of what we are actually talking about here, global position was pointed out as an example. And wine seems to play some role as well?
<pq>
MrCooper, getting de-facto standards could also be the goal. We cannot define a specific behavior up front, so just need to see where it goes.
<swick[m]>
just maybe don't call what people are doing ideological and rigid and stuff like that. maybe you didn't mean it in a negative way, fair enough, but I certainly don't find those words to have a positive meaning.
<pq>
swick[m], yes, people are going to use them, that's why they need to be "broken" from the start.
<pq>
There is no way to solve this problem in a way that is both reliable and following Wayland principles.
<kennylevinsen>
swick[m]: we have to be a bit more flexible when it comes to use of vocabulary. Language is hard, and for some of us we're working with what is purely a second or third language. Focus on what the person meant - after clarifying statements if needed - rather than what *could* be read.
<pq>
Toolkits can document their non-Waylandy APIs as unreliable on Wayland after they have a replacement, and forward all bug reports concerning the unreliable API to compositors.
<kennylevinsen>
my language skills and vocabulary is heavily fragmented, so I'd ask you to give some room and not assume malice by default. :)
<ifreund>
pq: I only see that "yuck" coming if the compositor the app developer cares about ignores it
<JoshuaAshton>
win32_shell would really just be exposing more optional data for compositors to make informed decisions
<JoshuaAshton>
For example, Gamescope uses win32 window stylings to make a lot of decisions about focus, etc.
<JoshuaAshton>
Infecting xdg_shell with all the win32 nuances would be bad -- but exposing them so those that want to have that extra information can would be nice, and Gamescope would definitely need that for Wine Wayland to become viable.
<pq>
ifreund, you are totally welcome to never implement any legacy compatibility extension! That's a good position in my opinion, if you can take the heat.
<emersion>
yeah, redirecting users to rootful is a completely OK decision
Consolatis_ has joined #wayland
Consolatis is now known as Guest2122
Consolatis_ is now known as Consolatis
<mclasen>
knowing that the heat will come and still going ahead is an unfriendly act
<kennylevinsen>
we don't have a habit of forcing protocol implementations though
<kennylevinsen>
(case in point, session lock, layer shell, content type, idle notify, ...)
Coelacanthus[envsnet][m] has quit [Quit: Client limit exceeded: 20000]
Guest2122 has quit [Ping timeout: 480 seconds]
<mclasen>
and my personal reading of "ideological" is "principled, but with negative connotations"
<swick[m]>
and I still don't know how one would interpret "enforcing a rigid worldview" as something positive
<MrCooper>
pq: "if you can take the heat" is kind of the rub, once such protocols are considered de-facto standards, any compositor not supporting them is generally considered weird / broken
<swick[m]>
so dunno, I don't want flamewars but I also don't like when people say stuff to me that sound like insults to me :/
<kennylevinsen>
ideologcal just means that it adheres to a set of ideals, no negative connotation intended
<karolherbst>
I want to note that there is a difference between ideology and acting out of ideology
<karolherbst>
where the former is just a set of ideas you want to see and the latter can come around as very oppinionated behavior not wanting to move one bit
<swick[m]>
anyway, I know people here are not acting in bad faith so moving on
<JoshuaAshton>
Regarding what pq said: We get enough noise about SteamVR not working on Gnome, that there is a special SteamVR error code https://github.com/ValveSoftware/openvr/blob/master/headers/openvr.h#L1904C2-L1904C42 just so the error textbox can send you to a dedicated Steam Support page that explains the situation and tells you to switch to another DE -- and to be clear, I really didn't want to have to add that but the fact that it remains
<JoshuaAshton>
unsolved kinda forced our hand there. :c
<mclasen>
kennylevinsen: my recommendation: avoid the term
<kennylevinsen>
mclasen: do you have an alternative?
<daniels>
swick[m]: i'm not sure how you expect anyone to take it positively when they're called 'naïve'
<mclasen>
I've given you principled already
<kennylevinsen>
hmm, I'd read that as implying some moral compas or disciplined stance :/
<swick[m]>
daniels: I was trying to call the idea naive, but fair point
<pq>
Consolatis, hahaha, you got my point. :-D A band-aid should be removed once it's no longer needed. It's better to heal a wound than to carry a band-aid forever, if it can heal. A band-aid is more uncomfortable than fully healed, even if it does work.
fmuellner has joined #wayland
<swick[m]>
JoshuaAshton: I mean, you made it clear that you're not going to support another solution otherwise we could have shipped leasing a few month ago on mutter...
<mclasen>
JoshuaAshton: I don't see what you hope to achieve by telling us that you added an error code specifically to tell people not to use gnome
<JoshuaAshton>
mclasen: It was a response to what pq mentioned: "once such protocols are considered de-facto standards, any compositor not supporting them is generally considered weird / broken"
<JoshuaAshton>
And what I am saying is, that this is basically that exact situation -- given that there was enough noise online and via support for us to have our hand forced here
<swick[m]>
your hand wasn't forced, you decided that we have to support wayland
<pq>
MrCooper, then I see no solution at all.
<kennylevinsen>
JoshuaAshton: the error state is just "no DRM leasing support", right? Maybe it would have been more proper to just say that, and have the error page give GNOME as an example of a compositor not having it
<JoshuaAshton>
kennylevinsen: We have a generic error too for that
feaneron has joined #wayland
<kennylevinsen>
how does it differ from the gnome one?
<JoshuaAshton>
Because of the distinction between Gnome X11 supporting it and Gnome Wayland not, we had to have different error text there
<JoshuaAshton>
because users were very confused
<kennylevinsen>
ah
<kennylevinsen>
yeah maybe not *too* fond of the way GNOME is being called out in the code like that, but it's just a matter of wording an unavoidable error
<swick[m]>
the unfair part here is that you were not open to any solution that isn't the wayland leasing protocol and hence, we still have no leasing
<swick[m]>
and the justification is: others support this protocol, therefore it's reasonable to force everyone else to support the protocol
<swick[m]>
and I don't agree with that
<JoshuaAshton>
swick[m]: I have no idea what you are talking about, from what I understand, it was just you that was pushing heavily for doing something different than everyone else and then making me implement it?
<JoshuaAshton>
Latest comment from Jonas on the issue: "We have discussed this among the maintainers, and would like to make it clear that a Wayland protocol implementation has never been blocked, and this is still the current state."
<swick[m]>
yes, you won, because you're not willing to consider anything else, mutter will expose the leasing protocol
<JoshuaAshton>
To be clear, what I said was actually that if we are going to converge on something, you should do it as a group, and not make it Gnome specific
<JoshuaAshton>
I don't think I won anything, I just think there was no interest from anyone else right?
<JoshuaAshton>
Like that is literally what I was saying right? That we should have a standard we all agree on?
<swick[m]>
but we don't agree
<pq>
who's working on the next major revision of the Wayland drm leasing extension?
<pq>
I see drm-lease-v1 in staging, so it's perfectly fine to make another major revision as necessary.
<mclasen>
you can't fix "this shouldn't be a wayland protocol" with a new revision of a wayland protocol
<JoshuaAshton>
swick[m]: It's really just Mutter though? It's implemented everywhere else, KDE, wlroots compositors, XWayland, Monado, SteamVR, there's that one thing for big video displays too that I forget the name of. Again, it is everyone else that you have to win over that your idea is better, not me.
<pq>
mclasen, oh, it was that deep? Hm.
<swick[m]>
I don't agree
<JoshuaAshton>
There is already a load of handshaking in the Wayland protocol -- plenty of room to stall and pop up whatever auth dialog you want anyway if you wanted it imo
<mclasen>
thats always the core of the disagreement, isn't it?
<daniels>
pq: yes, it's 'portals should be the primary API for applications' vs. 'I should never have to use D-Bus for anything'
<swick[m]>
some compositors refuse the implement dbus things, so if we can all agree on something, it must be wayland
<swick[m]>
iow, getting everyone to agree on a dbus protocol is impossible if some people refuse to use dbus for anything
<pq>
aha, that doesn't seem solvable
<JoshuaAshton>
and we can do handshakes in Wayland which the protocol already has
<JoshuaAshton>
so plenty of room for whatever auth
<swick[m]>
JoshuaAshton: so when you say, oh, just convince everyone else, that is impossible to do
<swick[m]>
which you know
<JoshuaAshton>
swick[m]: Then you have your answer then as to what to do? :P
<swick[m]>
no, then your requirement is unreasonable
<swick[m]>
because that means we're only ever allowed to do IPC with wayland
<JoshuaAshton>
I don't think my requirement of "we should converge on an API for something" is unreasonable
<kennylevinsen>
I don't think the intention was that mutter had to convenince 100%, but rather that there was already a majority agreement and replacement requires a *new* majority agreement
<JoshuaAshton>
^
<feaneron>
swick[m]: wouldn't say "won" as a portals / session service approach is still on the table
<swick[m]>
the point is, you don't don't want to implement anything but the wayland protocol and search for excuses why we shouldn't implement anything else
<swick[m]>
but you're not honest enough to say that
<alice>
mean thing to say
* mclasen
suggests that the drm lease case is water under the bridge
<pq>
swick[m], careful there. Maybe have a break, get lunch, or something?
<emersion>
yeah, i don't see this discussion being productive here. let's stop for now
f_ has quit [Ping timeout: 480 seconds]
<JoshuaAshton>
To be clear, I don't actually care implementing whatever as long as it's agreed upon that this is the path forward -- I do have a personal preference -- but I definitely cannot support fragmenting this already horribly fragmented ecosystem further. It's going to end up with more bugs, edge cases and maintenance down the road if that happens. :(
mart has quit [Remote host closed the connection]
Guest2101 has quit [Ping timeout: 480 seconds]
<ifreund>
pq: heh, yeah I'd say I can take the heat well enough. I've held out for years without implementing the old kde_server_decoration protocol to make gtk3 behavio for example :D
<ifreund>
s/behavio/behave/
cool110 has joined #wayland
cool110 is now known as Guest2126
<swick[m]>
JoshuaAshton: sorry, shouldn't have said the last part
<zamundaaa[m]>
pq: I think the proposal could use a different example than absolute positioning. With how toolkit APIs and win32 use it, I doubt compositors would have a lot of wiggle room... either the API works and apps do the same, or it doesn't and apps break.
<pq>
zamundaaa[m], sure. I just couldn't think of anything else this morning. Would you like to add another example?
<zamundaaa[m]>
I can only think of two things: the win32 window type thing Joshua mentioned, and a potential future protocol for a purely client side Xwayland
<pq>
I know nothing of win32.
looopTools has quit [Quit: looopTools]
<pq>
purely client side Xwayland would include set_position(x,y), wouldn't it?
<zamundaaa[m]>
I have some hope that you can get relatively far without it, but it might need it, yes
<ifreund>
how would override redirect stuff work without it?
<zamundaaa[m]>
ifreund: that's simple: it wouldn't
<zamundaaa[m]>
I'm not convinced compatibility layers need to support every use case
<pq>
aren't all menus and tooltips O-R windows?
<ifreund>
don't basic stuff like dropdown menus use override redirect?
<pq>
I think at least traditionally they were.
<JoshuaAshton>
Yes
<JoshuaAshton>
but not all of them
<JoshuaAshton>
Some of them are just normal toplevel windows :(
<ifreund>
hahaha
<zamundaaa[m]>
pq: you don't need global positioning to make those work though
<zamundaaa[m]>
pq: I'm saying the compat layer would have to use heuristics to detect what the app actually wanted to do
<JoshuaAshton>
yeah
<emersion>
sadly a lot of windows don't set these
<mclasen>
we've used o-r windows and absolute positioning to (poorly) simulate xdg-popover client-side in gtk
<JoshuaAshton>
emersion: Yeah, even then Gamescope isn't 100% perfect
<JoshuaAshton>
Because some apps give you literally 0 info
<emersion>
:shock:
<emersion>
no 100% perfect? what are you waiting for? :P
kts has joined #wayland
Guest2126 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest2131
vincejv has quit [Remote host closed the connection]
<MrCooper>
"purely client side rootless Xwayland" doesn't make much sense to me; if the compositor doesn't act as WM for rootless Xwayland, how can the WM cooperate with the compositor?
<kennylevinsen>
I recall DemiMarie often talking about something written in OCaml that did just that
<ofourdan>
yeah, same here, I kept trying to make sense of it but couldn't
<JoshuaAshton>
O🐪
<kennylevinsen>
I think that idea is XWayland -> something -> compositor, where "something" acts as a WM, pulling some tricks akin to wine wayland to sort of do its job
<emersion>
smh, it's writen お🐪
<MrCooper>
AFAIK there's only one Xwayland-specific Wayland protocol request so far, which isn't really required
<colinmarc>
kennylevinsen: like... gamescope?
<kennylevinsen>
Ah yes, honarary camel
<emersion>
colinmarc: except more tightly integrated because not rootful
<colinmarc>
Company: that will let you sample a YUV texture in a shader and get RGB. but there's a big gotcha, which is that the RGB is still nonlinear using whatever TF was applied before the YCbCr conversion
rolf has quit [Read error: No route to host]
<colinmarc>
just mentioning that since I got stuck on it for a long time...
<colinmarc>
oh, you asked about wayland, not vulkan. I read too fast
<Company>
for people who care about accuracy: probably a lot
<Company>
oh, I do use LINEAR
<emersion>
my main question is: should i require LNEAR support to advertise a format to a client, or should i gracefully fallback to NEAREST if the driver can't do LINEAR, or should i always use NEAREST?
<Company>
it's fun how everyone uses different values
sergio_ has joined #wayland
<Company>
mutter's shaders us R.709 narrow, you use R.601 narrow and GTK uses R.601 full
<Company>
I still wanted to check what GLES uses by default
<emersion>
iirc i've asked here about the rest of the params
<colinmarc>
imo 709 is a safe default if there's no way to get that information from the client, because that'll match sRGB primaries and it's very close to the sRGB transfer function
<Company>
I've used 601 because ffmpeg deemed it the default in their code
<Company>
and because it looked better with my webcam ¯\_(ツ)_/¯
<colinmarc>
@company: idk if this is helpful, but the YCbCr encoding (equivalent to the matrix_coeffs field in h264/5) is an extra encoding step on top of whatever RGB encoding (defined by primaries/tf)
<Company>
colinmarc: the problem with making it 2 values is that I then have to carry 2 values everywhere on the off chance that one is a YUV buffer :/
f_ has joined #wayland
<swick[m]>
Company: and if you get direct scanout you get another chance of everything being wrong
<Company>
swick[m]: yeah, but that's not my problem :)
<swick[m]>
and the TF sometimes has to applied before and sometimes after the matrix
rasterman has quit [Quit: Gettin' stinky!]
<colinmarc>
swick: when before?
<JEEB>
was it the constant luminance stuff or ICtCp?
<swick[m]>
yup
<colinmarc>
ah BT2020-CL?
<colinmarc>
right
<JEEB>
effectively I haven't seen constant luminance BT.2020 being utilized, everyone using NCL
<Company>
colinmarc: so rereading what you said, I take this to mean that people do YUV with R709 to do the conversion from YUV=>RGB, but then they interpret these RGB pixels not necessarily as sRGB or R709 but may use a different color space entirely?
coldfeet has joined #wayland
<Company>
so basically YUV buffers should be treated like some form of compression where some compressor properties are named after colorspaces?
<colinmarc>
<Company> "Colin Marc: so rereading what..." <- Right, the BT.709 transfer function goes from RGB to R'G'B', and the BT.709 YCbCr matrix coeffs go from R'G'B' to YUV. They were defined in the same document, that's why they are named the same, I guess?
<colinmarc>
I don't know a ton about video out in the wild but I've heard of people doing encoding with 1/2/1 for primaries/tf/matrix. So that would be the sRGB transfer function, but then the 709 matrix applied to it
<colinmarc>
thinking of YUV as extra compression makes the most sense to me as well
<JoshuaAshton>
Company: I don't think that's true at all wrt. Vulkan
<JoshuaAshton>
colinmarc: Yeah it does not apply a TF -- just primaries fwiu.
<Company>
what isn't true at all?
<swick[m]>
one cannot apply primaries
<Company>
all those properties just select a matrix for converting from a yuv vec3 to an rgb vec3
<Company>
what that vec3 then means is up to the app
<mclasen>
swick[m]: depends on whether we're discussing monitors or nail polish
<swick[m]>
are they really called primaries, not primers or sth like that?
mvlad has quit [Remote host closed the connection]
<mclasen>
primer is usually applied to the face
<mclasen>
I wasn't serious anyway, sorry for the distraction
<alice>
i've never heard any part of nail polish be called a primary
<alice>
but i can see it i guess
kts has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
<Company>
Google is very helpful here. I learned that the primary cosmetic is the thing that goes into the weapon slot
feaneron has quit [Remote host closed the connection]
feaneron has joined #wayland
coldfeet has quit [Quit: Lost terminal]
cool110 has joined #wayland
cool110 is now known as Guest2166
Guest2157 has quit [Ping timeout: 480 seconds]
rv1sr has quit []
caveman has quit [Ping timeout: 480 seconds]
mart has quit [Quit: Konversation terminated!]
sima is now known as Guest2175
sima has joined #wayland
caveman has joined #wayland
sima has quit [Quit: Leaving]
Guest2175 has quit []
sima has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
jensen9 has joined #wayland
<jensen9>
gtk/qt scaling is only responsible for graphical elements like buttons and menus as well as text *inside* these elements? so text on web browser and e.g. text editors (both gui/cli) are not controlled by gtk/qt? if that's the case, it would better to fractionally scale only gtk/qt and then increase font size *instead* of fractionally scaling everything (e.g. by the Wayland
<jensen9>
compositor)? of course fractional scaling should be avoided where possible
<d_ed[m]>
no. On Qt and GTK scaling is applied for all painting
<kennylevinsen>
fractional scaling is also done by the app when supported, rather than "by the compositor" in post