08:00wlb: weston Marius Vlad pushed a new branch 13.0 https://gitlab.freedesktop.org/wayland/weston/tree/13.0
10:11wlb: weston Issue #869 opened by Cepera Mosolov (mosolovs1987) Some kind of feedback for touchscreen press event abs coords required for user https://gitlab.freedesktop.org/wayland/weston/-/issues/869
11:17wlb: wayland Issue #436 opened by Pekka Paalanen (pq) Explicitly document the effect of binding globals etc. multiple times https://gitlab.freedesktop.org/wayland/wayland/-/issues/436 [Protocol], [Documentation]
13:59wlb: weston Issue #870 opened by Pekka Paalanen (pq) heap-use-afte-free in weston_desktop_seat_popup_grab_remove_surface() https://gitlab.freedesktop.org/wayland/weston/-/issues/870 [libweston-desktop]
15:02wlb: weston Merge request !1449 opened by Derek Foreman (derekf) Draft: compositor: Don't lift planes out of scene graph entirely https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1449 [Core compositor]
16:09emersion: pq, do you think it's fine if instead of the usual "child object inherits parent version" rule, it inherits another object
16:09emersion: 's poassed as argument?
16:09emersion: passed*
16:09emersion: e.g.
16:10emersion: external_iface.foo(wl_data_device, new id wl_data_source)
16:10emersion: where wl_data_source version is inherited from wl_data_device
16:20kchibisov: The configure state in xdg_shell is double buffered, how it should work when I don't really need to draw? Like for example, my window is marked as suspended, should I just do wl_surface.commit and not draw? Or should I draw/finish drawing and stop drawing from the next loop iteration?
16:21kchibisov: The same with activated, for example, activated doesn't result in the top-level commit/redraw in my case, but I just redraw subsurfaces in desync way, thus commit them.
16:21kchibisov: But not the top-level surface.
16:21vyivel: yeah just ack+commit without attaching a buffer
16:22kchibisov: And I _must_ do that?
16:22vyivel: preferably?
16:22kchibisov: Like it's just I don't want commit on behalf of the user.
16:23kchibisov: So they must draw via the infra I define.
16:23kchibisov: Like the concept that you _commit_ some object you usually use for drawing is a bit weird.
16:24vyivel: the idea is that you redraw in response to the configure
16:24kchibisov: yeah, but suspended tells you to stop doing so.
16:24vyivel: yeah this one's a bit weird
16:24vyivel: iirc alacritty doesn't respond with a commit to it?
16:24kchibisov: yeah.
16:25kchibisov: well, it's winit problem in general.
16:25kchibisov: Like we tell that once the window is Occluded you should stop drawing.
16:25vyivel: it probably should respond without a buffer
16:25kchibisov: Because it's common concept on all the platforms.
16:25kchibisov: Yeah, but if you do multithreaded rendering and have a buffer in-flight it'll cause issue if you commit on behalf of the user.
16:26vyivel: on the other hand, if the window is suspended, that's because it's invisible, so the compositor doesn't really care if it's updated or not…
16:26kchibisov: yeah, but it may think that the state is not applied.
16:26kchibisov: Thus it'll think that the window is not suspended.
16:26emersion: clients are supposed to ack to configures in a timely manner'
16:26kchibisov: yeah, I ack the things, the problem is commit.
16:26kchibisov: Like I ack configure, but don't commit/draw if it's suspended state.
16:27emersion: i mean ack+commit, an ack alone just populates the pending state
16:27vyivel: can/does winit signal to the app that a redraw is required?
16:27kchibisov: yeah, it can.
16:27kchibisov: like it's not an issue, it's just probably will start masking some bugs.
16:27kchibisov: Like the one when your window is suspended from the start.
16:27emersion: can winit ask the app to redraw with an empty damage?
16:27kchibisov: Hm, not yet, but I see what you're suggesting.
16:28kchibisov: I guess for now I'll change to force redraw.
16:28kchibisov: And then I'll change to somehow not really force redraw.
16:30kchibisov: My main issue is that this concept can't be automatically added to some abstraction, because it's a wayland unique behavior.
16:31kchibisov: Probably drawing one more time won't hurt, since damage tracking is on behalf of the client...
16:34kchibisov: Hm, if I draw with vsync will I block when I get suspended state and commit a buffer with it?
16:36kennylevinsen: It suggests that a surface frame callback might not fire anytime soon
16:36kchibisov: yeah, so it wants an wl_surface.commit() without a draw.
16:37kchibisov: Because asking me to draw here will block the clients.
16:38kchibisov: I guess I'll just remove the suspended handling for now.
18:30YaLTeR[m]: mhm, some clients seem to treat zwlr_foreign_toplevel_handle_v1 state activated like the keyboard focus (i.e. only one window can have it)
18:41YaLTeR[m]: i suspect adding keyboard focus into there could help
19:02emersion: keyboard focus may not be exclusive either
19:02emersion: there is multi-seat, and nothing in the spec prevents compositors from giving keyboard focus to multiple clients
19:03YaLTeR[m]: right
19:09kchibisov: I just feel like fcitx a little bit abused it with per toplevel ime state.
19:10kchibisov: Like it's a very useful feature when you use more than 2 languages at the same time, but probably there should be something else or maybe input-method-v2 itself should kind of broadcast focus.
19:11kchibisov: Though, input-method-v2 is not seat aware as well iirc.
19:22emersion: oh it's for fctix? yeah that wasn't designed for this at all…
19:22kchibisov: I've seen fcitx using it.
19:23kchibisov: https://fcitx-im.org/wiki/Using_Fcitx_5_on_Wayland the last thing on the page.
19:24YaLTeR[m]: emersion: sfwbar really dislikes multiple activated windows, and Waybar's taskbar handles them correctly but design-wise it really should be keyboard focus instead for indicating the "active" window
19:24emersion: for a bar "active" seems the right thing to use
19:25emersion: some devices don't have keyboards btw
19:25YaLTeR[m]: i.e. I keep the active window on every workspace activated even when it's not the active workspace, so that switching workspaces doesn't cause unneeded window animations. This means the bar will show a lot of active windows, that's really not what you want to see on a taskbar
19:26YaLTeR[m]: emersion: as a desktop compositor you can still track what the keyboard focus would be
19:26YaLTeR[m]: oh oops i replied
19:27YaLTeR[m]: oh that actually did the right thing on the irc side, nice
19:27emersion: i'd rather not go deeper into the design mistake of "there will always be a keyboard"
19:27soreau: this sounds like something that has more to do with compositor policies than protocol design choices
19:28emersion: yeah…
19:28soreau: for instance, the compositor could send active for only the window with focus if it's on the current workspace
19:29soreau: and if you're doing things to avoid unecessary animations.. seems like your compositor could have an option or fix for this
19:29YaLTeR[m]: like, that's what I will end up doing for my foreign toplevel impl, because that's what the clients seem to expect. Despite the fact the protocol says the states are the same as xdg-shell
19:30emersion: "active" is about visual feedback
19:30emersion: which is exactly what the bar wants to do
19:32kchibisov: I think the right solution would be to add more tracking into input-method-v2.
19:32kchibisov: Since a lot of IMEs kind of handles all the input.