00:34 DemiMarie: DodoGTA: why would Wayscope need atoms?
01:00 UndeadLeech: The `wl_surface::preferred_buffer_scale` event states "It is sent whenever the compositor's preference changes", which implies to me that it is not sent when the surface is originally created. Is this accurate? I'm curious if its goal is to have clients rely solely on this, or rely on the output on startup and just use this events for changes?
04:05 wlb: weston Merge request !1252 closed (backend-drm: make sure unused CRTC is disabled before atomic commit)
05:34 kchibisov: UndeadLeech: I'd say that you shouldn't rely on output events in any case, because enter/leave events are deprecated.
06:06 emersion: UndeadLeech: you don't get wl_output.enter on startup
06:17 kchibisov: emersion: I think the issue wording "It is sent whenever the compositor's preference changes". Which is unclear about startup, because if compositor was running all the time at 2x nothing changes from that perspective.
06:17 kchibisov: is wording*
06:18 kchibisov: The same could be said about running at scale 1.
06:18 emersion: kchibisov: we had wording which required sending scale=1 on wl_surface creation, which was pretty weird
06:18 emersion: if you have ideas to improve the wording, that'd be great
06:19 emersion: maybe "and when the initial preference is picked" or something?
06:20 kchibisov: This event is sent upon initial wl_surface.commit and whenever compositor's preference changes.
06:21 kchibisov: Though, inital is weird, because you could need the same wrt unmapping the surface.
06:22 kchibisov: I'm not sure if there's a protocol allowing attaching and commiting new surface right away though.
06:27 emersion: "initial commit" depends on the surface role really
06:28 kchibisov: yeah, that's the issue with such stuff.
06:28 emersion: e.g. one can commit a future cursor surface without getting a preferred scale
06:30 kchibisov: This event is sent in response to wl_compositor.create_surface and whenever compositor's preference changes.
06:32 kchibisov: This way it's clear that once surface is created you send scale and transform to it.
06:33 emersion: no, it's explicitly not sent on wl_compositor.create_surface
06:33 emersion: on wl_compositor.create_surface, the compositor has no information to send any preferred scale other than 1
06:33 emersion: easy enough to initialize a variable to 1 in clients instead of sending this weird event
06:34 kchibisov: Hm, how would it solve first frame scaling issues?
06:34 kchibisov: Or it was never meant to?
06:35 emersion: it is meant to yes
06:35 emersion: well
06:35 kchibisov: It's clear though, that with xdg-shell you won't have this issue anymore, because you handle it during configure dance on startup.
06:35 emersion: to some extent, some more work is required to have it perfect
06:35 emersion: yes
06:37 kchibisov: And yeah, using constructor is not a good idea, because you can create and attach + commit cursor surface in one go.
06:38 kchibisov: Maybe role objects should mention the interactions with such events instead?
06:38 emersion: i'd like to have a proper cursor addon interface
06:39 emersion: yeah maybe
06:39 kchibisov: With cursors we have shape protocol, and the behavior of the prefered scale depends on role.
06:39 emersion: the shape protocol only addresses the problem for well-known shapes
06:39 kchibisov: For xdg-shell I'd expect to get it or fractional scale info during initial configure dance, so the first frame is perfect.
06:40 emersion: but yeah, it mitigates the issue somewhat
06:40 kchibisov: The custom cursors are rare cases though.
06:41 emersion:thinking of games mostly
06:41 kchibisov: I think they draw them themselfves.
06:41 kchibisov: In a way that it simply blends over other stuff.
06:41 emersion: that's not my experience
06:41 emersion: but maybe some do
06:41 kchibisov: Yeah, it depens on games you play.
06:43 RAOF: "Hardware cursor" certainly used to be an option on a great number of games.
06:50 kchibisov: The initial event is sent with accordance to associated role object and then whenever compositor's preference changes.
06:51 kchibisov: Though, you could have a surface without a role and it's not clear when it'll get the scale factor.
07:04 kchibisov: On the other hand, "The compositor will reply with an xdg_surface.configure event" in xdg_surface docs could mention that compositor 'will reply with initial wl_surface state followed by xdg_surface.configure event'.
07:06 kchibisov: Right now my toolkit hopes that we get a scaling and such while waiting for initial configure, given that it's not stated explicitly that e.g. fractional scaling will be even sent during the configure dance.
07:07 kchibisov: If we don't get it nothing will break, but it'll be unfortunate...
07:07 kennylevinsen: I'd as usual add that some compositors do know the intended state the moment the role object is created (clay, WIP)
07:08 kchibisov: "do know", right?
07:08 kennylevinsen: yes, positive
07:09 kchibisov: Or do you mean 'before doing commit -> configure'?
07:09 kchibisov: My assumption is that compositor clearly knows the state after getting initial commit for xdg_surface.
07:10 kchibisov: The cursor role is weird and can't be helped by the wl_surface v6 additions.
07:11 kennylevinsen: clay picks the spot immediately, picked either when the client commits the role object (not map) or activates a launcher token on the wl_surface, so geometry and scale is well known at this point.
07:11 kchibisov: I think every compositor should know that.
07:11 kennylevinsen: Some clients get surprised by having a configure with size this early, and tend to overwrite it...
07:11 kchibisov: I have a feeling that you meant mpv.
07:12 kennylevinsen: others should at least have a guess that is better than assuming 1 or having the client read all outputs. I assume the problem they see is that the info could go stale between role object creation and map?
07:12 kennylevinsen: why would you think that :)
07:14 kchibisov: I mean you could know the output you'll open at least.
07:15 emersion: there is an edge case when the toplevel is large and spans multiple outputs
07:15 kchibisov: or do you mean why mpv? I just know that compositor I know which sends all the desired state isn't liked by mpv and it ignores the width/height.
07:15 emersion: but it doesn't really happen in practice
07:16 kennylevinsen: can we ban surfaces across multiple outputs and never think about it again? macOS got away with doing that
07:16 emersion: yeah i kind of agree with that
07:20 grinja: what is good start/read for nesting compositors?
07:21 kennylevinsen: Nested compositors are "just" a Wayland server and client glued together, drawing to a Wayland window instead of directly to a display.
07:23 kennylevinsen: Reading about servers and clients separately should do. You can also look at wlroots' or weston's Wayland backends (which is the part that can be swapped between e.g. drm/KMS, Wayland and X11 for different modes of operation)
07:23 grinja: have to think about
07:26 grinja: how system compositor knows if surface is handled by another compositor? not sure if needed, I've reading Wayland book and protocols, trying to design some event based system, have to think more about dependencies
07:26 pq: kchibisov, IMO, a wl_surface without a role would have no idea where it might be presented or how, so it generally cannot always have a preferred anything either. Anyway, my interpretation is that when a role is assigned, it probably causes the compositor to change its preference from "no idea" to "scale=S". But since it depends on the role, one cannot say anything more certain in wl_surface spec about when
07:26 pq: it's sent.
07:26 grinja: I think some inter compositor protocol is needed, but still not sure
07:27 kchibisov: pq: that's why I latter suggested to say that initial depends on the role or add to role objects 'when they deliver initial state' lines.
07:27 pq: grinja, that inter-compositor protocol is e.g. Wayland or anything else you want it to be. All Wayland listening sockets are specific to a compositor instance, so after a socket is picked, there is no confusion about who is going to handle the client.
07:28 pq: kchibisov, sure, but does that actually say anything?
07:28 grinja: so each compositor creates its own `wl_display`, make sense
07:29 kchibisov: pq: with xdg_surface update it would be clear to me that scale will be applied for the first frame that way.
07:29 grinja: and `socket`?
07:29 grinja: I think I got it
07:30 kchibisov: regardless of whether it was v6 or fractional scaling.
07:30 pq: grinja, yes. Wayland is a point-to-point protocol. You must choose your compositor (socket) to connect to before connecting from a client.
07:30 grinja: thanks, got it
07:30 kchibisov: Because right now nothing stops compositors from not sending anything along the surface creation so you could still have imperfect frames even with new protocols additions.
07:31 grinja: it makes perfect sense, not sure why I didn't see it, each unit is stand alone
07:31 kchibisov: Though, updating the spec doesn't eliminate bugs in compositors, I have work arounds for mutter for years.
07:32 pq: kchibisov, I guess I'd need to see a patch to say anything. I think wl_surface spec cannot make any promises of anything wrt. preferred scale etc. but role specific interfaces can.
07:33 grinja: so only `wayland-0` is like `system` compositor as that one was first and aware of all child clients
07:34 pq: kchibisov, the only thing wl_surface spec could say is that preferred scale is assumed to be 1 until the first preferred scale event, since people really don't want the initial event.
07:35 kennylevinsen: grinja: yes but a nested compositor is just 1 child client - wayland-0 cannot see past wayland-1 and see its children
07:35 kchibisov: pq: I think it should mention explicitly that 'preference for this surface'.
07:35 kennylevinsen: So "all child clients" depends on definition :)
07:35 kchibisov: Because it could read as compositor output scaling changes.
07:36 kennylevinsen: yeah an initial event should be for where an initial value is chosen, not a sent placeholder value
07:36 kchibisov: I know that initial question raised from the situation where compositor is designed for a particular use case, where scaling is always 2.
07:36 kchibisov: Because the monitor is always the same.
07:37 kchibisov: So scaling of 1 is not what it really wanted.
07:37 pq: kchibisov, oh, I have already read it as preference for the *surface* always. What lead you away from that?
07:38 pq: it is a wl_surface event after all
07:39 pq: if it's just a missing "for this surface" that solves all your problems, then that sounds good to me
07:39 pq: ..to add
07:39 kchibisov: I would also mention that 1 is the default somehow.
07:39 pq: but you just gave an example of the contrary?
07:40 kchibisov: Yeah, but how would you express that?
07:40 kchibisov: For e.g. cursor surfaces.
07:40 kchibisov: Where you could do everything in one go without ever getting this event.
07:40 pq: cursor role protocol simply doesn't have the mechanics to get the first frame perfect, so I'm not sure why the fixation on that
07:40 kchibisov: I mean, for the first frame.
07:41 pq: you have to invent a new cursor role protocol to fix that
07:41 pq: nothing in wl_surface can fix it
07:43 grinja: kennylevinsen: but will, for example `xdg` clients automatically connects to `wayland-0` if `NULL` is used or it will pick up top most `wayland-<N>`? I understand that you can configure `compositors` to select `wl_display`, but how would client choose?
07:43 pq: if a new cursor role object was specific to a wl_pointer instance, then the compositor would have quite nice grounds on deciding the preferred scale.
07:44 grinja: `xdg` client
07:45 pq: alternatively, maybe even better, a new cursor role object could be tied to a wl_surface it is a cursor for - that tells the compositor which window this is going to be used with.
07:45 pq: the disadvantage is that you may then need more cursor surfaces than before
07:45 emersion: that may be complicated for clients with sub-surafces and popups etc
07:46 pq: emersion, I suppose it doesn't need to be that strict association
07:47 pq: using a top-level for all its sub-surfaces and popups should be good enough - a pointer can leave any window anyway while still retaining the cursor which may then need a change of preference
07:48 pq: OTOH, associating with a wl_pointer instead, the compositor always knows where that pointer is, and that mostly determines the preferences.
07:48 grinja: system (global keys) -> window compositor -> window decoration compositor -> xdg_toplevel (does this make sense), so does `xdg` client have to specify `window decoration fd` or can just use `NULL`?
07:49 pq: grinja, clients usually have WAYLAND_DISPLAY set in their environment, telling them where to connect.
07:50 grinja: so system setting should provide it before launching client? ok, thanks
07:51 pq: grinja, no, the chain you described makes no sense.
07:51 pq: I can't even guess what you're trying to describe.
07:51 grinja: but should compositor enrich surface?
07:52 pq: what does that mean?
07:52 grinja: operates on surfaces
07:52 grinja: and wraps them into its unit
07:53 pq: a compositor's job is to relay input events to its clients, and to take the clients' surface and show then in some approriate way on screen.
07:53 pq: *surfaces and show them
07:54 pq: If you're asking who will be drawing window decorations, then there is a Wayland protocol extension to negotiate that, and if it's missing, then the clients draw their own decorations.
07:57 grinja: decoration was one example, I'm thinking is it possible to have different compositor for different output, or to have protocol implementations dynamically loaded, will think about bit more and come back
07:58 pq: Wayland does not say anything about those things.
08:06 wlb: wayland-protocols Merge request !213 opened by Kirill Chibisov (kchibisov) stable/xdg-shell: clarify initial wl_surface acknowledgement https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/213
08:15 grinja: pq: I was looking on nested compositors as `system` compositor plug in, that might be wrong approach, have to think about it, I'm aware about decoration protocol, and positioner, but I'm thinking if nested compositor is in the middle how that knowledge is handled top down, if needed, I just started with wayland, need to get it first
08:18 grinja: so for now, as I understand, nested `wl-1` needs to connect to `wl-0` and ask for surface, then `xdg` client needs to connect to `wl-1` and ask for surface, but how client knows it is `wl-1` it needs to connect. will try with `WAYLAND_DISPLAY`
08:18 pq: grinja, a plugin is not what we call a nested compositor at all.
08:20 grinja: so `wl-0` will only know about `wl-1`, so I can't reassign `xdg` client to `wl-2` without protocol
08:20 grinja: it would need to reconnect
08:21 grinja: will see... thanks for heads up, will read more
08:21 pq: yeah, Wayland connections cannot be reassigned at all.
08:22 pq: A nested compositor is an independent process with two sides: it acts as a Wayland server towards its own clients, and it acts as a Wayland client towards its host compositor.
08:24 pq: What a nested compositor does is completely up to it alone. Maybe it creates a single window as a virtual desktop, or maybe it forwards its own clients' windows as-is, or maybe it puts all its own clients' windows in a 3D virtual world that one can view on the host compositor.
08:24 pq: or anything else
08:24 grinja: yeah, got it, I have some experience with flux and dispachers
08:25 pq: a nested compositor could also connect, disconnect, and reconnect to any host compositors at will
08:25 grinja: I wan't global for input events and possibility to assign compositor to output
08:26 pq: I'm not sure what that means.
08:26 grinja: also virtual outputs and more... but step by step
08:27 pq: usually with multiple compositors running, something is routing input such that each compositor sees only the input meant for it.
08:28 grinja: for example, split monitor on half, show same applications in one half as tiled grid, and show 3D space in another half using only wayland protocol
08:28 pq: on a multi-seat setup, it means assigning physical input devices to seats, each seat having its own compositor instance, and therefore capable of opening only its own input devices.
08:29 grinja: still didn't get to multi seats, was going to, will check
08:30 grinja: wasn't aware of own compositor thing
08:30 pq: grinja, and what kind of security separation do you want with that? If none, then it's just a window management policy in a single compositor instance.
08:30 grinja: I need multi one
08:31 pq: grinja, are the basics clear to you? E.g. Wayland is not a program you could run.
08:31 grinja: for example different compositor dynamically loaded as accessibility option, idk, have to think more, lots of new info today
08:32 pq: that does not make sense to me, I'm afraid
08:32 grinja: pq, I understand that
08:51 wlb: weston Merge request !1254 opened by Michael Tretter (m.tretter) backend-drm: add fallback-mode for outputs without modes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1254
12:23 wlb: weston Merge request !1255 opened by Pekka Paalanen (pq) man: make --wait-for-debugger findable https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1255
14:09 wlb: weston/main: Pekka Paalanen * man: make --wait-for-debugger findable https://gitlab.freedesktop.org/wayland/weston/commit/406e3d2ab91a man/weston.man
14:09 wlb: weston Merge request !1255 merged \o/ (man: make --wait-for-debugger findable https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1255)
21:24 bent_fingers: Does luakit work on wayland without xwayland?
22:36 dottedmag: bent_fingers: Please ask in luakit support channels