ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
jmdaemon has quit [Ping timeout: 480 seconds]
<DemiMarie>
DodoGTA: why would Wayscope need atoms?
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
<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?
jmdaemon has joined #wayland
fmuellner has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Leopold has joined #wayland
Leopold___ has quit [Ping timeout: 480 seconds]
fmuellner has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
<wlb>
weston Merge request !1252 closed (backend-drm: make sure unused CRTC is disabled before atomic commit)
tzimmermann has joined #wayland
robobub_ has joined #wayland
<kchibisov>
UndeadLeech: I'd say that you shouldn't rely on output events in any case, because enter/leave events are deprecated.
mvlad has joined #wayland
kts has joined #wayland
tent405 has quit [Quit: tent405]
tent405 has joined #wayland
sima has joined #wayland
<emersion>
UndeadLeech: you don't get wl_output.enter on startup
tent405 has quit [Quit: tent405]
tent405 has joined #wayland
<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.
<kchibisov>
is wording*
<kchibisov>
The same could be said about running at scale 1.
<emersion>
kchibisov: we had wording which required sending scale=1 on wl_surface creation, which was pretty weird
<emersion>
if you have ideas to improve the wording, that'd be great
<emersion>
maybe "and when the initial preference is picked" or something?
<kchibisov>
This event is sent upon initial wl_surface.commit and whenever compositor's preference changes.
<kchibisov>
Though, inital is weird, because you could need the same wrt unmapping the surface.
<kchibisov>
I'm not sure if there's a protocol allowing attaching and commiting new surface right away though.
kts has quit [Quit: Konversation terminated!]
<emersion>
"initial commit" depends on the surface role really
<kchibisov>
yeah, that's the issue with such stuff.
<emersion>
e.g. one can commit a future cursor surface without getting a preferred scale
<kchibisov>
This event is sent in response to wl_compositor.create_surface and whenever compositor's preference changes.
tent405 has joined #wayland
<kchibisov>
This way it's clear that once surface is created you send scale and transform to it.
<emersion>
no, it's explicitly not sent on wl_compositor.create_surface
<emersion>
on wl_compositor.create_surface, the compositor has no information to send any preferred scale other than 1
<emersion>
easy enough to initialize a variable to 1 in clients instead of sending this weird event
<kchibisov>
Hm, how would it solve first frame scaling issues?
<kchibisov>
Or it was never meant to?
<emersion>
it is meant to yes
<emersion>
well
<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.
<emersion>
to some extent, some more work is required to have it perfect
<emersion>
yes
<kchibisov>
And yeah, using constructor is not a good idea, because you can create and attach + commit cursor surface in one go.
<kchibisov>
Maybe role objects should mention the interactions with such events instead?
<emersion>
i'd like to have a proper cursor addon interface
<emersion>
yeah maybe
<kchibisov>
With cursors we have shape protocol, and the behavior of the prefered scale depends on role.
<emersion>
the shape protocol only addresses the problem for well-known shapes
<kchibisov>
For xdg-shell I'd expect to get it or fractional scale info during initial configure dance, so the first frame is perfect.
<emersion>
but yeah, it mitigates the issue somewhat
<kchibisov>
The custom cursors are rare cases though.
* emersion
thinking of games mostly
<kchibisov>
I think they draw them themselfves.
<kchibisov>
In a way that it simply blends over other stuff.
<emersion>
that's not my experience
<emersion>
but maybe some do
<kchibisov>
Yeah, it depens on games you play.
<RAOF>
"Hardware cursor" certainly used to be an option on a great number of games.
iomari891 has joined #wayland
<kchibisov>
The initial event is sent with accordance to associated role object and then whenever compositor's preference changes.
<kchibisov>
Though, you could have a surface without a role and it's not clear when it'll get the scale factor.
<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'.
<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.
tent405 has quit [Quit: tent405]
<kchibisov>
If we don't get it nothing will break, but it'll be unfortunate...
<kennylevinsen>
I'd as usual add that some compositors do know the intended state the moment the role object is created (clay, WIP)
<kchibisov>
"do know", right?
<kennylevinsen>
yes, positive
<kchibisov>
Or do you mean 'before doing commit -> configure'?
<kchibisov>
My assumption is that compositor clearly knows the state after getting initial commit for xdg_surface.
<kchibisov>
The cursor role is weird and can't be helped by the wl_surface v6 additions.
<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.
<kchibisov>
I think every compositor should know that.
<kennylevinsen>
Some clients get surprised by having a configure with size this early, and tend to overwrite it...
<kchibisov>
I have a feeling that you meant mpv.
<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?
<kennylevinsen>
why would you think that :)
<kchibisov>
I mean you could know the output you'll open at least.
<emersion>
there is an edge case when the toplevel is large and spans multiple outputs
<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.
<emersion>
but it doesn't really happen in practice
<kennylevinsen>
can we ban surfaces across multiple outputs and never think about it again? macOS got away with doing that
<emersion>
yeah i kind of agree with that
grinja has joined #wayland
<grinja>
what is good start/read for nesting compositors?
<kennylevinsen>
Nested compositors are "just" a Wayland server and client glued together, drawing to a Wayland window instead of directly to a display.
<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)
<grinja>
have to think about
<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
iomari892 has joined #wayland
<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
<pq>
it's sent.
<grinja>
I think some inter compositor protocol is needed, but still not sure
<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.
<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.
iomari891 has quit [Ping timeout: 480 seconds]
<pq>
kchibisov, sure, but does that actually say anything?
<grinja>
so each compositor creates its own `wl_display`, make sense
<kchibisov>
pq: with xdg_surface update it would be clear to me that scale will be applied for the first frame that way.
<grinja>
and `socket`?
<grinja>
I think I got it
<kchibisov>
regardless of whether it was v6 or fractional scaling.
<pq>
grinja, yes. Wayland is a point-to-point protocol. You must choose your compositor (socket) to connect to before connecting from a client.
<grinja>
thanks, got it
<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.
<grinja>
it makes perfect sense, not sure why I didn't see it, each unit is stand alone
<kchibisov>
Though, updating the spec doesn't eliminate bugs in compositors, I have work arounds for mutter for years.
<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.
<grinja>
so only `wayland-0` is like `system` compositor as that one was first and aware of all child clients
cool110 has quit [Remote host closed the connection]
<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.
cool110 has joined #wayland
<kennylevinsen>
grinja: yes but a nested compositor is just 1 child client - wayland-0 cannot see past wayland-1 and see its children
<kchibisov>
pq: I think it should mention explicitly that 'preference for this surface'.
<kennylevinsen>
So "all child clients" depends on definition :)
<kchibisov>
Because it could read as compositor output scaling changes.
<kennylevinsen>
yeah an initial event should be for where an initial value is chosen, not a sent placeholder value
<kchibisov>
I know that initial question raised from the situation where compositor is designed for a particular use case, where scaling is always 2.
<kchibisov>
Because the monitor is always the same.
<kchibisov>
So scaling of 1 is not what it really wanted.
Company has quit [Quit: Leaving]
<pq>
kchibisov, oh, I have already read it as preference for the *surface* always. What lead you away from that?
<pq>
it is a wl_surface event after all
<pq>
if it's just a missing "for this surface" that solves all your problems, then that sounds good to me
<pq>
..to add
<kchibisov>
I would also mention that 1 is the default somehow.
<pq>
but you just gave an example of the contrary?
<kchibisov>
Yeah, but how would you express that?
<kchibisov>
For e.g. cursor surfaces.
<kchibisov>
Where you could do everything in one go without ever getting this event.
<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
<kchibisov>
I mean, for the first frame.
<pq>
you have to invent a new cursor role protocol to fix that
<pq>
nothing in wl_surface can fix it
<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?
<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.
<grinja>
`xdg` client
<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.
<pq>
the disadvantage is that you may then need more cursor surfaces than before
<emersion>
that may be complicated for clients with sub-surafces and popups etc
<pq>
emersion, I suppose it doesn't need to be that strict association
<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
<pq>
OTOH, associating with a wl_pointer instead, the compositor always knows where that pointer is, and that mostly determines the preferences.
<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`?
<pq>
grinja, clients usually have WAYLAND_DISPLAY set in their environment, telling them where to connect.
<grinja>
so system setting should provide it before launching client? ok, thanks
<pq>
grinja, no, the chain you described makes no sense.
<pq>
I can't even guess what you're trying to describe.
<grinja>
but should compositor enrich surface?
<pq>
what does that mean?
<grinja>
operates on surfaces
<grinja>
and wraps them into its unit
<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.
<pq>
*surfaces and show them
<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.
molinari has joined #wayland
<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
<pq>
Wayland does not say anything about those things.
<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
<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`
<pq>
grinja, a plugin is not what we call a nested compositor at all.
<grinja>
so `wl-0` will only know about `wl-1`, so I can't reassign `xdg` client to `wl-2` without protocol
<grinja>
it would need to reconnect
<grinja>
will see... thanks for heads up, will read more
<pq>
yeah, Wayland connections cannot be reassigned at all.
pochu has joined #wayland
<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.
rasterman has joined #wayland
<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.
<pq>
or anything else
<grinja>
yeah, got it, I have some experience with flux and dispachers
<pq>
a nested compositor could also connect, disconnect, and reconnect to any host compositors at will
<grinja>
I wan't global for input events and possibility to assign compositor to output
<pq>
I'm not sure what that means.
<grinja>
also virtual outputs and more... but step by step
<pq>
usually with multiple compositors running, something is routing input such that each compositor sees only the input meant for it.
<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
<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.
<grinja>
still didn't get to multi seats, was going to, will check
Leopold has quit [Ping timeout: 480 seconds]
<grinja>
wasn't aware of own compositor thing
<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.
<grinja>
I need multi one
<pq>
grinja, are the basics clear to you? E.g. Wayland is not a program you could run.
<grinja>
for example different compositor dynamically loaded as accessibility option, idk, have to think more, lots of new info today