ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
_whitelogger has joined #wayland
Brainium has joined #wayland
goat has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
goat has quit []
crazybyte has quit [Quit: Bye]
crazybyte has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
tristianc6704 has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
kts has joined #wayland
Riolku has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest2663
Guest2453 has quit [Ping timeout: 480 seconds]
Riolku has quit [Remote host closed the connection]
Riolku has joined #wayland
<Riolku>
Hello! New to wayland protocols, is it correct that after committing a buffer, a client should not update the mapped contents? And thus that to do updates a new buffer is needed?
<Riolku>
Does it then make sense to alternate between a current and pending buffer on the client side, just like on the server? Like after attaching a new buffer, the old one can be reused?
nerdopolis has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
<jadahl>
Riolku: when you commit a buffer, you shouldn't manipulate its content until it's "released" (wl_buffer.release). when you prepare the content of the next frame, you should use another buffer, and commit the new buffer, i.e. "double buffering"
kts has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
Guest2663 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest2671
ascent12_ has quit []
ascent12 has joined #wayland
<ascent12>
Riolku: The compositor can hold onto your buffer longer than "expected", even if you've committed a different one, so you must wait for the release event before you reuse any buffers.
<Riolku>
i might need three buffers then, right? If buffer A hasnt been released, and I want to prepare a new frame after committing C
<ascent12>
I think in the theoretical worst case, you need 4, but 3 is more than good enough most of the time. At least 4 is the number mesa uses for e.g. vulkan swapchains.
<ascent12>
I don't know how much the 4th gets used in practice, especially if the client is actually waiting for wl_surface.frame
<ascent12>
I don't think a wl_shm would ever need 4 either
<ascent12>
wl_shm buffer*
<Riolku>
related question - do apps generally create one shm pool per buffer? that seems simplest
<ascent12>
Yeah there is nothing wrong with doing that.
<Riolku>
I suppose more complex applications can do freelist or proper allocaton stuff on a large pool?
<ascent12>
Probably more effort than it's worth to go too complex here. The difference between having 1 or 2/3 shared memory things open is negligible in the grand scheme of things.
<ascent12>
But you could put all of your buffers into the same shared memory if you really wanted to.
glennk has quit [Ping timeout: 480 seconds]
<ascent12>
Depending on how the compositor is implemented, they may release your wl_shm buffer immediately, because they copy it to their own GPU buffers straight away.
<ascent12>
So you could potentially only need 1
<ascent12>
But that's not really the best assumption to make, and a client should be prepared to make more if needed.
iomari891 has joined #wayland
iomari892 has quit [Read error: Connection reset by peer]
<Riolku>
Makes sense, Ill definitely just make pools as needed
<Riolku>
ty
tzimmermann has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
sima has joined #wayland
tent405 has quit [Quit: tent405]
kts has joined #wayland
vyivel has quit [Read error: Connection reset by peer]
ofourdan has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
vyivel has joined #wayland
<kennylevinsen>
Riolku any1: 4 buffers can happen during direct scanout: One buffer currently displayed by drm, one committed to drm to replace it, one held by the compositor as the next to be committed to drm, and one used by the client to draw
<kennylevinsen>
The reason being that we cannot replace or amend a drm commit, so if new buffers come afterwards - too bad, they have to wait
<kennylevinsen>
During composition it is 3 buffers: One buffer held by the compositor to composite the current screen from, one held by the compositor to replace it, and one used by the client to draw
Serus has quit [Quit: WeeChat 3.8]
<kennylevinsen>
But they are worst-case numbers. For shm specifically there is even an optimization where some compositors release the buffer early so the client can do with 1
mvlad has joined #wayland
glennk has joined #wayland
Dami_Lu has quit []
Company has quit [Remote host closed the connection]
<soreau>
Often times, there are unused listener interface functions in the (client) code. Is there a way that the unused function pointers can be set to NULL and have the scanner do a NULL check instead of forcing definition of each?
<emersion>
that would be nice
tristianc6704 has joined #wayland
vyivel has joined #wayland
DPA2 has quit [Ping timeout: 480 seconds]
DPA has joined #wayland
<soreau>
Actually not the scanner, but libwayland. It seems it's as simple as http://ix.io/4IyH
<soreau>
emersion: any 'gotchas' you can think of besides this patch alone?
<emersion>
need to handle resource cleanup
<emersion>
for FDs and server-side objects, at least
<soreau>
should it call wl_closure_clear_fds(closure); before retruning?
<soreau>
I mean would that be enough to do what you're saying
iomari892 has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
vyivel has quit [Read error: Connection reset by peer]
<soreau>
made it so it only allows NULL for clients, to side step having to destroy any new_ids
<emersion>
what do you mean by side step?
<soreau>
i.e. still use the same abort for servers but not clients
<emersion>
clients need to handle new ids as well
<soreau>
oh, I misunderstood the comments then
vyivel has quit [Read error: Connection reset by peer]
neatversion has joined #wayland
rgallaispou has left #wayland [#wayland]
vyivel has joined #wayland
pochu has joined #wayland
<pq>
soreau, emersion, I can see why it might seem convenient to be able to use NULL as an event handler when you don't care about it. I am opposed though, because the empty functions have documentary value, and using NULL is not simple for libwayland in the corner cases of fd and new_id arguments.
<pq>
Sure, libwayland-client can just close an fd, but the new_id essentially explodes into the full "automatic implementation of inert objects" problem.
<pq>
What if the new_id object immediately delivers an event with a new_id.
<pq>
libwayland-client would not be able to automatically destroy all theoretically existing objects either, because the destroy sequence could be more complex than a simple destructor call.
<pq>
not all interfaces even have an explicit destructor
vyivel has quit [Read error: Connection reset by peer]
<pq>
All that makes it really hard to see how the libwayland-client implementation could be safe.
<pq>
OTOH, an explicit implementation in the caller of libwayland-client is always specific to a particular interface and is therefore easy to review to be always correct.
<soreau>
but if you do not want to entertain this, please close the MR with a comment
<pq>
soreau, try the same with an event carrying a new_id.
<soreau>
pq: does this event not carry a new_id?
<pq>
then, with the new_id using an interface that has no desctructor request but gets destroyed by other means.
<pq>
it does
<pq>
you can craft tests that show that no *existing* protocol interface is able to break your auto-ignore-destroy logic, but I believe I can always craft a new protocol interface that will break it.
<soreau>
clearly, this would be a waste of time
<pq>
yes
junaid has joined #wayland
vyivel has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
neatversion has quit []
junaid has quit [Remote host closed the connection]
vyivel has quit [Ping timeout: 480 seconds]
vyivel has joined #wayland
nerdopolis has joined #wayland
kts has joined #wayland
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
DemiMarie has joined #wayland
<DemiMarie>
How do compositors with server-side decorations deal with clients that commit with a different size than expected?
fmuellner has joined #wayland
<pq>
I'm happy to see the proposal and the review discussion on the xdg-alignment protocol.
<pq>
DemiMarie, simply draw decors for the actual size?
glennk has joined #wayland
<pq>
either the protocol allows a different size, which means the compositor deals with it, or protocol doesn't which leads to disconnection with a protocol error.
<DemiMarie>
pq d_ed: question is *how* to deal with it, considering that I am writing a seamless compositor with a backend that expects me to submit a buffer with the exact size that it requested.
<kennylevinsen>
DemiMarie: Server-side decorations are drawn around whatever buffer the client commits
<kennylevinsen>
as the client decides the size of the window whenever it commits a buffer
<DemiMarie>
d_ed: The protocol I am using for drawing expects that its own idea of the window size is authoritative.
<kennylevinsen>
DemiMarie: Your own protocol can dictate whatever behavior you want, including requiring implementing clients to strictly adhere upon an ack-ed configure or similar
<kennylevinsen>
but that will not apply to "normal" wayland clients using e.g. xdg-shell
<DemiMarie>
kennylevinsen: I don’t have control of either side here.
Moprius has joined #wayland
vyivel has quit [Remote host closed the connection]
<DemiMarie>
I’m trying to figure out how best to deal with this (bad) situation.
<kennylevinsen>
In that case you must accept that the client dictates the window size and have the SSD conform to it
<kennylevinsen>
When tiling, sway clips windows if the containiner is smaller than the window can/will render, and centers the content when larger, but that is bad UX for a floating window
<DemiMarie>
kennylevinsen: This is a rootless compositor, and the backend protocol is itself backed by an X11 WM that can and will impose whatever policies it wants.
<DemiMarie>
Would it be best to tell the client that it is tiled?
<kennylevinsen>
DemiMarie: only if the client *is* tiled
<pq>
DemiMarie, if Wayland says window size can be any, and your own API requires a specific size, then I'm sorry. clip/scale/stretch/pad...
<DemiMarie>
kennylevinsen: It may or may not be (I don’t know that), but it is the only way I can think of to prevent infinite resize loops.
<pq>
nothing to do with decorations, too
<DemiMarie>
pq: yeah, the long-term solution is cross-VM Wayland but that is a *much* larger project.
<pq>
Since clipping may lose vital window content, I would probably do an aspect-ratio-preserving scaling with padding.
<DemiMarie>
And yeah, nothing to do with decorations. It just means that writing a conformant rootless compositor with an X11 backend is not possible.
<DemiMarie>
Not without the risk of infinite resize loops or ugly heuristics to break them.
<pq>
why is it not possible? Wayland client with X11 WM seems like the best arrangement if you have to cross-plant a window.
<pq>
X11 apps can already disagree with the X11 WM, too
<kennylevinsen>
DemiMarie: Even with the states that set requirements to dimensions (e.g., maximized and fullscreen), these are only followed when acked so there can be an artbirary number of frames with a different dimension
<pq>
the result is clip / pad with garbage, so at least when you can scale + pad, you are already doing better than X11
<DemiMarie>
pq: because client-initiated resizes need to work (think Ctrl-+ in various terminal emulators) and I need to somehow distinguish between “client resized window” and “client is responding to server-initiated resize”.
<kennylevinsen>
sway used to do this IIRC - it's an issue with X clients primarily. The best solution is send e.g. configure events on drag-to-resize, but always rendering the at any time client-submitted dimensions
<kennylevinsen>
that deals better with clients that have, say, aspect-ratio restrictions
vyivel has quit [Read error: Connection reset by peer]
<pq>
DemiMarie, what's the conflict or problem there? Why do you even need to make that difference?
<pq>
DemiMarie, although, with Wayland ack_configure, you can know what is a reaction to a configure event. It just may be combined with client spontaneous resize.
vyivel has joined #wayland
luyn has joined #wayland
<luyn>
pq: Thank you for responding to my proposal to add wl_pointer.button_position
<pq>
luyn, you're welcome.
mbalmer has quit [Read error: Connection reset by peer]
mbalmer has joined #wayland
Leopold__ has joined #wayland
<luyn>
This problem can also be reproduced not only on kwin, but also on other compositor. I think button_position is very necessary to add. It is unclear whether there are other scenarios where the position is not updated.
Leopold_ has quit [Remote host closed the connection]
Leopold__ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
kts has quit [Quit: Leaving]
<pq>
luyn, no, I think it's the compositors that just didn't realize what to do when the window moves under the pointer. After all, it takes great care to even observe the problem by not accidentally moving the mouse one bit.
rv1sr has joined #wayland
<DemiMarie>
pq: the problem is that I have never written a compositor before, and was not sure what to do.
<DemiMarie>
pq kennylevinsen: thanks for the help!
<pq>
DemiMarie, alright, in that case kennylevinsen said what's good to do. :-)
<pq>
as I'm accustomed to the protocol asynchronicity, it's kind of obvious to me that the compositor always paints what it got, not what it asked for.
rv1sr has quit []
<pq>
the same applies to window states
<pq>
if the compositor tells the client window to go from windowed to maximized, the compositor will keep on drawing it windowed until the client acks the maximized state
kts has joined #wayland
kts has quit []
rv1sr has joined #wayland
<luyn>
pq: Thank you. Do you have any suggestions for this problem
Moprius has quit [Quit: bye]
rv1sr has quit []
<pq>
luyn, yeah, it's in that reply I left in your MR.
mbalmer has quit []
kts has joined #wayland
Company has joined #wayland
cmichael has quit [Quit: Leaving]
privacy has joined #wayland
rv1sr has joined #wayland
tent405 has joined #wayland
agd5f has quit [Read error: No route to host]
agd5f has joined #wayland
privacy has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
pochu has quit [Ping timeout: 480 seconds]
<Riolku>
can i attach one buffer to multiple surfaces? If so, do I have to refcount the release events?
<Riolku>
ah, the docs say I shouldnt do this, and should instead create multiple buffers from the same backing storage, because release events are undefined if i reuse a buffer