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
<mriesch>
i have a setup in which the output is activated when the hdmi cable is plugged in, but when after hotplug, the hdmi output is repeatedly enabled and then disabled (no heads left) after a while
<daniels>
mriesch: ahhh yeah, that might be worth looking at
<mriesch>
daniels: quick glance at the logfiles of both cases (fresh start vs. hotplug) tells me that Layer 0 has View 0 after a fresh start but [no views] after hotplug
pym__ has joined #wayland
<mriesch>
what do layers and views mean (roughly) in weston context?
<daniels>
mriesch: a view is an instantiation of a surface to be displayed; views are grouped into layers
<daniels>
which shell are you using?
<mriesch>
desktop-shell
<daniels>
hrm
<daniels>
maybe that's broken recently then, but it certainly should be sprawling iirc
<zubzub>
What are the minimum required steps to get wayland-drm working, working as in, get eglimages from a client? I currently have an egldisplay, created from a gbm device. I use this egl display to call eglBindWaylandDisplayWL (so no context creation or make current at that point). This egldisplay seems to work fine as I can pass it on to gstreamer who happily uses it to do it's gl thangs. However when I
<zubzub>
launch ie weston-simple-egl, it fails on eglInitialize.
<zubzub>
are there any implicit steps I need to do, or is there perhaps some protocol calls that I'm screwing up?
<mriesch>
daniels: ok, so there are two views, the desktop shell fade surface and the background. the former is only visible after a fresh start -> makes sense, right?
<pq>
zubzub, hmm, I wonder... did Mesa stop supporting wl_drm client-side? That means your compositor needs to implement zwp_linux_dmabuf_v1 extension. That would be a good idea anyway.
<zubzub>
D:
<pq>
seems a bit unlikely to me for Mesa to do that, but I dunno
<zubzub>
I was hoping to make the simple implementation work first before taking a shot at zwp_linux_dmabuf_v1
<pq>
zubzub, btw. which DRM device node are you using on the compositor side for this?
<daniels>
mriesch: you should have a background for the output
<pq>
daniels, mriesch, btw. weston-desktop-shell has some unholy logic to avoid creating redundant backgrounds when outputs are mirrored. Maybe that might be tripping up?
<daniels>
as for Mesa requiring zwp_linux_dmabuf_v1 - we did briefly make that a requirement and axe support for wl_drm, but we had to back that out
<pq>
although, that should trip up also on fresh start, too...
<pq>
daniels, did wl_drm support require the compositor to be DRM master?
<emersion>
no
<pq>
I mean the whole auth cookie thing
<emersion>
wlroots has a minimal wl_drm impl if you want to look at it
<mriesch>
just out of curiousity, there are six layers. what exactly defines this number?
<daniels>
zubzub: does WAYLAND_DEBUG=client show the wl_drm global advertised? does the client try to bind to it?
<emersion>
pq, you can send a render node
<mriesch>
shell? drm driver?
<pq>
emersion, we are talking about the Mesa server-side implementtion of wl_drm specifically.
<daniels>
mriesch: it's defined by the shell
<emersion>
pq, that still doesn't require DRM master :)
<daniels>
mriesch: they're just a window-management primitive, so you can e.g. reshuffle your toplevel windows around without having to worry about the panel staying on top
<mriesch>
ah ok
<pq>
emersion, ok, good. One less idea of what could be wrong. :-p
<emersion>
i've fixed it so that glBindWaylandDisplay() works on non-GBM EGL
<emersion>
eglBindWaylandDisplay*
<emersion>
or w/e it's called
<pq>
could zubzub have old Mesa where it's not fixed?
<zubzub>
10:01 < pq> so, check that first, since I don't think anyone else has tested that in ages - everyone implements linux_dmabuf AFAIK
<zubzub>
shouldn't zwp_linux_dmabuf_v1 become stable then?
<pq>
it already is, and it cannot :-p
<pq>
hmm, maybe it could under the latests stabilization process
<emersion>
there would still be "z" in the anme which is unfortunate
<emersion>
also there is a list of breaking changes we want to make -- mostly cleanup, nothing major
<zubzub>
I was under the impression it was still unstable because of the z
<emersion>
name*
<zubzub>
good to know it's actually stable!
maxzor has quit [Ping timeout: 480 seconds]
<pq>
well, it's in the unstable category, because moving into the stable category would mean removing that 'z', which means everyone would need to implement both old and new name /o\
<pq>
and it's too widely used already (has been for years) to do that just for the sake of the one 'z'
<emersion>
yeah
<pq>
so, currently we live with it
<emersion>
"unstable" doesn't actually mean that breaking changes are allowed
<emersion>
^ very common misconception :S we should've picked a better name
<emersion>
in any case, the new naming scheme shouldn't have this issue anymore
<zubzub>
ah i see
<emersion>
i think README has all of the explanations
<ifreund>
It'd be nice to make some distinction between "unstable" protocols that everyone implements and broken stuff like input method v1
<ifreund>
though maybe that's best solved through that compositor support matrix website we'd all love to see happen
<emersion>
can't wait :P
<emersion>
this kind of stuff has way too much bikeshedding potential sadly
<davidre>
run wayland-info for every compositor for every version of said compositors to generate the table :D
dcz_ has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
<jadahl>
can just move it to stable, explain why the z is still there, remove the disclimer, and be done with it. those breaking changes won't happen anyway I'm going to assume