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
ahartmetz has quit [Quit: Konversation terminated!]
sych1ll has quit [Ping timeout: 480 seconds]
Seirdy has quit [Ping timeout: 480 seconds]
sychill has joined #wayland
jmdaemon has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
slattann has joined #wayland
hill has joined #wayland
Seirdy has joined #wayland
pounce has joined #wayland
pounce has quit [Remote host closed the connection]
pounce has joined #wayland
Company has quit [Quit: Leaving]
pounce has quit [Remote host closed the connection]
pounce has joined #wayland
pounce has quit [Remote host closed the connection]
pounce has joined #wayland
Arnavion has quit [Quit: Arnavion]
slattann has quit [Ping timeout: 480 seconds]
txtsd is now known as Guest1912
txtsd has joined #wayland
Guest1912 has quit [Ping timeout: 480 seconds]
slattann has joined #wayland
Arnavion has joined #wayland
pounce has quit [Remote host closed the connection]
pounce has joined #wayland
dcz_ has joined #wayland
hill has quit [Remote host closed the connection]
hill has joined #wayland
danvet has joined #wayland
tzimmermann has joined #wayland
ofourdan_ has left #wayland [#wayland]
ofourdan has joined #wayland
hill has quit []
progandy[m] has joined #wayland
hardening has joined #wayland
wv has joined #wayland
progandy[m] has quit []
jagan_ has joined #wayland
mbalmer has quit []
<pq>
i509VCB, at least device major/minor numbers are not guaranteed stable across reboots. (I don't recall what the comparison is used for.) GPU hotplug/unplug have the same problem.
shankaru has joined #wayland
<pq>
daniels, did we not discuss that already? I said it's fine if you add screaming instead of asserts too. In any case, let's discuss it in Gitlab once it's back to not split and forget.
<MrCooper>
daniels: one thing I noticed reading protocol docs over the weekend is that destroying or unmapping a parent surface is supposed to unmap descendant surfaces; I wonder if that's supposed to be handled as the equivalent of attaching a NULL buffer, or something else?
<pq>
daniels, I will object to having views for a surface mapped, when the surface is not mapped, because a mapped view *can* be visible and is not reliably always ignored. That's how I think the concepts should work.
<pq>
"mapped" means: is present in the scenegraph with a defined position and z-order.
<pq>
MrCooper, what do you meant by "equivalent"?
<MrCooper>
I mean, should the compositor internally attach a NULL buffer to the descendant surfaces?
<pq>
I don't see why, and it would break protocol state tracking.
<pq>
MrCooper, to me, "has a non-NULL buffer attached last" is a necessary requirement for having a surface mapped, but not sufficient. A surface with content can be in unmapped state.
<MrCooper>
k, thanks
<emersion>
pq, xdg_surface doesn't really allow it (but other roles do)
<pq>
emersion, allow what?
<emersion>
ie, when you create an xdg_surface, it must not have a buffer attached
<emersion>
i guess you can destroy the xdg_surface object, then the wl_surface would still have a buffer attached, and be unmapped
<pq>
exactly
<pq>
wl_surface retains its state, right?
<emersion>
yea
<pq>
so if you want to map again, you'd need to explicitly attach NULL buffer first
<emersion>
things like cursors work differently
<pq>
yes, because they are not xdg_surface, and do not have the map negotion hand-shake.
<pq>
*negotiation
<pq>
We *could* have "unmap causes the attached buffer to be forgotten", but I don't think that has ever been written down nor expected, so it would be a breaking change IMO.
<pq>
at least if defined in wl_surface
<pq>
it also wouldn't make always sense, e.g. with cursors
<pq>
the mapped state of a cursor wl_surface might be a bit vague concept in the first place, because the compositor may choose to stop using that wl_surface at any time.
rasterman has joined #wayland
<jadahl>
pq: it's more so that unmap without attach(null) does *not* forget the buffer, since (iirc) it's mentioned in xdg-shell that one must attach a null buffer before remapping a xdg_surface
<MrCooper>
jadahl: reading that in the protocol docs made me wonder if mutter is correctly unmapping the descendants of destroyed or unmapped parent surfaces
<jadahl>
MrCooper: a quick check makes it look like a subsurface will remove itself from the tree if its parent got destoryed, but perhaps not unmapped
<MrCooper>
maybe it ends up kind of the same, since the descendants will no longer be reachable from any toplevel?
<jadahl>
subsurfaces attach themself to the toplevel (i.e. xdg-surface), not to the parent though
<jadahl>
i mean, in mutter/clutter
<jadahl>
before the "flattening" of the actor tree, it probably worked
___nick___ has joined #wayland
alarumbe has quit [Ping timeout: 480 seconds]
<zubzub>
do I need a library like libseat to take care of permissions if I want to make sure/take care of gpu device permissions when using linux_dmabuf_v1/wl_drm as non-root?
<zubzub>
I've implemented wlroots linux_dmabuf_v1 but the client seems to get a permission error about the device I give it (I don't use libseat for now and have my own device lookup function)
<zubzub>
(not sure about permission)
<emersion>
you need to only open render nodes
<emersion>
libseat wouldn't help, since i assume another DRM master is running?
<zubzub>
yes
<emersion>
render nodes don't need permissions
<zubzub>
I don't need to render to a screen
<zubzub>
ok
<emersion>
primary nodes are restricted
<emersion>
the wlroots impl works without any special permission FWIW
<zubzub>
yeah, I'm trying to figure out what's wrong. I open /dev/dri/renderD128, do the whole egl setup (based on wlroots implementation), all works fine, pass the whole egl setup (device & context) to gstreamer, who's happy with it. Use that setup to setup linux_dmabuf_v1 (also wlroots implementation), yet when I run gtk4, it fallbacks to sh, and when I run weston-simple-dmabuf-feedback, it get's an assertion