04:47 ellipticsaki: Hello, wayland newbie here. I am finding a way to pass the pointer event(especially click event) to the beneath of the window. I tried to create region and subtract the entire region, and use set_input_region. But it seems not working. Is this even possible or am I approaching wrong?
05:00 soreau: it should work, just make sure the compositor supports it and you're committing after setting the region. you might also have a look at the output with WAYLAND_DEBUG=1 to make sure the region is set to what you expect
05:20 ellipticsaki: soreau, thanks for the reply. I've checked the debug output and it is definitely commiting after the region is created. I bet the compositor does not support this kind of feature, and I want to check if really is. Can you give me an advice where can I find the handling logic in compositor?
09:12 MrCooper: colinmarc: I also recommend waiting for the acquire point to signal before using the buffer for anything; if you really want to wait on the GPU though, you first need to wait for a fence to materialize in the acquire point anyway, then it's basically the same as implicit sync
09:33 colinmarc: @_oftc_MrCooper:matrix.org I think I must have misunderstood something about that - right now I export the acquire point as a vulkan semaphore and then pass that to submit, and that's fast - all the waiting seems to happen on the GPU
09:34 colinmarc: I think I don't care about the case where the client is bugged, because my compositor is single-client and if the client dies or does something weird we tear down the compositor anyway
09:34 colinmarc: and it's all virtual so I do a "page flip" (send the frame to the encoder) whenever the client finishes rendering
09:35 colinmarc: is there any other reason to do the wait on the CPU?
09:35 colinmarc: (I based my gpu wait on the vulkan code in wlroots, and it seems to work well)
09:36 colinmarc: the reason I want to do frame scheduling in the first place is that I obviously limit the encoder to 60fps, so if the client is very fast then there's a bunch of input lag between when I get the buffer and when I encode it
11:18 latex: Does the Wayland protocol require compositors to implement compositing? Is there no way to use the traditional stack and repaint technique?
11:23 kchibisov: latex: what do you mean by _compositing_ here?
11:23 soreau: you could make a 'compositor' that is just an IRC server :P
11:24 kchibisov: like how you draw is up to you, but I'm mostly curious what they mean by compositing here, since likely not what it actually means.
11:24 soreau: I'm curious what's meant by 'stack and repaint' method
11:25 kchibisov: probably some X11 impl detail.
11:25 kchibisov: which would be also compositing to some sort.
11:26 kchibisov: I feel like they mean alpha blending or not, but won't guess further here.
11:26 soreau: I guess the only thing visual that might not be considered compositing is a single client.. more than one on the output at a time and you're composing a scene
11:27 kchibisov: if you mean direct scan out path then yes, it's not compositing.
11:27 kchibisov: but wayland compositor could render like that, as in you have a stack of full screen windows you swap betwee.n
11:28 kchibisov: and even then, not all clients could be scanned out.
11:28 kchibisov: Like if they have way too many subsurfaces, etc, etc.
11:29 soreau: but in wayland, clients have a way to tell the compositor that there are opaque portions where nothing needs to be rendered behind it (because the surface in front has opaque portions where alpha = 1.0), and weston uses this optimization unconditionally IIRC
11:29 kchibisov: yeah, I'm just saying if you have way too many subsurfaces, you won't be able to scan out.
11:30 kchibisov: doesn't matter whether they are opaque or not.
11:30 kchibisov: Like you'd need to blend them somehow regardless.
11:30 kchibisov: since they are in different buffers, but should be in one, or on planes in a specific order.
11:31 kchibisov: and you don't have that many overlay planes.
11:31 soreau: yea, shoulda said s/client/surface/
11:31 soreau: meaning no subsurfaces
11:32 kchibisov: like my gpu supports like 4 overlay planes iirc, so I have only like 4 terminals max scanned out at the time.
11:32 soreau: oh but wait, don't forget the cursor
11:32 soreau: have to draw that if you have a mouse or something
11:32 kchibisov: it's blended as well on a different level.
11:32 kchibisov: unless you have _software cursor_.
11:33 kchibisov: The thing is that scene is composed in this case as well, just all on a different level.
11:34 kchibisov: and with direct scan out it's also composed, but further up.
11:34 soreau: while we're specualting, my guess is that they want the desktop background 'beneath' all transparency and not what is 'actually' behind it
11:35 kchibisov: wayland doesn't block any of that, but that's speculation as well.
11:35 kchibisov: if you're talking about fake transparency on X11 that was done by screenshoting and making it benith the window, it's something else though.
11:36 kchibisov: compositor can do the exact same thing though, if they wanted to.
11:36 soreau: screenshotting, heh
11:36 soreau: but wayland xdg protocol says fullscreen surfaces must have black behind them.. seems kinda prudent
11:36 soreau: so if you call xdg spec 'wayland', then yea, kinda blocks stuff up
11:37 kchibisov: it doesn't say so though.
11:37 soreau: it doesn't say what?
11:37 kchibisov: that it should be black.
11:37 soreau: it doesn't anymore?
11:37 soreau:looks
11:37 kchibisov: it never did.
11:38 kchibisov: it says that other screen content not part of the same surface tree shouldn't be shown.
11:38 soreau: "The content of the border fill is undefined, but should be assumed to be in some way that attempts to blend into the surrounding area (e.g. solid black)."
11:38 kchibisov: it's a border when it doesn't fit.
11:38 kchibisov: like when you have to center the buffer.
11:38 kchibisov: The last paragraph is what you're looking for.
11:39 soreau: oh right
11:39 soreau: so the black is for the non-aspect-ratio matching surfaces
11:39 soreau: anyway, compositors are free to serve up client buffers how it sees fit - this is an overstep of the protocol IMHO
11:39 soreau: regarding the last paragraph
11:40 kchibisov: it's also (e.g. black).
11:40 kchibisov: not just black.
11:40 kchibisov: so what you use is up to use.
11:40 soreau: sure, but the last paragraph is gratuitous
11:40 kchibisov: you just should not show anything that is below the window, but if you use wallpaper of your compositor, it probably won't violate anything.
11:40 kchibisov: I mean, any other window that was below.
11:40 soreau: it violates the spec
11:41 soreau: which folks can argue they rely on for e.g. security
11:41 kchibisov: I mean, it's not a wayland client, but default background of compositor.
11:41 kchibisov: it's just, default background is some png.
11:41 soreau: no I mean showing whatever you want
11:41 soreau: what's below it, a shader, desktop background image, anything rendered
11:42 kchibisov: if compositor must always show black color under the window, it should be stated so.
11:43 soreau: "...the compositor must make sure that other screen content not part of the same surface tree (made up of subsurfaces, popups or similarly coupled surfaces) are not visible below the fullscreened surface." seems like this rules out even the simplest background image too
11:43 kchibisov: Like in my case you won't see anything else, other than a default compositor background fill.
11:43 soreau: but you're free to write some shader pixels
11:43 soreau: doesn't really make any sense
11:44 kchibisov: What I'm just saying is that black is not mandated anywhere.
11:45 soreau: and what I'm saying is the last paragraph should be omitted entirely
11:45 kchibisov: it shouldn't though.
11:45 soreau: it should :)
11:45 kchibisov: the point was to make that other wayland clients won't be rendered below the window.
11:46 kchibisov: if you want such behavior, you want other mode.
11:46 soreau: yes but that should not be enforced on a compositor
11:46 soreau: it's compositor policy/design decision, not protocol spec
11:46 kchibisov: Like there's a simple fullscreen concept usually in compositors, which is simpler.
11:46 kchibisov: as in you can stack above, etc, etc.
11:46 kchibisov: and see what is below.
11:47 kchibisov: it's not maximized, though, the window is fullscreen.
11:48 soreau: In wayfire, we ignore this altogether. Nothing stops showing what's behind a fullscreen semi-transparent surface. In addition, there's a 'force fullscreen' plugin that allows you to fullscreen windows that don't support resize/fullscreen at all. Regardless how it's fullscreened, it shouldn't matter what's behind it from spec POV
11:48 kchibisov: it does matter for perf.
11:49 soreau: but that's not for spec to decide
11:49 soreau: I should be able to pixman all day long if I want
11:49 soreau: or make a horribly slow shader
11:49 soreau: so it might be a good idea or a suggestion, but certainly shouldn't be enforced by some paragraph that's largely a security crutch
11:50 kchibisov: IIRC it was due to direct scan ou.t
11:50 kchibisov: But I could be wrong and it was actually a security thing.
11:50 soreau: yes but then it should be expanded to not enforce but suggest based on reasoning
11:50 soreau: not just 'hey, dont do this'
11:51 soreau: then a compositor dev will understand why to do this and not just blindly do it 'because spec said so'
11:53 soreau: (I would write a patch but I'd rather complain on IRC until someone with marge rights says 'hey, we would entertain a patch that improves the paragraph by changing it to xyz')
11:54 soreau: because the patch I'd like would be something like -3,+0
12:25 davidre: zamundaaa tried to make a patch
12:26 davidre: Some people were not happy
12:27 emersion: this has already been discussed and a different way forward has been suggested
12:28 soreau: regarding 'the paragraph'? link?
12:29 emersion: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/377
12:34 soreau: emersion: I guess the way forward you refer to is jadahl's most recent comment here? https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/377#note_2735819
12:35 emersion: the first comment was already a way forward
12:39 soreau: Well hopefully it doesn't remain stagnant. It's difficult to tell if the original merge requester is to write this or if it's to be superceded by another MR
13:38 pq: kchibisov, soreau, I would assume they referred to the core X11 model: each pixel on screen is owned by some Window at any time, and the server sends expose events to those Windows to tell them to paint themselves into the server's (front) framebuffer, e.g. a when window moves, other windows' parts get exposed.
13:39 pq: on screen, meaning, in the server framebuffer
13:40 soreau: brilliant speculative assumption
13:40 pq: "compositing" is more like: the server (or a compositing manager) has off-screen images of each window, and composes the final framebuffer from those rather than asking clients to issue draw commands that target the framebuffer.
13:41 pq: soreau, hm?
13:41 soreau: now let's write some specification for this model and call it.. xwayland!
13:41 emersion: fwiw, it wasn't entirely clear whether you were criticizing the core X11 model, or pq's message :P
13:42 pq: latex, Wayland has no protocol for expose events, nor requests for the drawing commands.
13:43 soreau: emersion: no criticism, just asserting that without further input beyond the initial query is speculation
13:44 pq: latex, Wayland fundamentally assumes that clients provide images of windows, and the server does whatever to produce the final framebuffer on its own.
13:45 emersion: soreau: ah, so, there are better ways to say that
13:45 emersion: your wording was rude here
13:45 soreau: emersion: well that was not my intent..
13:46 emersion: maybe "i'm not sure this was what they meant" would've been another way to say it?
13:46 pq: yeah, I read soreau as borderline insulting me. Good to hear it wasn't intentional.
13:46 soreau: well if that's what it came across as, I'm sorry
13:46 soreau:is bad at typing english
13:46 emersion: no worries, good to hear it wasn't intentional
13:47 pq: hazards of communication, no problem now
13:47 soreau: textual communication, even
13:49 soreau: but yea, I guess 'traditional' in wayland terms kinda implies X
13:53 soreau: but I still am wondering about the 'way forward' for the fullscreen paragraph.. how to know who will type up the suggestion into something acceptable?
13:55 emersion: ask if the original author has plans to do it, if not, do it?
13:58 soreau: emersion: ok
14:00 soreau: now I have a question about xdg_configure event.. does it require some special request for it to be sent?
14:01 MrCooper: colinmarc: see https://blogs.gnome.org/shell-dev/2023/03/30/ensuring-steady-frame-rates-with-gpu-intensive-clients/ for some rationale for waiting on the CPU
14:02 MrCooper: colinmarc: AFAIK a syncobj timeline point can't be converted to a Vulkan semaphore directly, presumably you mean the fence (sync_file) which materialized for the acquire point?
14:02 soreau: in my case, I commit a shm buffer every second and xdg_configure events are sent at this frequency. but, if I continually request frame events, then xdg_configure is called 'fluently'
14:03 colinmarc: MrCooper: I don't understand what you mean by "materialized", but yes, I think that's what I'm doing. exporting a sync fd and then importing that as a semaphore
14:04 soreau: if I try committing in xdg_configure, it still doesn't get another xdg_configure event until comitting outside of dispatch handling
14:05 soreau: at least, AFAICT
14:05 colinmarc: MrCooper: Thank you for sharing this! I feel pretty confident it doesn't apply to my case (single-client, no physical display blank to hit), is that wrong?
14:06 MrCooper: colinmarc: right, and exporting a sync_file works only once the fence has materialized, for which you need to wait on the CPU anyway; after that, the synchronization with the exported fence works essentially the same as implicit sync
14:07 MrCooper: colinmarc: I suppose that's a special case where it might not make any difference
14:08 colinmarc: > exporting a sync_file works only once the fence has materialized, for which you need to wait on the CPU anyway
14:08 colinmarc: I'm exporting right before render, which is sometimes a while after commit, so I wonder if I'm hiding a bug. what happens if it hasn't materialized yet? what is this materialization thing anyway?
14:08 MrCooper: colinmarc: if you don't wait for the fence to materialize, you've been getting lucky :) (actually there might be no client in the wild yet which attaches a buffer before the acquire point fence has materialized, the protocol allows it though)
14:10 colinmarc: how do I wait for a specific point to materialize? since I need to export the fd in order to poll it
14:11 colinmarc: if I need to introduce a cpu wait anyway, then yeah, I see your point about just doing all the waiting on the CPU
14:13 MrCooper: you can use drmSyncobjEventfd for this, the eventfd becomes readable when the syncobj timeline point fence has materialized
14:19 MrCooper: but yeah, why not just wait for the acquire point to signal, can use drmSyncobjEventfd (with 0 for flags) for that as well
15:07 wlb: weston Merge request !1689 opened by Robert Mader (rmader) Draft: color: update color-management protocol to wp-v1 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1689
15:13 kchibisov: pq: I'd assume hardware acceleration doesn't work in this shared model at all?
15:55 latex: kchibisov: I mean this: https://en.m.wikipedia.org/wiki/Compositing_window_manager
15:56 latex: soreau: this is stack and repaint: https://en.wikipedia.org/wiki/Compositing_window_manager#Contrast_with_stacking_window_managers
15:57 latex: Does Wayland require compositors to implement compositing? Or is there support for repaint messages like on X11?
15:57 kchibisov: in that sense you've got an answer, everything has its own buffer submitted and being composed by compositor.
15:58 colinmarc: @_oftc_MrCooper:matrix.org thanks for the help!
15:58 latex: And another thing, does compositing cause input lag compared to stacking/repainting?
15:58 latex: Because someone I know insists that it does
15:59 kchibisov: depends how it's done.
15:59 kchibisov: and it's also a matter of a different level.
16:01 latex: What does that mena?
16:02 kchibisov: it's a tearing/non-tearing thing.
16:03 kchibisov: it's true that with compositor model it's more likely to hit one frame of latency if you do things very naive.
16:05 kchibisov: To be more clear, if you use stacking model it also matters how your window manager (x11) communicates the buffer to the kernel.
16:09 daniels: when you enable compositing in X11, it introduces latency because of the very specific way that it was implemented for X11
16:09 kchibisov: x11 having latency here is no doubt.
16:09 daniels: this is not true of Wayland, and it is possible to achieve latency just as low as non-composited X11
16:09 kchibisov: it has nothing good when it comes to frame scheduling.
16:09 soreau: latex: in wayland, there are frame events that are sent to clients requesting it, for the compositor to tell the client that it's a good time to submit a new buffer and in most cases, the compositor renders the client surface buffer in the next frame which is basically asap, assuming there is no tearing allowed
16:09 kchibisov: or anything.
16:09 kchibisov: and what it has, doesn't work in 99% of the time for whatever reason.
16:10 daniels: as kchibisov says, 'compositing' really just means that every client submits full buffer contents, instead of maintaining only partial buffer contents - the repaint chain can be in fact even more optimal than X11's
16:10 kchibisov: submitted buffer is most of the time is just a reference to something old and you have a delta of changes.
16:11 kchibisov: and in some cases, the buffer is not even composed but used directly.
16:11 soreau: in a wayland compositor the display server and window manager are in the same process, so there isn't the trifecta of X/wm/client, there's just compositor/client
16:11 Ermine: i saw an article which stated that author had higher latency in plasma wayland than in plasma x11
16:11 kchibisov: Could be just a plasma thing.
16:12 kchibisov: Like I've debugged a frame of latency on gnome recently due to how alacritty used certain api.
16:12 kchibisov: it used it correctly, but it caused gnome to add frame of latency just for alacritty.
16:12 kchibisov: Like measuring latency is a _hard thing to do_.
16:13 kchibisov: and catching such things is also hard, since it's not that obvious and you need specialized hardware setup for such things.
16:13 Ermine: yeah
16:13 kchibisov: Like plasma could just have a bug on Wayland, but generally it's not a wayland thing or compositor specific thing.
16:13 kchibisov: compositor model specific thing*
16:14 Ermine: seems like it's hard to formalize how do people perieve things
16:14 kchibisov: I mean, you just use a light sensor based approach to measure things.
16:14 soreau: you can definitely be a wayland compositor and have worse latency than X, which is probably easy to do if you really wanted to
16:14 kchibisov: e.g. time from it inputing something from pixel changing on screen.
16:14 kchibisov: so a full system latency.
16:37 zamundaaa[m]: Ermine: then that author didn't actually do any measurements
16:37 Ermine: yes, it was a perception thing
16:37 zamundaaa[m]: I did roughly 3 years ago, and Plasma Wayland is on par with uncomposited X11 session
16:38 zamundaaa[m]: Since then we optimized latency more, I should redo those measurements soon
16:38 kchibisov: zamundaaa: it's a matter of client they used, etc, etc.
16:38 soreau: is it possible the cursor moves more fluently on X than wayland?
16:39 kchibisov: zamundaaa: I'd also suggest to examine various path in typical input cases, like text-input based ones, etc, etc.
16:40 kchibisov: for example, gnome (has/had) a full frame delay if you've touched text-input reposition thing, becuase it started to compose earlier than it should.
16:40 kchibisov: even though, it wasn't even visible.
16:40 Ermine: In my case, I never had any latency issues with plasma, neither on x11 nor wayland
16:41 soreau: me neither, but that's only because I've never used plasma ;)
16:41 Ermine: i'm writing this from plasma :)
16:41 kchibisov: if you're used to certain amount of latency you won't notice it if it's bad.
16:42 kchibisov: especially on high refresh rate monitors it's also not that obvious.
16:42 kchibisov: I remember I had a bug where I was drawing a blank frame, and I've noticed it when switched to 60fps monitor.
16:43 kchibisov: on 144Hz it was not that obvious for eye perception.
16:43 Ermine: my displays are all 60fps
16:44 kchibisov: I'd imagine that on e.g. 300fps monitors measuring latency is even harder, since it's all pretty much in noise range.
16:44 soreau: zamundaaa[m]: is it possible to run only plasma's panel in a different compositor? or is it baked into the compositor or requires nonstandard protocol(s) or some other reason it won't work as a 'standalone' client?
16:44 kchibisov: And frame scheduling is probably not that needed there.
16:57 soreau: ah, I found my issue with xdg_configure.. didn't commit after ack'ing :P
16:59 soreau: so I have to ack(+commit) the surface configure to get a toplevel configure event..
17:00 kchibisov: yeah, you have to commit to apply changes.
17:00 kchibisov: even when nothing relevant changes, like e.g. you've got only suspended state change.
17:00 soreau: right but why do toplevel configure events only come after acking the surface configure event..
17:01 soreau: does it sound like the compositor is correct in this case?
17:01 kchibisov: could be compositor specific?
17:01 soreau: I wonder if this is this specified in the protocol anywhere
17:03 kchibisov: I'd assume you commit before that as well.
17:03 kchibisov: just to start the initial setup sequence.
17:04 kchibisov: The flow is you create objects, set all the state you want, and to wl_surface.commit(), then you get the surface.configure/toplevel.configure, etc.
17:06 kchibisov: I know that you must ack_configure for xdg_toplevel::configure.
17:06 kchibisov: But the other configure is a bit vague here, it just tells to do that eventually before surface.commit.
17:07 zamundaaa[m]: soreau: plasmashell is only supported on KWin. Some people have made it kinda work with lots of hacks on other compositors, but it is not supported
17:08 soreau: zamundaaa[m]: I see, thanks
17:09 soreau: kchibisov: how do you know that you must ack before getting toplevel configure events?
17:09 kchibisov: it's not specified.
17:09 kchibisov: I know that you must ack toplevel configure.
17:10 kchibisov: i don't know about before.
17:11 soreau: ah, well that's where it's confusing..
17:12 soreau: because the spec says for toplevel.configure, you have to send surface.ack_configure but in surface.configure.. well, this is where simple-shm sends ack_configure
17:12 kchibisov: There's also a wording like >The client must acknowledge it and is then allowed to attach a buffer to map the surface.
17:12 kchibisov: I'd assume you must ack the initial configure.
17:13 soreau: right but ack'ing in surface.configure isn't required, right?
17:13 kchibisov: it's required for initial setup.
17:13 kchibisov: but it doesn't say where.
17:13 soreau: oh ok
17:13 kchibisov: read the xdg_surface general doc.s
17:13 kchibisov: "After creating a role-specific..." paragraph.
17:15 soreau: my point is in toplevel.configure it states "Clients must send an ack_configure in response to this event. See xdg_surface.configure and xdg_surface.ack_configure for details." but in simple-shm there is only one ack, and it's in surface.configure
17:16 soreau: so technically per spec, it seems simple-shm is missing an ack in toplevel.configure
17:16 soreau: does this make sense?
17:16 soreau: and it all happens to work out because surface.configure and toplevel.configure are basically emitted together?
17:20 kchibisov: it's correct.
17:20 kchibisov: the surface.configure marks the end of the configure sequence.
17:21 kchibisov: and you can only ack the serial from it.
17:21 soreau: oh it needs a serial
17:21 kchibisov: thus, you ack from the xdg_surface.configure.
17:21 kchibisov: since it's the end of the sequence.
17:21 soreau: so why does the spec say to emit an ack in response to toplevel.configure?
17:21 kchibisov: idk.
17:22 kchibisov: you'd emit it anyway.
17:22 kchibisov: probably for consistency and that it'll only apply because you ack.
17:23 soreau: so toplevel.configure(s) always happen first followed by a surface.configure except the initial configure?
17:25 kchibisov: you can not get surface.configure -> toplevel.configure -> no surface.configure.
17:25 soreau: so that's backward then
17:25 kchibisov: it's always all-possible-thing.configure -> surface.configure -> ack.
17:26 kchibisov: so the state of multiple objects applied atomically.
17:26 kchibisov: e.g. decoration manager + top level.
17:27 soreau: so simple-shm is frame event driven, but it doesn't commit after ack in surface.configure, it just relies on the frame event to commit the ack at that point..
17:27 soreau: (except on initial configure)
17:28 kchibisov: you usually commit -> loop { ack -> draw -> commit (by means of draw) }.
17:29 soreau: ok, untangling the confusion
17:29 kchibisov: the point is that you commit when you've applied the state, to inform that state got applied and compositor transitions, since you've applied already.
17:30 kchibisov: if you commit straight away, it's wrong, since you likely haven't accounted for a new size, etc.
17:30 kchibisov: The point is for state change to be atomic and you don't see window flicker.
17:30 soreau: unless you pass the --tear-it-up flag ;)
17:30 kchibisov: The only thing where you don't need to really draw, is when you got a suspended state change.
21:04 dongle: occasionally after afk i come back and move the mouse and the screen comes back on but everything is frozen for 30 seconds. then it is ok. any ideas? gnome 43.9 wayland, debian 12
21:11 dongle: intel integrated gpu
21:16 danieldg: the 30 seconds sounds like some dbus call is timing out
21:16 danieldg: perhaps running dbus-monitor on both session and system bus would help figure it out
21:17 danieldg: likely a gnome bug, check their bug tracker
21:17 danieldg: (mutter, that is)
21:24 dongle: i'll look into that thanks danieldg