04:27 kchibisov: KALT: I've fixed your issue, but ensure that you do `with_transparency(true)` when building a window, since the default is false.
05:47 KALT: Thanks kchibisov.
08:32 emersion: jadahl: re !68: does that count as review or ack or none?
08:34 jadahl: emersion: i'd say review, since i've been reviewing it
08:34 emersion: ty
08:34 jadahl: raising issues that you've addressed etc
08:34 jadahl: so thanks for that
08:35 emersion: sorry the process has been so cumbersome, thank you for bearing with me
08:36 emersion: okay, so next up is collect 2 ACKs
08:37 emersion: zzag, drakulix[m], RAOF: would you be interested in ACK'ing !68?
08:37 jadahl: i'll nag for some extra review on the flatpak mr
08:38 emersion: please remember that an ACK does not need the same amount of effort as a proper review :)
08:38 emersion: nice
08:41 emersion: link to said MR: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68
08:43 pq: jadahl, tempting but flammable.
08:44 jadahl: pq: with the right amount of gif animations, it might work
08:47 pq: daniels, looks like all the "do this first" special wording for wl_surface.attach dx,dy was not explicitly carried over for wl_surface.offset, but wl_surface.offset does say it is semantically equivalent to attach dx,dy.
08:48 pq: daniels, wl_surface.commit spec has a clear answer.
08:51 emersion: jadahl: and btw would you also be interested in acking for mutter?
08:51 pq: Oh, offset on the child instead, that's a slightly different case. set_position is applied on parent commit, attach is applied on child commit, so depend on the commit order, I'd say.
08:52 pq: and application order
08:53 pq: set_pos definitely does stomp the offset if applied later
08:53 jadahl: emersion: isn't a review an implicit ack?
08:54 emersion: I'll take it :)
08:54 pq: no, you cannot ignore it
08:55 pq: it all depends on what commits were done on which surfaces with what state changes
08:56 emersion: pq, i'm not sure what you're replying to
08:56 emersion: "you cannot ignore it" → compositors cannot ignore the offset request for sub-surfaces?
09:05 pq: emersion, correct. Client can issue a protocol sequence where ignoring for a sub-surface would be visibly different behavior from the spec.
09:06 pq: low-level mechanical protocol, boo
09:06 emersion: well, that's not how implementations do it
09:07 pq: *shrug*
09:07 emersion: and we were talking about changing the spec to make all compositors ignore the offset
09:07 pq: ok, but it's a spec change, not a clarification
09:08 pq: so better make sure everyone has always done the same way
09:09 pq: We have, for example, this statement in the spec for sync'd sub-surface: "The cached state is applied to the sub-surface immediately after the parent surface's state is applied."
09:10 pq: that might actually result in non-sensical behavior, given that set_position is parent state and offset is child state
09:10 pq: but it is unambiguous
09:10 wlb: wayland Merge request !324 opened by Simon Ser (emersion) protocol: fix whitespace https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/324
09:12 pq: I'm happy if you can fix these things by writing a better spec, but I always worry that such change will cause a regression for someone somewhere, and the whole creditibility of Wayland depends on not breaking things randomly after we have defined how it must work.
09:12 pq: *credibility
09:13 pq: and that makes me the PI in your TA :-)
09:28 daniels: pq: when you speak about a 'clear answer', are you saying that 'If there is no pending wl_buffer, the coordinates [for any request other than attach] are relative to the current surface contents' suggests that a commit with damage but no attach refers to the currently-attached buffer?
10:01 wlb: wayland-protocols Merge request !215 closed (staging: add surface suspension protocol)
10:03 pq: daniels, surface contents != buffer, they are two different "objects".
10:05 pq: I'm not sure what the question is.
10:07 daniels: pq: the question is - if a client calls wl_surface_attach(surf, buf, 0, 0); wl_surface_damage(surf, ...); wl_surface_commit(surf); wl_surface_damage(surf, x, y, w, h); wl_surface_commit(surf); - should the second commit apply (x,y)->(w,h) damage to surf resulting in re-sourcing the content from buf?
10:08 pq: I would say no, because the compositor *might* have already released the buffer from the first commit.
10:09 daniels: I agree with your assertion, which is why I asked what you were meaning - to me, it's clear that it implies that calling e.g. wl_surface_set_input_region() without an intermediate attach is fine, and that the co-ordinates passed apply in the way you'd think they would, and it's also clear (because, as you say, current surface contents != buffer) that the above scenario is UB at best
10:09 daniels: yes
10:09 daniels: that's where I thought we'd landed yesterday, but your question made you think you might be interpreting that sentence in wl_surface.commit differently :)
10:10 pq: I was talking about the sub-surface set_position vs. offset, if I guess what question you mean
10:13 daniels: oh, iswym
10:14 daniels: sorry, for some reason half the backlog was just missing when I loaded it this morning - seeing your conversation with emersion now it all makes much more sense
10:15 pq: heh
10:21 emersion:TIL "FSVO"
10:23 jadahl: me too, but I don't know what Food Safety and Veterinary Office has to do with subsurfaces
10:24 daniels: ha
10:24 daniels: 'for some value of'
10:25 jadahl: daniels: ambiguous, and not the top search result, but sure
10:26 emersion: it is first result in Urban Dictionary, at least
10:27 emersion: i mean, the first result for "TIL" is til-technologies.fr
10:27 emersion: .. and then "Transports interurbains de la Loire", i guess my locale weights a bit here
10:33 jadahl: emersion: tbf, the second result was correct and from wiktionary
10:34 jadahl: but seems google is confusing sweden and switzerland here or something, because I don't care about any swiss government agencies
10:38 kennylevinsen: easy mistake to make
10:39 kennylevinsen: banking and falukorv, same same
10:39 zzag: with wayland/wayland-protocols!68, is the compositor supposed to check whether wp_security_context_manager_v1 is bound by a sandbox?
10:39 zzag: if so, how?
10:40 emersion: i mean both are regions of the beautiful country of Europe
10:40 emersion: zzag: the compositor has the choice between two strategies
10:41 emersion: - assume no security context means no sandbox, which is incorrect on current sandbox impls but not more wrong than the status quo (sway)
10:42 zzag: my second question is: what problem does the protocol solve?
10:42 zzag: I don't quite follow the motivation behind the protocol
10:42 zzag: perhaps I should have asked that in the MR
10:43 emersion: - add racy sandbox-specific logic to check whether a client is flatpak or not, only allow the client to create a flatpak security context if that check succeeds
10:43 emersion: (mutter already has flatpak-specific logic, so could do that)
10:43 drakulix[m]: I guess the idea is giving sandboxed clients a less privileged sockets? (E.g. hide some globals?)
10:44 zzag: example?
10:44 emersion: the motivation is to be able to tell when a client is running in a sandbox in a secure and non-racy way, and provide a sandbox-agnostic way to get basic metadata about that client
10:44 jadahl: drakulix[m]: point is primarily to avoid the PID reuse race. mutter already knows if a client is flatpak/snap so it'd be more about the theoretical race
10:44 drakulix[m]: got it
10:45 emersion: so yeah, compositors can then take policy decisions based on the metadata provided by the protocol
10:45 drakulix[m]: So assuming you trust the sandbox, you could also e.g. have permissions to enable certain globals based on the app_id.
10:45 emersion: one example would be to hide the layer-shell global, for compositors implementing this
10:45 emersion: another example would be to restrict keyboard-shortcuts-inhibit
10:46 jadahl: emersion: keyboard shortcut inhibit is used by most remote desktop and virtual machine viewers
10:46 emersion: yeah, and one could only allow these apps to use it
10:47 emersion: and not allow other unsandboxed apps
10:47 jadahl: true
10:47 emersion: the reason it's opt-in, rather than opt-out, is to reflect the reality that unsandboxed clients can mess up your system without going through the trouble of using wayland (echo bad >>~/.bashrc)
10:47 zzag: emersion: hmm, I see. although I'm not sure that hiding "privileged" globals is always the case. for example, layer-shell still makes sense for some apps that operate in overlay mode
10:47 zzag: e.g. your slurp app
10:47 zzag: or for third party screenshot tools
10:47 zzag: where you want to show an overlay
10:48 emersion: zzag: yes, so, my plan is to hide the globals as the first step
10:48 emersion: then as a second step, add a way to expose these globals to allow-listed sandboxed apps
10:49 emersion: you don't necessarily need to hide the globals, you can deny/ignore protocol requests if you prefer a more dynamic setup
10:50 zzag: "then as a second step, add a way to expose these globals to allow-listed sandboxed apps" that makes sense, especially if sandbox/flatpak is responsible for that
10:50 emersion: yeah, i've not yet looked too much into flatpak's permission store, but maybe could use that
10:50 zzag: "especially if sandbox/flatpak is responsible for that" i.e. flatpak reading app metadata and asking for those globals
10:51 emersion: (https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.impl.portal.PermissionStore.xml)
10:52 emersion: yeah, i'm not that far into the Future™ yet, but that'd be nice for sure
10:53 emersion: my immediate goal is to remove the ability for Zoom/Teams/other proprietary sandboxed apps to have unrestricted access to our protocolsd
10:54 drakulix[m]: Why is the order of operations first to send the fd, then the metadata?
10:54 emersion: to make the metadata extensible
10:54 qyliss: my use cases for this protocol in a security-focused are: restricting access of (non-allow-listed / granted permission at runtime) sandboxed applications to certain compositor features (clipboard, fullscreen, screenshot, etc.), and for securely identifying different applications, so I can do e.g. Qubes-style coloured window decorations to differentiate between different sandbox
10:55 emersion: can add more metadata requests
10:55 qyliss: instances.
10:55 emersion: if we want to invent another mechanism which doesn't use the FD, we can add a new request on the global which creates the metadata object
10:56 drakulix[m]: ok, makes sense.
10:56 drakulix[m]: So realistically a compositor has to wait for commit on the context before it can really accept connections on the fd, right?
10:57 drakulix[m]: At least if it wants to take the metadata into account.
10:57 emersion: yes, a compositor would stash the FD somewhere and only start listening on commit
10:57 emersion: that's what the wlr impl does
10:59 zzag: emersion: I will check with d_ed on the protocol and either he or I ack it
10:59 emersion: ty!
11:01 pq: drakulix[m] said "wait for commit" - is there some strange character just before the word "commit"? It shows as reverse-video "Q" in irssi, and I've seen it occasionally, maybe from Matrix bridges?
11:02 drakulix[m]: I put commit in backticks, like markdown code formatting. (Which is how it is rendered in Element.)
11:02 drakulix[m]: Does that break when send over the bridge?
11:02 pq: I see no backticks at all
11:02 emersion: maybe it tries to convert to ANSI formatting codes
11:02 drakulix[m]: but why...
11:03 emersion: https://modern.ircdocs.horse/formatting.html#monospace
11:04 emersion: (my clients interprets it correctly, but maybe older clients don't)
11:04 pq: :facepalm:
11:04 pq: my terminal is already monospace, thank you irccloud
11:05 drakulix[m]: So do we blame clients or should I try to avoid that in the future?
11:06 emersion: ideally that would've been an IRCv3 cap that one needs to opt-in to
11:06 emersion: but was well before my time
11:06 pq: I guess I'll just mentally ignore it, and hope that Debian Bookworm contains a version of irssi that just strips it, or converts back to backticks.
11:07 emersion: i'd suggest opening an irssi issue if it's not fixed, since that ship has already sailed…
11:08 pq: looks like irssi 1.4.4 changelog has "support receiving monospace"
11:09 emersion: nice
11:09 pq: bookworm has 1.4.3
11:09 pq: well, one day
11:12 emersion: \o/ got an ACK
11:13 emersion: ty drakulix[m]
11:14 drakulix[m]: np. I was already looking forward to this protocol, I just had to get up-to-date. 🙂
11:44 wlb: wayland-protocols Issue #147 opened by Mark Bolhuis (markbolhuis) input-timestamps: Clarify interaction between relative-pointer and wl_pointer.frame https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/147
12:46 wlb: weston Merge request !1282 opened by Pekka Paalanen (pq) Simple build fixes in the Sphinx sub-tree https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1282 [Build system]
12:58 kchibisov: If compositor wan't to maximize/fullscreen my client, can I somehow indicate that I don't want/can't?
12:58 kchibisov: I could ignore size change, but some still makes me fullscreen, centered around the black content.
13:00 emersion: mark as not resizable?
13:01 kchibisov: if you mean by that set min and max sizes to the same values, I think I've still seen fullscreen.
13:04 kennylevinsen: min/max is just a hint, so while it might be silly for a compositor to allow a non-resizable client to fullscreen, a client must deal with it anyway
13:04 pq: I might call that a compositor bug, even if protocol allows it. It's not nice to exceed size hints.
13:04 kennylevinsen: exceeding size hints is normal, e.g. tiling
13:04 kennylevinsen: in both directions
13:04 pq: ugh
13:05 pq: still not nice
13:05 kennylevinsen: although tiling compositors also take min == max as hint for modal that become floating by default
13:05 pq: modal?
13:05 pq: is that really used to imply modal?
13:06 vyivel: regarding maximized state, it's an error to disobey the size received from the compositor
13:06 pq: yes
13:07 kchibisov: So a dialog menu, which sets min/max sizes to the same value, should still somehow deal with resize.
13:07 kennylevinsen: modal is the wrong word, but its used to deduce that this is a floating window ala file save prompts
13:08 kennylevinsen: ("Similarly, a tiling window manager may use this information to place and resize client windows in a more effective way.")
13:09 vyivel: kchibisov: the client doesn't have to ack a configure
13:09 emersion: it has to…
13:09 kchibisov: The client must also acknowledge configure events using "ack_configure
13:09 kchibisov: ¯\_(ツ)_/¯
13:10 vyivel: hm, i think gtk programs don't ack sizes less than min size...? unless i misremember
13:11 kennylevinsen: vyivel: an ack is implicitly an ack of every prior configure, so to not ack one you'd have to never ack ever again
13:11 kennylevinsen: wayland client tantrum
13:11 vyivel: you can ignore them until you get a state you support
13:12 pq: I would have expected to have new xdg-surface sub-roles than deducing anything from size hints.
13:13 kennylevinsen: pq: note: xdg_toplevel parent association is also used as hint for the same
13:13 kennylevinsen: it's a lot of toplevels that would have to use the new role though
13:14 pq: using parent association is fine
13:14 kennylevinsen: every file dialog, save or password prompt, etc.
13:14 kchibisov: well, we have wm_capabilities, could do client_capabilities.
13:14 kchibisov: but that's probably stupid.
13:14 kennylevinsen: but roll-out difficulty aside, I wouldn't mind clearer communication
13:14 pq: wm_capabilities?
13:15 kchibisov: wm_capabilities (v5 event).
13:15 kchibisov: Tells the client what compositors supports or not.
13:15 pq: aha
13:15 kchibisov: Could do inverse of it.
13:16 kennylevinsen: is your issue just that you have a dialog you'd prefer not to be fullscreen, or that you want a mechanism to block arbitrary fullscreening?
13:16 kchibisov: kennylevinsen: yes, some kind of.
13:16 kennylevinsen: "a or b" "yes"
13:17 kchibisov: I choose "a".
13:17 kchibisov: Though, the user I have want "b" for maximize.
13:18 kchibisov: And I was told that at least on some systems you have ways to mark window 'not maximizable'.
13:18 kennylevinsen: just asking, 'cause i'd prefer not to define "compositor must never" behavior here
13:20 kchibisov: Though, we could have a way to mark a window not resizable or user resizable only.
13:20 kennylevinsen: i.e., telling the compositor it is a dialog so it can do whatever it does for dialogs is good, saying "dialog cannot be tiled/fullscreen" is bad
13:22 kennylevinsen: for example, my compositor is strictly tiling in a plan9-esque way where toplevels are placed in user pre-defined "containers". The window has no say in the matter, and size hints are not considered.
13:22 kennylevinsen: dialogues just replace their parent as the sole content of the container until they are closed, but they are tiled all the same
13:22 kennylevinsen: weird, yes, but I'd prefer for that to not suddenly become a protocol violation
13:23 kchibisov: I still don't understand why users can't handle resizes.
13:23 emersion: i don't really understand what problem you're trying to solve, kchibisov
13:23 emersion: we already have "not resizable"
13:23 kchibisov: emersion: the user wants to prevent all ways to maximize a window.
13:23 pq: by users you mean apps/clients?
13:23 pq: not actual users
13:24 kchibisov: The actual users of the library, because they have something like that with Qt
13:24 kennylevinsen: as contrarian example, users of my compositors want all toplevels to be "maximized", full stop
13:24 kennylevinsen: s/compositors/compositor/
13:24 pq: right, so "we could do this with X11, we want it with Wayland too"
13:25 kchibisov: it's more like, I can do that with Win32, but you've got the point.
13:25 kchibisov: emersion: you mean that compositor treats min/max hints?
13:26 kchibisov: kennylevinsen's compositor doesn't bother for example, so…
13:26 kennylevinsen: exactly, which is how it should be
13:26 kennylevinsen: this allows the user to have the wanted behavior, rather than forcing the client developer's choice that may not fit with the intended usage
13:27 kchibisov: I set min/max hints as well, but I know that it's a recommendation.
13:28 kennylevinsen: while that could be more explicit, telling the server it is a dialogue some way is all that is needed. the server can then implement behavior that is appropriate for that environment/user choice/etc.
13:28 kennylevinsen: this could mean blocking fullscreen, or it could mean not caring - depends on the user/DE/whatever
13:31 wlb: weston/main: Pekka Paalanen * doc: set language for Sphinx https://gitlab.freedesktop.org/wayland/weston/commit/2da397c5dabd doc/sphinx/conf.py.in
13:31 wlb: weston/main: Pekka Paalanen * build: use project_source_root() https://gitlab.freedesktop.org/wayland/weston/commit/bd794a01490a doc/sphinx/meson.build
13:31 wlb: weston/main: Pekka Paalanen * build: use full_path() https://gitlab.freedesktop.org/wayland/weston/commit/d65e819bf764 doc/sphinx/meson.build
13:31 wlb: weston Merge request !1282 merged \o/ (Simple build fixes in the Sphinx sub-tree https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1282)
14:02 wlb: weston Issue #764 opened by Philipp Zabel (pH5) gl-renderer: Vertex clipping optimizations break rendering of rotated clients https://gitlab.freedesktop.org/wayland/weston/-/issues/764
14:43 sewn: hi, is this the correct channel for wayland development? i am currently trying to make a wayland application but i'm getting some errors i can't solve
14:43 qyliss: This is the channel for Wayland development.
14:44 sewn: ok cool um
14:44 qyliss: (but not for toolkit specific questions, etc.)
14:45 sewn: https://termbin.com/0qck why does this program get a segfault?
14:45 sewn: it particularly happens at wl_registry_bind when handling the compositor interface
14:46 daniels: because data == NULL, which is because you passed NULL as the last argument to wl_registry_add_listener()
14:47 sewn: how can i pass the client_state struct in main?
14:47 sewn: to it i mean
14:47 sewn: ah i see, &state, thanks alot
14:48 sewn: another question, do i pass the state registry (state->registry) to wl_registry_bind or the given registry argumene in handle_global?
14:50 daniels: they're they same thing, so either is fine
14:52 sewn: okay thanks
15:38 sewn: what is this weird "listener function for opcode 2 of xdg_toplevel is NULL" error? i'm pretty sure i filled out most of the listeners with their functions
15:41 daniels: you didn't fill out the third entry of the listener you passed to xdg_toplevel
15:51 sewn: my xdg_toplevel_listener only has .configure and .close
15:52 daniels: presumably you're passing too high a version to bind then - you need to only pass the version you actually support
15:52 daniels: https://wayland-book.com is quite a good introduction which should help you
15:53 sewn: thanks! i have been looking for a tutorial for a while
19:21 wlb: weston Merge request !1283 opened by Loïc Molinari (molinari) gl-renderer: Make clip_transformed() surf parameter constant https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1283
19:37 DodoGTA: Why do Wayland clients call add_listener() for some objects while doing nothing with the events those objects provide?
19:38 DodoGTA: Here's one example of this: https://github.com/glfw/glfw/blob/3fa2360720eeba1964df3c0ecf4b5df8648a8e52/src/wl_window.c#L2780-L2783
19:39 DodoGTA: How is that different from not calling add_listener() at all?
19:45 emersion: yes, that listener is dead code
19:47 DodoGTA: emersion: Both SDL2 and GLFW have that listener code while winewayland doesn't (I'm trying to figure out mouse escape issues with winewayland)
19:53 emersion: it shouldn't make any different in behavior
19:53 emersion: difference*
19:54 kennylevinsen: I imagine it might just be habit in how they wrote the code - "this is what I did with all the others"
19:54 kennylevinsen: might not have been obvious that you don't need the listener
19:57 DodoGTA: I guess I should try removing it from SDL2 and see what happens then
20:17 bwidawsk: What is the expected behavior if you damage an attached buffer, then commit. The spec says damage effects the "pending buffer" but that's a bit ambiguous, I feel. Does damaging the attached buffer without attaching a new one do anything?
20:20 bwidawsk: RAOF: this ^^ pertains to https://github.com/MirServer/wlcs/blob/main/tests/frame_submission.cpp#L64. It's not a spec violation, but I believe the test is incorrect in what it intends to do
20:21 emersion: bwidawsk: we had this exact conversation… yesterday in this channel
20:21 bwidawsk: oops, I shall read the backlog
20:21 bwidawsk: funny timing
20:21 emersion: yeah :P
20:21 emersion: tl;dr
20:21 emersion: yes, you need to attach again
20:21 emersion: and make sure you're not damaging a buffer which hasn't been released
20:23 bwidawsk: RAOF: Do you agree the test is broken based on what emersion says ^^
20:23 bwidawsk: emersion: thanks for the tl;dr
20:27 bwidawsk: emersion: is there specific verbiage I should reference in a bug report on WLCS?
20:59 kennylevinsen: bwidawsk: damage applies to the pending buffer only. the pending buffer is explicitly cleared after commit, meaning that it is only valid between attach and commit
21:04 DodoGTA: emersion: I guess it's dead code after all (I removed the listener stuff and Xonotic works fine without cursor escape)
21:26 bwidawsk: kennylevinsen: yeah, I think "pending" in this case is a bit ambiguous, but I'm relatively new to wayland protocol.
21:27 bwidawsk: because even if you reuse the buffer, is it not pending?
21:29 kennylevinsen: bwidawsk: no, it is explicitly no longer pending after you call commit
21:30 kennylevinsen: bwidawsk: a pending buffer is what you assign with attach (i.e., nothing is pending beforehand), and there is explicitly no longer any pending buffer after commit (because it was made current)
21:30 kennylevinsen: so damage only has something to operate on immediately after attach and until just before commit
21:31 RAOF: bwidawsk: thanks for finding these! I'm a bit surprised that *Mir* doesn't fail these tests.
21:31 bwidawsk: There's nothing wrong with what it's doing
21:31 bwidawsk: afaict, it's not against spec
21:32 bwidawsk: kennylevinsen: I notice though damage without previous attach isn't mentioned as an error, but presumably it would have no effect
21:33 bwidawsk: RAOF: if you or someone you know is fixing, you are supposed to use damage_buffer now instead of damage, fyi
21:33 bwidawsk: RAOF: the only reason I noticed is because my compositor in a certain mode will only send frame callbacks if there is damage
21:34 bwidawsk: aiui, Firefox at least, probably others, will send frame requests without damage, so that would break
21:36 RAOF: Oh, yeah, that's why it passes. The test never actually submits a buffer, so we'll always send a frame event when asked 🤦‍♀️
21:37 RAOF: The damage bit is just a big noop
21:39 kennylevinsen: bwidawsk: it is undefined and makes no sense to attach without a pending buffer, irrespective of why there is none
21:39 kennylevinsen: there is no current error for it, so it is undefined behavior
21:40 kennylevinsen: uh
21:40 bwidawsk: s/attach/damage... gotcha
21:40 kennylevinsen: I mean, damage without a pending buffer of course :)
21:42 bwidawsk: has there been previous discussion about clients submitting a frame request and expecting a done event without any damage occurring anywhere on the composited frame?
21:45 kennylevinsen: yes, it should be send irrespective of whether any damage is submitted as it is a request to be notified when to draw the *next* frame