06:22looopTools: Hello, is it okay to ask questions about how to test against wayland in this forum ?
07:10MrCooper: looopTools: sounds fine, worst case we can point you elsewhere :)
07:27looopTools: 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
07:28looopTools: However the test have to run in a docker container
07:28looopTools: Is this possible at all ?
08:34kennylevinsen: 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
08:35kennylevinsen: I imagine weston can do the same
08:49wlb: wayland-protocols Merge request !307 opened by Julian Orth (mahkoh) security-context-v1: clarify close_fd behavior https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/307
08:53MrCooper: mstoeckl_: waypipe seems to pass through wp_linux_drm_syncobj_manager_v1, it doesn't actually work though
08:57daniels: looopTools: yeah, weston --backend=headless --renderer=pixman
08:57daniels: or you can use --renderer=gl if you want to use llvmpipe software rendering, or if you've bind-mounted your GPU device into the container
09:07wlb: wayland-protocols Issue #194 opened by Pekka Paalanen (pq) RFC: new category for legacy compatibility extensions https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/194
09:08pq: That ^ is a draft for bringing global window system coordinates to Wayland.
09:08pq: No, it's not late April 1st.
09:08kennylevinsen: April -1st
09:09pq: kennylevinsen, it actually grew from what you said in a recent comment :-)
09:10kennylevinsen: Oh, the one on the discussion for output fractional scale?
09:10pq: about compatibility and practicality
09:10pq: I already forgot in which discussion.
09:12kennylevinsen: well, it seems it had more impact than I anticipated :)
09:13looopTools: daniels: thanks :)
09:13looopTools: kennylevinsen: thanks :)
09:18kennylevinsen: pq: well worded proposal. I'm starting to be in favor of such more lenient, but still structured, approach to practical compatibility
09:20pq: My key point there is that it is defined to be "unreliable". That's what makes any of it plausible to me.
09:21pq: people need to feel "eeeew, yuck" when using those client-side :-)
09:21kennylevinsen: 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
09:23kennylevinsen: 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...
09:24kennylevinsen: 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
09:24pq: yeah
09:26kennylevinsen: 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")
09:29MrCooper: I'd say that's more than just a risk, that's what happens when behaviour isn't clearly specified
09:31ifreund: 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
09:31kennylevinsen: it's less of a risk if mutter, kwin and weston disagree so developers do not get a sense of reliable semantics, but yes
09:32swick[m]: 100% people are going to use those features rather than rewriting their code
09:32kennylevinsen: 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
09:33kennylevinsen: e.g., "set_position result must *never* match absolute coordinates"
09:33swick[m]: that is all just the definition of a slippery slope
09:35kennylevinsen: either way, how to handle these issues is definitely worth some more formal (and civil) discussion.
09:35swick[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
09:35swick[m]: I don't trust them a single bit at all
09:35ifreund: yep
09:35kennylevinsen: 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
09:36ifreund: 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"
09:36swick[m]: gtk is a bad example because it has changed its APIs accordingly
09:36kennylevinsen: I don't think neiher Qt and Gtk object to offering the new APIs or making breaking revisions in later majors
09:37kennylevinsen: 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...
09:42kennylevinsen: 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
09:43ifreund: honestly, I don't see myself ever supporting such a "legacy" protocol in my compositor
09:43daniels:shrugs
09:43daniels: I'm pretty relaxed about it
09:43swick[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.
09:43ifreund: yeah
09:44kennylevinsen: daniels: that's also the state of mind I'm arriving at
09:44daniels: you can always make compat features mutually exclusive with other features - provide them a carrot rather than just a stick
09:44daniels: swick[m]: the obvious counterargument is that xwayland_shell exists, and at some point win32_shell might also need to exist
09:44ifreund: 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
09:45daniels: those client-facing APIs are pretty unlikely to change, and those clients also need to run on Wayland systems
09:45swick[m]: daniels: I mean at least the xwayland protocol can be exposed to exactly the xwayland processes
09:45swick[m]: *to the
09:45daniels: and wine?
09:45daniels: ultimately that's going to have to be exposed to random clients
09:46daniels: and if someone really wants to pretend that hard to be a win32 client ... shrug
09:46kennylevinsen: 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...
09:46swick[m]: you just shrug, we have sandboxes and stuff
09:46swick[m]: win32_shell would be a security risk, period
09:46swick[m]: exposing it to random clients is not going to work
09:47kennylevinsen: 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
09:48daniels: 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
09:48ifreund: kennylevinsen: I was thinking mostly about exposing an absolute positioning primitive to wayland clients with that statement
09:48daniels: it's just a limitation of GNOME that Win32 clients are only supported in a blessed sandbox or whatever
09:49kennylevinsen: ifreund: It was also just an example from pq, there might be lighter things we'd want to handle in this way
09:49daniels: other environments can and will have different approaches
09:49emersion: 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
09:49swick[m]: the other obvious way to make all of that work is to make things rootful
09:49emersion: i also think that a legacy positioning protocol will not be enough for all use cases (e.g. wine)
09:50emersion: given that wine alreafy has trouble going from win32 to x11...
09:51swick[m]: X11 and wine apps by default would be rootful and if wayland exposes xwayland or win32 protocols then it can go rootless
09:51daniels: I think we're all too hung up on legacy positioning
09:51daniels: set_position(x,y) was a random low-effort strawman
09:51daniels: to illustrate the wider point
09:52ifreund: 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
09:52kennylevinsen: 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
09:54daniels: ^
09:55swick[m]: sure, and I would expose cmp_ protocols to clients only if they have some off-by-default permission
09:56swick[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
09:57swick[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
09:58daniels: 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
09:59daniels: 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
10:00daniels: so it's not naïve of me to not really care if there's a non-Wine app using win32_shell
10:02swick[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.
10:03swick[m]: and we're not "enforcing a rigid world view" but care about authenticity, something that the web, android, and iOS also all do
10:04daniels: 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
10:05kennylevinsen: 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.
10:05daniels: 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
10:05swick[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.
10:05daniels:rolls eyes
10:06daniels: you don't need me for this conversation, since you're already constructing strawmen for me
10:06kennylevinsen: 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.
10:07swick[m]: you're saying we "enforcing a rigid world view" and I find that utterly unfair
10:08Consolatis:assumes there is a glitch in the matrix
10:08Consolatis: thought for a moment that wayland-protocols is discussing specifying protocols with the goal of them not being used
10:08kennylevinsen: sell, with the goal of them barely being used
10:08kennylevinsen: *well
10:10swick[m]: I could also claim that it's a rigid worldview that everything must be 100% backwards compatible
10:10daniels: 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?
10:11Consolatis: 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."
10:11daniels: 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
10:12daniels: I'm also not equating 'rigid' to 'dumb', because yes, I do think that sandboxing is good
10:12daniels: and weirdly I'm not out here arguing that it's better for every app to be completely unsandboxed either
10:12kennylevinsen: Consolatis: again, it's not specifically about global positioning, it was just meant as an example for a different way to approach these issues
10:12swick[m]: the backwards compatibility you want is also a rigid worldview
10:13swick[m]: it's just not a useful thing to say
10:13daniels: find a word you like, pretend I said it, move on
10:15daniels: 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
10:16kennylevinsen: communication is hard and people do not always agree on how strong words are, but let's avoid intentionally lighting things on fire
10:16swick[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
10:17daniels: swick[m]: I'm not telling you anything at all
10:17swick[m]: alright, whatever
10:17daniels: 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
10:18kennylevinsen: 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.
10:20kennylevinsen: 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
10:20kennylevinsen: 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.
10:22kennylevinsen:goes on break
10:22swick[m]: and again my goal is "ideological", your goal is not
10:22kennylevinsen: it is not fair to assume my goal
10:22swick[m]: this is exactly what I mean
10:23swick[m]: I don't know your goal, but you're calling mine idealogical
10:23kennylevinsen: I'm a wlroots maintainer, we are historically *brutally* aligned with the ideological approach :)
10:23daniels: he even said 'defending our ideologic approaches'
10:23daniels: you're reading personal attacks whilst none exist
10:24daniels: not every conversation has to be a fucking flamewar
10:24kennylevinsen: 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.
10:25pq: ifreund, the "yuck" comes from "a compositor can just ignore this??"
10:26Consolatis: 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?
10:26pq: 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.
10:27swick[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.
10:27pq: swick[m], yes, people are going to use them, that's why they need to be "broken" from the start.
10:28pq: There is no way to solve this problem in a way that is both reliable and following Wayland principles.
10:32kennylevinsen: 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.
10:32pq: 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.
10:32kennylevinsen: my language skills and vocabulary is heavily fragmented, so I'd ask you to give some room and not assume malice by default. :)
10:33ifreund: pq: I only see that "yuck" coming if the compositor the app developer cares about ignores it
10:33JoshuaAshton: win32_shell would really just be exposing more optional data for compositors to make informed decisions
10:33JoshuaAshton: For example, Gamescope uses win32 window stylings to make a lot of decisions about focus, etc.
10:34JoshuaAshton: 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.
10:34pq: 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.
10:35emersion: yeah, redirecting users to rootful is a completely OK decision
10:35mclasen: knowing that the heat will come and still going ahead is an unfriendly act
10:36kennylevinsen: we don't have a habit of forcing protocol implementations though
10:37kennylevinsen: (case in point, session lock, layer shell, content type, idle notify, ...)
10:39mclasen: and my personal reading of "ideological" is "principled, but with negative connotations"
10:40swick[m]: and I still don't know how one would interpret "enforcing a rigid worldview" as something positive
10:40MrCooper: 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
10:41JoshuaAshton: Something something drm leasing? :)
10:41swick[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 :/
10:41kennylevinsen: ideologcal just means that it adheres to a set of ideals, no negative connotation intended
10:42karolherbst: I want to note that there is a difference between ideology and acting out of ideology
10:43karolherbst: 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
10:43swick[m]: anyway, I know people here are not acting in bad faith so moving on
10:44JoshuaAshton: 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
10:44JoshuaAshton: unsolved kinda forced our hand there. :c
10:44mclasen: kennylevinsen: my recommendation: avoid the term
10:44kennylevinsen: mclasen: do you have an alternative?
10:44daniels: swick[m]: i'm not sure how you expect anyone to take it positively when they're called 'naïve'
10:45mclasen: I've given you principled already
10:46kennylevinsen: hmm, I'd read that as implying some moral compas or disciplined stance :/
10:46swick[m]: daniels: I was trying to call the idea naive, but fair point
10:47pq: 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.
10:50swick[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...
10:51mclasen: 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
10:52JoshuaAshton: 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"
10:53JoshuaAshton: 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
10:54swick[m]: your hand wasn't forced, you decided that we have to support wayland
10:54pq: MrCooper, then I see no solution at all.
10:55kennylevinsen: 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
10:56JoshuaAshton: kennylevinsen: We have a generic error too for that
10:56kennylevinsen: how does it differ from the gnome one?
10:56JoshuaAshton: Because of the distinction between Gnome X11 supporting it and Gnome Wayland not, we had to have different error text there
10:56JoshuaAshton: because users were very confused
10:56kennylevinsen: ah
10:57kennylevinsen: 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
10:57swick[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
10:59swick[m]: and the justification is: others support this protocol, therefore it's reasonable to force everyone else to support the protocol
10:59swick[m]: and I don't agree with that
10:59JoshuaAshton: 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?
10:59JoshuaAshton: 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."
11:00swick[m]: yes, you won, because you're not willing to consider anything else, mutter will expose the leasing protocol
11:00JoshuaAshton: 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
11:00JoshuaAshton: I don't think I won anything, I just think there was no interest from anyone else right?
11:00JoshuaAshton: Like that is literally what I was saying right? That we should have a standard we all agree on?
11:01swick[m]: but we don't agree
11:01pq: who's working on the next major revision of the Wayland drm leasing extension?
11:02pq: I see drm-lease-v1 in staging, so it's perfectly fine to make another major revision as necessary.
11:03mclasen: you can't fix "this shouldn't be a wayland protocol" with a new revision of a wayland protocol
11:03JoshuaAshton: 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.
11:04pq: mclasen, oh, it was that deep? Hm.
11:04swick[m]: I don't agree
11:05JoshuaAshton: 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
11:05mclasen: thats always the core of the disagreement, isn't it?
11:05daniels: pq: yes, it's 'portals should be the primary API for applications' vs. 'I should never have to use D-Bus for anything'
11:06swick[m]: some compositors refuse the implement dbus things, so if we can all agree on something, it must be wayland
11:07swick[m]: iow, getting everyone to agree on a dbus protocol is impossible if some people refuse to use dbus for anything
11:07pq: aha, that doesn't seem solvable
11:07JoshuaAshton: and we can do handshakes in Wayland which the protocol already has
11:07JoshuaAshton: so plenty of room for whatever auth
11:07swick[m]: JoshuaAshton: so when you say, oh, just convince everyone else, that is impossible to do
11:07swick[m]: which you know
11:08JoshuaAshton: swick[m]: Then you have your answer then as to what to do? :P
11:08swick[m]: no, then your requirement is unreasonable
11:09swick[m]: because that means we're only ever allowed to do IPC with wayland
11:09JoshuaAshton: I don't think my requirement of "we should converge on an API for something" is unreasonable
11:09kennylevinsen: 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
11:09JoshuaAshton: ^
11:09feaneron: swick[m]: wouldn't say "won" as a portals / session service approach is still on the table
11:10swick[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
11:10swick[m]: but you're not honest enough to say that
11:10alice: mean thing to say
11:10mclasen:suggests that the drm lease case is water under the bridge
11:11pq: swick[m], careful there. Maybe have a break, get lunch, or something?
11:12emersion: yeah, i don't see this discussion being productive here. let's stop for now
11:13JoshuaAshton: 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. :(
11:21ifreund: 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
11:21ifreund: s/behavio/behave/
11:34swick[m]: JoshuaAshton: sorry, shouldn't have said the last part
11:42zamundaaa[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.
11:43pq: zamundaaa[m], sure. I just couldn't think of anything else this morning. Would you like to add another example?
11:48zamundaaa[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
11:50pq: I know nothing of win32.
11:51pq: purely client side Xwayland would include set_position(x,y), wouldn't it?
11:53zamundaaa[m]: I have some hope that you can get relatively far without it, but it might need it, yes
11:53ifreund: how would override redirect stuff work without it?
11:53zamundaaa[m]: ifreund: that's simple: it wouldn't
11:54zamundaaa[m]: I'm not convinced compatibility layers need to support every use case
11:54pq: aren't all menus and tooltips O-R windows?
11:54ifreund: don't basic stuff like dropdown menus use override redirect?
11:55pq: I think at least traditionally they were.
11:55JoshuaAshton: Yes
11:55JoshuaAshton: but not all of them
11:55JoshuaAshton: Some of them are just normal toplevel windows :(
11:55ifreund: hahaha
11:56zamundaaa[m]: pq: you don't need global positioning to make those work though
11:56JoshuaAshton: bool valid_maybe_a_dropdown =
11:56JoshuaAshton: w->maybe_a_dropdown && ( ( !w->is_dialog || ( !w->xwayland().transientFor && win_skip_and_not_fullscreen( w ) ) ) && ( w->skipPager || w->skipTaskbar ) );
11:56JoshuaAshton: return ( valid_maybe_a_dropdown || win_is_override_redirect( w ) ) && !win_is_useless( w );
11:56JoshuaAshton: from Gamescope
11:56pq: zamundaaa[m], oh?
11:56JoshuaAshton: https://github.com/ValveSoftware/gamescope/blob/master/src/steamcompmgr.cpp#L3206
11:56zamundaaa[m]: pq: I'm saying the compat layer would have to use heuristics to detect what the app actually wanted to do
11:56JoshuaAshton: yeah
11:57emersion: sadly a lot of windows don't set these
11:57mclasen: we've used o-r windows and absolute positioning to (poorly) simulate xdg-popover client-side in gtk
11:57JoshuaAshton: emersion: Yeah, even then Gamescope isn't 100% perfect
11:57JoshuaAshton: Because some apps give you literally 0 info
11:58emersion: :shock:
11:58emersion: no 100% perfect? what are you waiting for? :P
12:28MrCooper: "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?
12:30kennylevinsen: I recall DemiMarie often talking about something written in OCaml that did just that
12:30ofourdan: yeah, same here, I kept trying to make sense of it but couldn't
12:30JoshuaAshton: O🐪
12:31kennylevinsen: 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
12:32emersion: smh, it's writen お🐪
12:32MrCooper: AFAIK there's only one Xwayland-specific Wayland protocol request so far, which isn't really required
12:32colinmarc: kennylevinsen: like... gamescope?
12:32kennylevinsen: Ah yes, honarary camel
12:33emersion: colinmarc: except more tightly integrated because not rootful
12:39ofourdan: ah that would be https://github.com/talex5/wayland-proxy-virtwl (the "something" ocaml in-between)
12:40colinmarc: emersion: thank you, I hadn't understood the distinction until now. I wonder if I should be doing rootful
12:41kennylevinsen: rootful "just works", as Xwayland just makes a window and acts like a plain old wayland client
12:41kennylevinsen: especially after recent improvements from ofourdan
12:41colinmarc: my thing is fullscreen only, so that sounds appealing
12:41ofourdan: it's missing a dedicated bridge client for copy/paste between the inner X11 clients and threst of the world.
12:42ofourdan: (Xwayland rootful, I mean)
12:52ifreund: yeah, that's the only real pain point I had though last time I used it
12:52ifreund: it was very useful to get some pita java swing application working
12:52emersion: it would be kinda nice to have the clipboard stuff in xwayland itself
12:52emersion: so that compositors don't need to re-implement it
12:53ofourdan: I reckon it's a minefield
12:53emersion: X11 clipboard is a minefield, no doubt
12:54ifreund: it would be very nice indeed
13:25wlb: wayland-protocols Issue #195 opened by Sebastian Wick (swick) Specify behavior for destroying a wp_image_description_v1 before committing https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/195
13:25swick[m]: grrr, stupid gitlab
13:27wlb: wayland-protocols Issue #195 closed \o/ (Specify behavior for destroying a wp_image_description_v1 before committing https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/195)
14:22wlb: wayland Merge request !388 opened by Julian Orth (mahkoh) protocol: add wl_fixes interface https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/388
16:03Company: (where) does Wayland handle YUV properties like full/narrow range, chroma filter and location? Basically the stuff in https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkSamplerYcbcrConversionCreateInfo.html ?
16:04colinmarc: 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
16:05colinmarc: just mentioning that since I got stuck on it for a long time...
16:06colinmarc: oh, you asked about wayland, not vulkan. I read too fast
16:07emersion: Company: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183
16:07Company: I didn't even think about yet how tf tf work with yuv
16:07emersion: Company: but for the chroma filter i'm not sure what's the right thing to use
16:08Company: I'm trying to figure out how I'd model GTK API for it
16:08emersion: currently i use VK_FILTER_LINEAR
16:08rIMpossible: Hello. I want to try/use wayland on OpenBSD 7.5. I get the following error, when starting sway:
16:09rIMpossible: 00:00:00.100 [wlr] [render/allocator/allocator.c:66] Failed to open DRM node '/dev/dri/renderD256': No such file or directory
16:09rIMpossible: 00:00:00.100 [sway/server.c:158] Failed to create allocator
16:09Company: I think I use NEAREST because some GPUs can't do LINEAR
16:09emersion: but some drivers don't support that for some formats
16:09emersion: yeah
16:09emersion: i don't know if that matters
16:09emersion: pq, do you know?
16:09Company: for people watching videos: probably not
16:09emersion: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/render/vulkan/renderer.c?ref_type=heads#L1783
16:10Company: for people who care about accuracy: probably a lot
16:11Company: oh, I do use LINEAR
16:11emersion: 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?
16:11Company: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gsk/gpu/gskvulkandevice.c#L787
16:12Company: it's fun how everyone uses different values
16:12Company: mutter's shaders us R.709 narrow, you use R.601 narrow and GTK uses R.601 full
16:12Company: I still wanted to check what GLES uses by default
16:12emersion: iirc i've asked here about the rest of the params
16:15colinmarc: 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
16:16Company: I've used 601 because ffmpeg deemed it the default in their code
16:16Company: and because it looked better with my webcam ¯\_(ツ)_/¯
16:16wlb: wayland/main: Chloé Vulquin * xcursor: catch theme inheritance loops https://gitlab.freedesktop.org/wayland/wayland/commit/16aee2ec3829 cursor/xcursor.c
16:16wlb: wayland Issue #317 closed \o/ (cursor: Theme that inherits itself causes infinite recursion https://gitlab.freedesktop.org/wayland/wayland/-/issues/317)
16:17wlb: wayland Merge request !376 merged \o/ (xcursor: prevent recursive inherit loops https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/376)
16:17YaLTeR[m]: mpv has a bunch of heuristics based on video resolution I believe
16:18Company: yeah, I'm not doing that
16:18Company: I want to make it explicit anyway
16:19Company: but I'm currently wondering if I just stuff everything into a "Colorstate" object or if I have different objects for this
16:19Company: like Wayland with color-managemenet vs color-representation
16:21wlb: wayland/main: Simon Ser * Add support for the deprecated-since XML attribute https://gitlab.freedesktop.org/wayland/wayland/commit/ee12e69b8fb8 protocol/wayland.dtd src/scanner.c
16:21wlb: wayland/main: Simon Ser * protocol: mark wl_pointer.axis_discrete as deprecated https://gitlab.freedesktop.org/wayland/wayland/commit/da8e1bbc45bd protocol/wayland.xml
16:21wlb: wayland/main: Simon Ser * tests: add deprecated-since attributes https://gitlab.freedesktop.org/wayland/wayland/commit/80c65f862f79 tests/data/ small-client-core.h small-client.h small-code-core.c small-code.c small-private-code.c small-server-core.h small-server.h small.xml
16:22wlb: wayland Merge request !329 merged \o/ (Add support for the deprecated-since XML attribute https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/329)
16:22colinmarc: @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)
16:22wlb: wayland Issue #462 opened by Daniel Hill (YellowOnion) Wayland needs more precise timers. https://gitlab.freedesktop.org/wayland/wayland/-/issues/462
16:25colinmarc: so the main mistake to avoid is thinking "the primaries are BT.709, that must mean the YCbCr encoding is also BT.709"
16:25colinmarc: I would want whatever API to make clear the distinction, and that's easier if they're next to each other I guess
16:30JEEB: YaLTeR[m]: I think there should just be one switch on resolution: BT.601 vs BT.709 matrix / primaries for untagged YCbCr
16:30JEEB: since you have no idea of knowing what otherwise stuff is :D
16:30wlb: wayland/main: Simon Ser * client: fix invalid doc command for WL_MARSHAL_FLAG_DESTROY https://gitlab.freedesktop.org/wayland/wayland/commit/6e1db5391685 src/wayland-client-core.h
16:30wlb: wayland Merge request !383 merged \o/ (client: fix invalid doc command for WL_MARSHAL_FLAG_DESTROY https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/383)
16:34wlb: wayland/main: Sebastian Wick * protocol: define content updates and their internal queue https://gitlab.freedesktop.org/wayland/wayland/commit/9069af78a71f protocol/wayland.xml
16:34wlb: wayland Merge request !379 merged \o/ (protocol: define content updates and their internal queue https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/379)
16:42wlb: wayland/main: Derek Foreman * client: print debug events that have no listener https://gitlab.freedesktop.org/wayland/wayland/commit/e60c631ff286 src/wayland-client.c
16:42wlb: wayland Merge request !385 merged \o/ (client: print debug events that have no listener https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/385)
16:44Company: 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 :/
16:47swick[m]: Company: and if you get direct scanout you get another chance of everything being wrong
16:48Company: swick[m]: yeah, but that's not my problem :)
16:49swick[m]: and the TF sometimes has to applied before and sometimes after the matrix
16:56colinmarc: swick: when before?
16:56JEEB: was it the constant luminance stuff or ICtCp?
16:56swick[m]: yup
16:57colinmarc: ah BT2020-CL?
16:57colinmarc: right
16:57JEEB: effectively I haven't seen constant luminance BT.2020 being utilized, everyone using NCL
16:58Company: 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?
17:00Company: so basically YUV buffers should be treated like some form of compression where some compressor properties are named after colorspaces?
17:04colinmarc: <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?
17:05colinmarc: 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
17:06colinmarc: thinking of YUV as extra compression makes the most sense to me as well
17:08colinmarc: I just opened a vulkan spec issue on the YCbCrSamplerConversion issue btw https://github.com/KhronosGroup/Vulkan-Docs/issues/2356
17:08colinmarc: since that's a massive footgun
17:10Company: it's also a weird space where nobody really cares if it works properly, so people don't file bugs
17:10Company: unless it's the few people who really care
17:10Company: but they are usually in their own space with their custom software
18:47JoshuaAshton: Company: I don't think that's true at all wrt. Vulkan
18:47JoshuaAshton: colinmarc: Yeah it does not apply a TF -- just primaries fwiu.
18:49Company: what isn't true at all?
18:59swick[m]: one cannot apply primaries
19:06Company: all those properties just select a matrix for converting from a yuv vec3 to an rgb vec3
19:06Company: what that vec3 then means is up to the app
19:07mclasen: swick[m]: depends on whether we're discussing monitors or nail polish
19:10swick[m]: are they really called primaries, not primers or sth like that?
19:15mclasen: primer is usually applied to the face
19:15mclasen: I wasn't serious anyway, sorry for the distraction
19:15alice: i've never heard any part of nail polish be called a primary
19:15alice: but i can see it i guess
19:36Company: Google is very helpful here. I learned that the primary cosmetic is the thing that goes into the weapon slot
22:01jensen9: 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
22:01jensen9: compositor)? of course fractional scaling should be avoided where possible
22:22d_ed[m]: no. On Qt and GTK scaling is applied for all painting
22:29kennylevinsen: fractional scaling is also done by the app when supported, rather than "by the compositor" in post