11:11 staceee: Hey there, I'd like my xdg_popup to not being clickable, just a surface to give a user feedback. Is it possible?
11:11 staceee: and if so, how should I configure my wl_surface for this use case?
11:13 pq: staceee, by not clickable, do you mean clicks should go through it to what's below?
11:13 staceee: pq: exactly
11:14 pq: I think setting an empty input region on the wl_surface should do.
11:16 kchibisov: Hm, how feasible it would be for libwayland-egl to set the scale/transform for the surface along the sizes?
11:16 staceee: pq: it works! thanks for the clue
11:17 kchibisov: So the mesa state and the client state won't desynced due to mesa lingering resizes.
11:17 kchibisov: desync*
11:18 pq: kchibisov, it sounds easy, but why would it end with just those two? There is a lot more state one might want to sync.
11:19 kchibisov: Mostly because mesa owns the surface and scale not much can crash the entire client.
11:19 kchibisov: not match*
11:19 kchibisov: sorry, can't type.
11:19 pq: so could ack_configure with a wrong size
11:20 kchibisov: Maybe mesa should callback and inform the client about what it's doing?
11:20 kchibisov: But it could be weird in cross platform.
11:21 pq: Doesn't wl_egl_window_get_attached_size() help?
11:21 pq: or is that the "previous" size?
11:21 kchibisov: I'm not entirely sure what the size it'll be.
11:22 kchibisov: I think the query for width and height on the EGLSurface will work.
11:22 pq: yeah, I hope so
11:22 kchibisov: I just don't remember at which time it's all applied, I remember that it could be inside the swap_buffers.
11:23 kchibisov: So you're out of luck in that case.
11:24 kchibisov: yeah, it's inside the swap_buffers.
11:24 kchibisov: So you don't know until you swap buffers...
11:25 kchibisov: Which is all pointless and you've already done a commit.
11:26 kchibisov: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/egl/drivers/dri2/platform_wayland.c#L1615
11:26 kchibisov: And the same about other properties, they all apply when you actually try to draw.
11:28 pq: Looks like the attached_width,height are the ones you just committed. What about the EGLSurface EGL_WIDTH, EGL_HEIGHT?
11:29 kchibisov: I think they should work.
11:29 kchibisov: Because it's a base.Width iirc.
11:29 kchibisov: And it'll only change if you don't have back buffer.
11:30 kchibisov: But I think it's always has back.
11:30 kchibisov: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/egl/drivers/dri2/platform_wayland.c#L476
11:30 kchibisov: I'm not a mesa developer, I don't remember the details here.
11:33 pq: If there is no back buffer yet, you can simply set the new size, and when a back buffer is next allocated, it'll be that size.
11:34 pq: If there is a back buffer already, it cannot replaced for another size, so the size cannot change before the current back buffer has been swapped.
11:34 kchibisov: Ah, and the size will be updated on the functions which could result in latching, such as make_current.
11:34 pq: a back buffer is chosen at the first call that needs a back buffer; it could be a draw call, query of buffer_age, etc.
11:35 kchibisov: yeah.
11:35 kchibisov: I guess if it doesn't go immidiatelly it's a working indicator?
11:36 pq: I suppose so
11:41 pq: kchibisov, https://lists.freedesktop.org/archives/mesa-dev/2018-June/196522.html
11:42 pq: found via the link in the comment in the Mesa code
11:49 kchibisov: It's nice that it mentions fatal issues which we got today.
11:49 kchibisov: But from the behavior used to prevent them.
11:49 kchibisov: (not in that mail, in other ones in this thread)
11:54 kennylevinsen: not a fix for mesa WSI issues, but using wp_viewporter instead of buffer scale makes scale mismatch into an imperfect render instead of a protocol error
11:55 kchibisov: kennylevinsen: yeah, I said that in the past.
11:56 kchibisov: I just getting pinged about this issue from time to time.
11:56 kchibisov: And from time to time i try to dig a bit.
11:56 kchibisov: surely I can set viewporter to the target size and workaround the issue all together.
11:56 kchibisov: (I guess)
11:57 pq: It's not even a Mesa WSI issue even, the WSI behavior is completely deterministic wrt. to the calls made to Mesa. The root of the problem is that the toolkit cannot require nor ensure when and how Mesa is called.
11:57 kchibisov: Though, wsi is bugged wrt context current stuff.
11:58 kchibisov: because there's no explanation to it.
11:58 pq: ah, yeah, that's another thing
11:58 kchibisov: Like I gave 2 examples in the past where it's clearly a bug.
11:58 kchibisov: which I implemented in alacritty.
11:58 kchibisov: Like even if you look at them it doesn't make any sense, but they prevent all the latching.
11:59 kchibisov: It's like "before you create a new window, uncurrent the active context on the current thread, otherwise you'll latch it".
12:01 kchibisov: kennylevinsen: the main issue here, is that users need to develop heuristics to apply the state.
12:52 kennylevinsen: yeah, I'm not a fan of graphics APIs that interact with the window system... It splits responsibility of window state across multiple components (mesa and its user)
12:53 kennylevinsen: rendering to buffers and having the client (or their toolkit) attach them in their (unavailable) platforms-specific window bits is a cleaner separation of responsibilities
12:53 kennylevinsen: s/unavailable/unavoidable/
12:54 pq: EGLDevice platform for the win?
12:55 pq: and maybe a library to help handling all the dmabuf protocol and modifier feedbaack
12:56 emersion: you just invented wlroots backends :P
12:57 kennylevinsen: indeed :D
12:57 pq: yay \o/
12:58 kennylevinsen: but to sell this to kchibisov we'd also need to have a means to get this running on windows, macos and x11 :P
12:58 kennylevinsen: I doubt we'll add a win32 backend to wlroots anytime soon
12:59 kchibisov: kennylevinsen: I mean, I can use vulkan without such issues.
12:59 kchibisov: it doesn't have to work across all the platforms, it just should be something that could be reliable.
13:00 kchibisov: The EGLDevice platform will solve the out standing issue with languages hard depending on libwayland because of mesa.
13:02 pq: EGLDevice platform solves the issue of fighting a WSI, right?
13:02 pq: as in, you get to reinvent it yourself so it does what you need
13:04 kchibisov: yeah, we considered doing something like that.
13:04 kchibisov: but it requires resources.
13:19 emersion: pq, EGLDevice doesn't mean you don't get an EGLSurface
13:19 emersion: you can create an EGLDisplay bound to wl_display and an EGLDevice
13:20 emersion: i think you mean surfaceless, rather than EGLDevice
13:20 pq: isn't EGLDevice an independent EGL platform?
13:20 emersion: hm, right
13:21 emersion: and if you use it, you don't get an EGLSurface that can work with Wayland
13:21 pq: but yes, I am bit confused how you get scanout-able dmabuf out of an EGLDevice platform
13:21 emersion: you allocate via GBM
13:21 pq: or not even scanout-able
13:22 emersion: you can allocate via FBO if you'd like, but then it's not good for Wayland
13:22 pq: ah, still GBM for allocation, even though not using EGL GBM platform.
13:22 emersion: yes
13:22 emersion: Vulkan is a bit different in this regard, there is enough Vulkan API to allocate proper buffers for Wayland
13:22 emersion: (but not necessarily scanout)
13:55 bl4ckb0ne: > <kennylevinsen> rendering to buffers and having the client (or their toolkit) attach them in their (unavailable) platforms-specific window bits is a cleaner separation of responsibilities
13:55 bl4ckb0ne: working on that in https://git.sr.ht/~bl4ckb0ne/hel