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
Dami_Lu has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
michel has joined #wayland
test1234 has joined #wayland
michel has quit []
Wra1th has joined #wayland
pseigo has joined #wayland
Wra1th has left #wayland [#wayland]
test1234 has quit []
Arnavion has quit [Quit: Arnavion]
shankaru has joined #wayland
Arnavion has joined #wayland
ppascher has joined #wayland
jgrulich has joined #wayland
dcz_ has joined #wayland
hardening has joined #wayland
shankaru has quit [Quit: Leaving.]
eroux has joined #wayland
tzimmermann has joined #wayland
wvanhauwaert has joined #wayland
danvet has joined #wayland
rustylerp has joined #wayland
MajorBiscuit has joined #wayland
peeterm has quit []
peeterm has joined #wayland
peeterm has quit []
peeterm has joined #wayland
Company has quit [Quit: Leaving]
<pq>
MrCooper, a compositor is not allowed to read a wl_buffer before the wl_surface.commit that attaches it, so there is no way the compositor could retain the wl_buffer contents, semantically.
<MrCooper>
right
<emersion>
it's not about the contents
<emersion>
it's about the wl_buffer object
<emersion>
what all other wayland requests allow is: use_object(object); object_)destroy(object);
<pq>
MrCooper, whether wl_surface.attach(buffer); wl_buffer_destroy(buffer); wl_surface.commit(); is equal to attach+commit NULL buffer or retaining the old surface contents is up for debate, but I don't think there is a protocol error already defined, so adding a protocol error for this could be a client-killing change.
<emersion>
if we had wl_shm_buffer_ref() it would be trivial to ref on attach
<emersion>
and make it so the wl_shjm_buffer remains intact when destroyed by the client
<emersion>
no need to read the actual contents before commit
mbalmer has joined #wayland
<pq>
emersion, exactly: the wl_buffer object disappears before you can look into it at commit time.
<emersion>
this is a libwayland-client issue
<pq>
emersion, all the other Wayland interfaces that allow create/apply/destroy/commit workflow mandate in the protocol spec that the compositor makes a copy of the data at apply time. wl_buffers must never be copied before commit.
<emersion>
no copy
<emersion>
a reference
<pq>
IOW, if a client does attach, destroy, commit, it's a client bug with undefined compositor behaviour.
<pq>
there are no such references at the protocol level: wl_buffer is the reference, and the client just destroyed that before the compositor could do anything with it.
<pq>
wl_shm_buffer_ref() on attach wop
<pq>
wl_shm_buffer_ref() on attach would be wrong.
<emersion>
that's not my reading of the spec
<pq>
before commit the buffer is only pending, so not really with the compositor
pseigo has quit [Ping timeout: 480 seconds]
<pq>
This is my intention, certainly.
<pq>
Why should this become a good thing to do?
<emersion>
consistency with the rest of the protocol
<pq>
we already had really hard time justifying that destroying buffer immediately after commit and before release has some defined semantics, and I really do not want to extend that.
* emersion
shrugs
<pq>
sorry, but this is the early protocol design. You cannot apply consistency in hindsight.
<emersion>
i don't really care
<pq>
it is what it is, file the fix under wayland 2.0
<emersion>
wlr supports this behavior, and i won't change it
<pq>
good
GentooPhysicist39354 has quit []
<pq>
it's undefined behaviour, so there is not need to change it
<emersion>
> wl_shm_buffer_ref() on attach would be wrong.
<emersion>
wl_shm_buffer_ref doesn't exist
<emersion>
but regardless, the pain exists with destroy-after-commit too
<pq>
the whole point of wl_surface.commit is that it samples the pending state at the time of commit. If a client destroyed the pending buffer, there is no pending buffer.
GentooPhysicist39354 has joined #wayland
<emersion>
that seems like your idea of the commit request
<emersion>
your PoV*
<pq>
yes, because I designed it
<pq>
wl_surface.attach *must not* do any more than track the current pending buffer.
<pq>
wl_surface.attach must not e.g. validate the buffer in any way, because other state may affect the validation. So to *keep consistent*, attach must not actually do *anything*.
<emersion>
that's an impossible thing to do
<pq>
weston does that
<emersion>
attach must *at least* stash the pointer and setup a destroy listener
<pq>
...
<emersion>
increasing a ref count is not very much different from that
<pq>
yeah, twist my words, skip my lines
<pq>
pq> wl_surface.attach *must not* do any more than track the current pending
<pq>
buffer.
<emersion>
ref'counting counts as "track the current pending buffer" for me
<pq>
you track the wl_buffer, not what it points to
<emersion>
just like inert objects exist, there can be times when the compositor needs to keep a resource state longer than the client does
<pq>
do we at least agree that it is bad form for a client to attach/destroy/commit?
<pq>
that's only *after* commit
<pq>
Would I design the wl_surface interface differently today? Very likely. But we're stuck with what we have, unless replacing it.
<Levans>
Hmm, just asking the question: about the "destroying the buffer after commit but before release" part, are you saying that it should be considered a 100% valid thing to do, and as such that the compositor *must* copy the buffer contents on commit?
<emersion>
no copy
<emersion>
just keep the reference to the underlying storage
<pq>
Levans, not "must copy", but "must keep a hold of it". Destroy before release is only defined for when the client will not re-use the buffer's storage.
<emersion>
yes, destroy after attach but before commit is bad
<Levans>
Ok, so a client that destroys the buffer before release promises that it'll not modify the underlying storage ever again. Got it, thanks.
<emersion>
yeah
<pq>
yup
<emersion>
useful for client teardown, and for one-shot buffers
<emersion>
e.g. swaybg uses it to upload a shm buffer with the user's background image
<emersion>
and then destroy it immediately to use less RAM, and let the compositor drop the memory once the GPU upload is complete
<pq>
The no-"must copy" remark is only valid if the OS allows the compositor to keep a hold. If you are on an operating system where the client does literally destroy also the storage, pulling out under compositor's feet, then the compositor is screwed no matter if it copies or not: the copy might not have finished when the client destroys it.
GentooPhysicist39354 has quit []
GentooPhysicist39354 has joined #wayland
<jadahl>
pq: emersion: fwiw, mutter treats wl_surface_attach(s, b), wl_buffer_destroy(b), wl_surface_commit(c) the same as attaching a NULL buffer
<emersion>
weston probably does the same
<pq>
probably
<pq>
it's a case I suspect I'd never had even considered
mvlad has joined #wayland
rustylerp has quit [Ping timeout: 480 seconds]
<jadahl>
either way, i'm not interested in changing it, just to let clients be lazy and crash if run on older compositors
<wb9688>
Without that diff it works fine, but I'm not sure why this diff causes there to be a wrapper
<davidre>
I see wlroots, is this a compositor?
<wb9688>
No, it's client-side
<wb9688>
It's just supporting the wlroots protocol for output management
<davidre>
Ah ok,there was a chance that calling the function on a wrong object
<davidre>
And also me being a bit confused :)
<davidre>
You could always break on wl_proxy_create wrapper tosee who is calling it
<wb9688>
When breaking on wl_proxy_create_wrapper it seems to be called by wl_display_roundtrip_queue
<davidre>
Only instance or are there more hits?
<wb9688>
Twice, but in another file and that also happens before applying this diff
<davidre>
No other hits? I think wl_proxy_create_wrapper is the only place where ti sets FLAG_WRAPPER
<davidre>
Or something is writing over it by accident?
<kennylevinsen>
I'd log the head pointer in xw_output_wlroots_new and likewise in xw_output_wlroots_constructed to see if it's the same. You can also look at WAYLAND_DEBUG=1 to see what the actual object ID should be.
jgrulich has quit [Quit: Konversation terminated!]
jgrulich has joined #wayland
<kennylevinsen>
I'm not fluent in glib, but my suspicion would be that you add listener on a wrong/stale object
<wb9688>
It seems like not the same pointer indeed, thanks!
<wb9688>
Now I just need to figure out how I could make GLib not do this…
Company has joined #wayland
wvanhauwaert has quit [Quit: Leaving]
wvanhauwaert has joined #wayland
jgrulich has quit [Ping timeout: 480 seconds]
<wb9688>
Now I tried g_object_new_with_properties instead of g_object_new it works, so I think I did something wrong there
wvanhauwaert has quit [Ping timeout: 480 seconds]
agd5f_ has quit []
agd5f has joined #wayland
ybogdano has joined #wayland
<wb9688>
Ah, g_object_new apparently wraps it into a GValue for me while I was also wrapping it into a GValue myself. g_object_new_with_properties wants you to wrap it into a GValue yourself, so that's why that was working.
devilhorns has quit [Remote host closed the connection]
<that_guy>
so I'm drawing some very simple decorations, just a few px border of a solid color -- is there a way to get a buffer to tile on a surface? or do I have to actually have h*w*depth*scale bytes allocated?
<emersion>
you can use subsurfaces
<emersion>
and viewporter if you want to stick to a 1x1 buffer and then scale it
<emersion>
(and the upcoming single-pixel-buffer proto if you want to skip wl_shm)
fmuellner has quit [Ping timeout: 480 seconds]
pseigo has quit [Read error: No route to host]
pseigo has joined #wayland
pseigo has quit []
pseigo has joined #wayland
<that_guy>
yeah so I'm using subsurfaces to stick the decorations where they need to be
<that_guy>
didn't think to look at the viewporter, will look at that, thanks
<wb9688>
If you were wondering what I was working on: it is libxw - https://github.com/wb9688/libxw , a library for making GTK panels that abstracts getting toplevels, workspaces, outputs, etc. It will support the Wayland protocols from wlroots and KDE, and also X11. It is far from finished, but I will be working a lot on it the coming days and already have more code locally. Because it seems
<wb9688>
like there is no progress in getting new protocols for panels merged into wayland-protocols, including ammen99's workspace protocol and ifreund's toplevel protocols, I also started xw-protocols - https://github.com/wb9688/xw-protocols , which contains the before mentioned protocols but renamed and is also going to contain new protocols like xw-foreign-toplevel-workspace to integrate
<wb9688>
xw-foreign-toplevel-info with xw-workspace. ammen99 has said that he would want support for xw-protocols in Wayfire core.
<emersion>
that's unfortunate :(
<wb9688>
emersion: Why is that unfortunate?
<emersion>
that this isn't getting through wayland-protocols
<emersion>
i would NACK support for these in wlroots, fwiw
<emersion>
wayland-protocols ensures that the protocols are high-quality
<emersion>
the requirements for ext- protocols is pretty low
<emersion>
are*
<wb9688>
NACK because of the quality or NACK because wlr-protocols doesn't accept new protocols anymore?
<emersion>
NACK because the proper way to do this is to go through wayland-protocols
pseigo has quit [Quit: left]
pseigo_ has joined #wayland
<emersion>
wayland-protocols has superseded wlr-protocols
<wb9688>
I know, but it does not seem like any such protocols are merged and both ifreund and ammen99[m] have given up on their protocols
<i509VCB>
The ext-foreign-toplevel-info protocol would be nice to have in wayland-protocols, but that implies someone actually working on it
<emersion>
wb9688: yes, they're not merged because of the lack of manpower
<wb9688>
Well, GNOME isn't on board anyway for these kind of protocols, so there is only wlroots and KDE left, with KDE having solved things in their own way making this less of a priority.
<emersion>
it's not about GNOME/KDE
<wb9688>
And it indeed takes a lot of time to get someone else to review such a protocol, because of apparent lack of time/interest
<emersion>
the same people working on wlr-protocols are now working on wayland-protocols
<i509VCB>
I can say for certain the group of people I work with on smithay would be interested in that workspace stuff. I think drakulix was working on some stuff related to ext-workspace for cosmic?
<wb9688>
And I do agree that wayland-protocols would be the best place, but if it is not happening there, we will do it somewhere else so we can actually have something that users can use
<emersion>
if you, ammen99 and potentially other people are interested in this protocol, i don't see why it can't be in wayland-protocols
<wb9688>
Well, if it can be, that would be the ideal situation
<wb9688>
And then I could just throw away xw-protocols
<emersion>
someone needs to submit the MR, someone needs to review, etc
ammen99_ has joined #wayland
<i509VCB>
emersion since you happen to be around, was there any discussion about the proposed protocol to attach the driver and device uuid to a wl_buffer? I know one concern that was brought up is lying clients (since a lying client could cause undefined behavior)
<emersion>
also i'm not sure it would really help a lot
<emersion>
if you have a buffer coming from vaapi or v4l2, maybe it can be scanned out, even if the device doesn't match
<daniels>
emersion, pq: fwiw I would personally - even though the only two compositors I use are Weston & Mutter - support an ext (or protocol revision …) which enforced emersion’s view that an attach is a buffer storage ref, with the storage remaining compositor-accessible even after object destroy
<emersion>
i509VCB: oh... for memory barriers, i see. yeah, i'm not sure how to resolve that without some kind of "is this a local buffer" DRM IOCTL
maxzor_ has joined #wayland
<emersion>
and that wouldn't be enough…
<emersion>
we definitely need a GL/Vulkan spec to generate cryptographically signed certificates which can be checked by the compositor
<wb9688>
emersion: So you are saying it should be possible to get these protocols merged into wayland-protocols if I continue ifreund's work? If so, what would be the requirements for getting it merged?
<emersion>
wb9688: one review from someone familiar with wayland-protocols, 1 client + 1 server impl, and then hopefully a wlr member can slap an ACK and merge it
<emersion>
"hopefully" = if the member doesn't see any issue in the proto
<emersion>
s/familiar with wayland-protocols/familiar with wayland protocol design/
<wb9688>
emersion: So if I continue it and get e.g. ammen99[m] to review it, it would be enough to get merged?
<emersion>
yeah, it could
<emersion>
maybe also ask for feedback from i509VCB as well
pseigo_ has quit [Ping timeout: 480 seconds]
<i509VCB>
I would be willing to look at the protocols wb9688, just poke me here or mention me in the MR so I can subscribe to it.
<wb9688>
In that case, it seems like xw-protocols won't be needed after all
<i509VCB>
One protocol idea I've had in my head for some time is a debug info protocol of sorts. The gist of the protocol is to provide the client some information about the compositor for debugging or bug report purposes.
<wb9688>
i509VCB: I'll be sure to ping you then
pseigo_ has joined #wayland
<emersion>
i509VCB: sounds like this would potentially leak stuff, disclose global info, etc?
<emersion>
compositor logs should be enough?
<i509VCB>
Yeah I definitely spent a lot of time deliberating whether this info is too sensitive to expose
<i509VCB>
Plus weird clients could match on the compositor name and start doing compositor specific behavior without any protocol negotiation. Don't want to create the landscape for Java swing detecting the x11 wm and behaving differently
<emersion>
eheh, to this day we still have to ask users to set _JAVA_AWT_WHATEVER=1 to make java behave properly
<wb9688>
Yeah… that's just stupid
<i509VCB>
Hopefully the proposed Wayland support for swing will be less hacky
<dottedmag>
Because everybody is still using Mozilla/5.0, ahem, Compiz.
<wb9688>
Lol wow
<ifreund>
wb9688: protocols do get merged to wayland-protocols if they are high enough quality and solve problems that wayland compositor maintainers care about
<ifreund>
this process can even move quite quickly if all parties involved are active, see e.g. ext-session-lock-v1
<wb9688>
Ah, indeed
<ifreund>
In the case of ext-toplevel-info/management, I don't think they are a big enough step forward to be worth my limited time/attention
<wb9688>
I think it would be if there would also be an ext-foreign-toplevel-workspace integrating it with ext-workspace, and I would be interested in working on that
<ifreund>
I personally think abstracting over radically different window management approaches in the way that ext-workspace does brings too much accidental complexity into the system
<ifreund>
I probably won't implement it
neonking__ has joined #wayland
<wb9688>
Ah
<wb9688>
ifreund: But did you think the quality of -info/-management was generally OK (other than not using an add-on object)?
mvlad has quit [Remote host closed the connection]
<ifreund>
I guess I did 2 years ago or whenever that was
neonking_ has quit [Ping timeout: 480 seconds]
<wb9688>
Ah, in that case it seems there is not much to do for me on those protocols (other than the using an add-on object in -management), but more implementing it and getting people to review it and writing -workspace as well to have workspace information about the toplevels
neonking_ has joined #wayland
<ifreund>
I'm not sure if it's something I want my compositor to support long term tbh, I think keeping the number of priviledged/abusable protocols to a minimum is important to avoid clients doing stupid things that break policy over mechanisim
<wb9688>
Well, my goal is basically to have panels that could work cross-compositor
<wb9688>
Also, does anyone know why I suddenly don't have an account on gitlab.freedesktop.org anymore?
neonking__ has quit [Ping timeout: 480 seconds]
<ifreund>
there was a large purge of inactive accounts without comments/repos to combat spam
<ifreund>
perhaps yours got accidentally caught up in that :/
<ifreund>
if you run into troubles the folks in #freedesktop can likely help
<wb9688>
Ah, probably
<wb9688>
Hmm… it seems like I can not register without real name now?
<wb9688>
Ah, I could just fill in W as first name and B as last name, but it seems like I now need to wait for manual approval
jmdaemon has joined #wayland
<wb9688>
ifreund: Does your compositor currently support wlr-foreign-toplevel-management though? And if so, what would you otherwise want in the future?
<wb9688>
Also, thanks for your responses and help so far!
<ifreund>
wb9688: yes, it currently supports wlr-foreign-toplevel-management. I don't know exactly what I want long term, but I have some architectural changes I want to explore for river and see where things go.