ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
fmuellner has quit [Ping timeout: 480 seconds]
sav10_ has joined #wayland
sav10 has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
zebrag has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
floof58 is now known as Guest1822
floof58 has joined #wayland
Guest1822 has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
Nico has quit []
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
smallville7123 is now known as Guest1827
smallville7123 has joined #wayland
Guest1827 has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
zebrag has joined #wayland
sav10_ has quit [Read error: No route to host]
nerdopolis has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
soreau has quit [Remote host closed the connection]
<smallville7123>
what mechanism does wayland use for shared memory transfer? specifically for ensuring the client and server dont try to read and write to shared memory simoultaniously
Leopold_ has quit [Remote host closed the connection]
smallville7123 is now known as Guest1837
smallville7123 has joined #wayland
smallville7123 is now known as Guest1838
smallville7123 has joined #wayland
Guest1837 has quit [Ping timeout: 480 seconds]
Guest1838 has quit [Ping timeout: 480 seconds]
sav10 has joined #wayland
Company has quit [Quit: Leaving]
sav10 has quit []
tzimmermann has joined #wayland
<kennylevinsen>
smallville7123: when the client wants to change the content on screen, they take an unused buffer, attach and submit it. They're then not allowed to touch this buffer again until the buffer is released by the compositor.
<kennylevinsen>
Assuming we are talking about shared memory for graphical content
dcz_ has joined #wayland
hardening has joined #wayland
<smallville7123>
hmm
<smallville7123>
so shared memory buffers are created and destroyed each frame?
Major_Biscuit has joined #wayland
<smallville7123>
kennylevinsen:
<kennylevinsen>
smallville7123: no, they can be reused after the compositor releases it. A client is often using 2 or 3 buffers in rotation.
<kennylevinsen>
(outside of a special optimization allowing certain software rendering clients to use just one buffer, clients actively rendering will need to use at least two buffers, but it occasionally grows to three)
jgrulich has joined #wayland
<pq>
smallville7123, in this case "release" is simply a message from compositor to the client saying the buffer is no longer read by the compositor.
<smallville7123>
hmm
<pq>
there is no mechanism employed to actually catch clients that would write at a buffer that a compositor is reading, it's just a protocol contract.
<smallville7123>
when a client is attached to wayland, does the client allocate a shared memory buffer and send it to the compositor for reading?
<pq>
yes
<pq>
but not when "attached to wayland"
<pq>
one wl_buffer is one frame or image, and clients allocate them when needed, and attach them to wl_surfaces when they want to so that the compositor can read them.
<smallville7123>
when are the buffers created and destroyed in a client's lifetime ?
<pq>
created whenever the client needs one, and destroyed whenever both the compositor and the client are no longer needing it.
<smallville7123>
how does the client determine if it needs a buffer?
danvet has joined #wayland
<pq>
when it wants to update a wl_surface's content
<smallville7123>
hmmm
<pq>
either the client allocates a new buffer or re-uses an existing free buffer
<pq>
there was a nice diagram about this somewhere...
<smallville7123>
so client: [ render, create buffer, attatch to wayland, copy render contents into buffer, wait for wayland to render buffer, destroy buffer ] ?
<pq>
almost, but not quite
<pq>
client: choose a free buffer (or allocate a new one); render into the buffer; attach the buffer to wl_surface; - repeat.
<pq>
but in parallel: client listens for buffer release events, and when it gets one, it marks that buffer as free for use again, or destroys it if it's e.g. wrong size.
<smallville7123>
hmmm ok
<pq>
a client always has a pool of buffers where it tracks whether each one is free for re-use or used by the compositor.
manuel__ has joined #wayland
<pq>
usually the pool starts empty, and the client allocates new buffers as needed, up to some maximum number
<pq>
when it reaches that maximum and still needs a free buffer, it waits for one to become free
<pq>
then there are separate frame rate throttling mechanisms, as this one is purely about buffer management.
glennk has quit [Remote host closed the connection]
glennk has joined #wayland
<smallville7123>
ok
<smallville7123>
would wayland directly read from this buffer into gpu ?
<smallville7123>
eg wayland: wait for buffer; copy buffer into texture; release buffer; composite texture
<pq>
a compositor could, and likely does, yes (not wayland)
<pq>
depends on the buffer type and compositor type, if you want to go into details
d_ed has joined #wayland
<smallville7123>
alright
jmdaemon has quit [Ping timeout: 480 seconds]
anarsoul has quit [Remote host closed the connection]
anarsoul has joined #wayland
gschwind has joined #wayland
<gschwind>
hello :)
devilhorns has joined #wayland
<yshui`>
hmm, the spec says the client must wait for a xdg_surface.configure before attaching a buffer, but not all clients are following this rule
<emersion>
they'd be disconnected with a protocol error if they don't
<emersion>
at least under wlroots
<yshui`>
the one i noticed is alacritty. does that work under wlroots?
<emersion>
yeah
<emersion>
how do you check whether it waits or not? protocol log, or reading the code?
<pq>
was ack_configure required in that case? Otherwise a client could be just lucky.
<yshui`>
well, i have a half working toy compositor that doesn't send any configure events @emersion 😅
<emersion>
yshui`: maybe alacritty assumes it'll get configure after a roundtrip, or something
<emersion>
if that's the case, please report this bug to them
<yshui`>
yeah, could be. and with a properly implemented compositor nobody would notice.
<yshui`>
hmm, is this violation serious? i can kind of understanding the rational behind the requirements, but letting the client choose whatever initial configuration they want doesn't sound too terrible?
<pq>
unless the compositor is a tiling one
<emersion>
if the compositor wants to open the client fullscreen, or maximized, or tiled, or restore a previous size…
<yshui`>
i see.
<emersion>
jadahl: any idea why GTK4 renders rounded corners for tiled windows?
<emersion>
ok, so that leaves it up to the compositor
<jadahl>
right
<emersion>
so, why do we need edge constraints? why isn't tiled_* enough?
<jadahl>
there are even settings for what middle click does :o
<jadahl>
it's to differentiate between tiled against a monitor edge and another tiled window
<emersion>
the right click sounds like it's xdg-shell open window menu thing?
<emersion>
ah
<emersion>
i see
<jadahl>
yea, right click maps to the menu iirc
<jadahl>
not sure if its worth the effort to introduce xdg_wm_tiling for edge constraints, but maybe its better
<jadahl>
to avoid piling more and more things inside xdg_wm_*base*
dngray[m] has joined #wayland
<d_ed>
jadahl: do you have users of system bell? I would have expected most usages being replaced with normal notification sounds.
<jadahl>
d_ed: terminals
<jadahl>
can't use just a sound because of a11y features
<jadahl>
sometimes it's a window flash, sometimes its a fullscreen flash, depending on the a11y settings
<pq>
would be really fun and annoying hook up a literal bell to that :-)
<jadahl>
e.g. for deaf people
<jadahl>
pq: it would :P
<d_ed>
so you don't need it for the bell itself, you need it for the fallback for the bell
<jadahl>
yes, so vte/gnome-terminal/gnome-console/... don't do any audible belling, they outsource it to the compositor to decide whether to making a visual bell or audible bell
<d_ed>
We also had an X11 fullscreen flash hooked up to the bell in our accessibility. Right now on wayland we don't do anything
Major_Biscuit has quit [Ping timeout: 480 seconds]
<jadahl>
d_ed: so in other words, you'd be interested in a bell protocol?
<d_ed>
If there are usages IRL, then yes
<jadahl>
there is, gnome-terminal et al, and maybe konsole would too perhaps? (personally I find any visual or audible bell frustratingly annoying though)
<d_ed>
I remember the days of my first office job, someone would cat a binary file at least once a week and we'd get a continual stream of beeps for seemingly eternity
<jadahl>
:D
<emersion>
a friend has picked the dog sound for the bell… always surprises me
<jadahl>
emersion: your friend will be sad because it was removed from gnome 43 (if that is where it came from)
<emersion>
oh no
<jadahl>
gnome did it again!
<emersion>
removing important features, time and time again!
<d_ed>
we can explicitly mention dog sounds in the spec
<d_ed>
<request name="beep"> <arg name="animal">
<emersion>
perfection
* kennylevinsen
passes "human" as argument
<jadahl>
kennylevinsen: a human barking or ?
<kennylevinsen>
I guess "human" should just be... random talk and/or groaning
<kennylevinsen>
unless the dog bark is a dog immitating a beep to the best of its ability
<kennylevinsen>
the protocol will need to clarify
<jadahl>
word by word from some book, only way to hear it is by pressing tab in a terminal where one gets multiple auto-complete options
<kennylevinsen>
and just before you have time to hear the final chapter... GNOME 44 comes out and swaps out the book
rasterman has joined #wayland
<jadahl>
kennylevinsen: anything else would be out of character
floof58 is now known as Guest1859
floof58 has joined #wayland
markbolhuis has joined #wayland
Guest1859 has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
<markbolhuis>
Hi all. When the client calls xdg_positioner.set_reactive, should the popup follow the parent surface?
smallville7123 has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
<jadahl>
markbolhuis: the popup always follows the parent. set_reactive means the compositor may re-constrain the popup given the positioner rules while it moves
<markbolhuis>
ok cool, just wondering since kde doesn't follow that rule
<jadahl>
the popup doesn't follow, or it isn't reconstrained?
<markbolhuis>
the popup isn't moved with the parent
<jadahl>
perhaps time to file a bug on kwin about it then
<emersion>
thanks for the GTK patch jadahl!
<jadahl>
np. seems gtk3 is the same, so will backport
<emersion>
hm, strangely i don't have this issue with GTK3
<jadahl>
oh?
<emersion>
maybe GTK3 doesn't request a high enough xdg-shell version?
<emersion>
(sway falls back to maximized in that case)
<markbolhuis>
will do
<jadahl>
emersion: that is probably why then, it binds an older version
<emersion>
makes sense
<jadahl>
not a backport then, but should be relatively simple to fix
<MrCooper>
to be clear, the above is equivalent to what you guys described for the special (rather common really :) case of block width & height 1, i.e. non-block-based formats
<DemiMarie>
MrCooper: what if the number of blocks in a row is not evenly divisible by the block height? Should that be a protocol error? And what if the height is not a multiple of the block height?