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
rasterman has quit [Quit: Gettin' stinky!]
dcz_ has joined #wayland
st3r4g has quit [Ping timeout: 480 seconds]
arinov has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
st3r4g has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
st3r4g has quit [Quit: おやすみ]
dcz_ has quit [Ping timeout: 480 seconds]
txtsd has quit [Ping timeout: 480 seconds]
boistordu_ex has joined #wayland
boistordu has quit [Ping timeout: 480 seconds]
xantoz has quit [Ping timeout: 480 seconds]
xantoz has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
immibis has quit [Remote host closed the connection]
immibis has joined #wayland
maxzor has joined #wayland
immibis has quit [Remote host closed the connection]
immibis has joined #wayland
johnsmith has quit [Ping timeout: 480 seconds]
c7s has quit [Ping timeout: 480 seconds]
jgrulich has joined #wayland
maxzor has quit [Remote host closed the connection]
<maxzor>
I wonder if any compositor makes use of that hardware-based blend of CRTC planes, or if they composite purely out of it. Is it a feature used like x11 drawing apis, which means not used?
<zubzub>
it's odd that libexec_weston.so.0 is resolved while libweston-10.so.0 is not
msisov has joined #wayland
msisov has quit []
<MrCooper>
ofourdan: third commit could definitely use a real commit log, and the randr changes could maybe be split out into a separate commit
<ofourdan>
MrCooper: mind adding that in the mr then?
msisov[m] has joined #wayland
<ofourdan>
(agreed, the randr change is preparation work)
<zubzub>
hmm it seems the rpath of the weston binary makes the libexec_weston.so resolve, but not the libweston.so
<MrCooper>
ofourdan: done
<ofourdan>
ty!
<SardemFF7>
zubzub: libexec_weston is an internal library installed in a non-standard location, libweston.so is a public library installed in a standard location, thus your system-wide ldconfig should make it discoverable, or LD_LIBRARY_PATH for more special installations
<zubzub>
so it's odd that it's not being picked up even though my LD_LIBRARY_PATH seems to be correct
<zubzub>
ah seems I have to add my $arch after $WLD/lib
<maxzor>
MrCooper What about the client? Does it make sense to draw the background of your app in the overlay plane and blend it with your primary plane?
<MrCooper>
maxzor: clients have no direct control over this, it's up to the compositor which (sub-)surfaces it puts on planes (which can change per output frame)
<maxzor>
As far as I understood clients can have a say in this if they get a low-level access to libdrm with things like egl
<maxzor>
to draw only in their little garden
<MrCooper>
that would be a display server then, not a Wayland client
<maxzor>
you can use DRM while not being DRM master
<maxzor>
I don't get it
<MrCooper>
you can't actually display anything without either being DRM master or making use of a display server which is
rgallaispou has joined #wayland
<MrCooper>
in the case of the latter being a Wayland compositor, clients can pass buffers to it for surfaces, but the compositor has full control over how they are actually displayed
easo2k has joined #wayland
<maxzor>
Can't I say as a client : ok Mr. display server, you are DRM master, but please make this small area of the screen there my realm and I will draw in my sub-frame buffer alone and will call libdrm to blend the planes in my realm
<maxzor>
Ahh I think that I get what you mean
easo2k has quit [Remote host closed the connection]
arinov has joined #wayland
<maxzor>
blending, and zpos are done at the scale of the plane not on a specific rectangle, so it makes sense that only the display servers manages that.
<pq>
zubzub, yeah, the $arch in the LD_LIBRARY_PATH is something that some distributions patch in to Meson, I think.
<pq>
maxzor, yeah, and even in more generally, you cannot ask for exclusive access to a region of an output. You cannot force the position or z-order of your window either. That is so with the usual set of Wayland extensions, and has nothing to do with DRM or KMS.
<pq>
maxzor, there also is no "the framebuffer" you could even ask access to. A display server with flip between multiple different buffers.
<pq>
*will flip
rasterman has joined #wayland
dcz_ has joined #wayland
<zubzub>
is it always expected that weston has a background shell view?
<zubzub>
(because if it's valid that there isn't a shell background view then dnd will break fyi)
<daniels>
yeah, expected
<daniels>
or required, even; else we'd just render garbage in areas not covered by client views
<zubzub>
👌
<MrCooper>
maxzor: in fact, a Wayland compositor may not even display client surfaces as rectangles, it can apply arbitrary transformations :)
<maxzor>
I wonder if there is the hardware architecture in gpus to composite framebuffers at the level of end-user applications like there is in the scanout line for the display server
<maxzor>
(basically I know nothing about computer graphics)
<pq>
maxzor, I don't understand what you are thinking about. It does sound a little bit X11 DRI1'ish with the shared rectangle lists? That approach was abandones a long long time ago.
<maxzor>
for example if you draw animations over a fixed background, I imagine putting the background in framebuffer1, the animation in framebuffer2 and telling the GPU sum me these two planes into one. Still makes sense for 2D
<maxzor>
I don't know a thing about DRI
<pq>
maxzor, you can already *kind of* do that in Wayland by using two wl_surfaces, one as the sub-surface for the other. The problem is, how the blending together is done is not defined by Wayland.
<pq>
So when you need a specific blending result, it is better to do that in your application.
<pq>
That means rendering just one image for one wl_surface per frame.
<pq>
You can totally keep a copy fo your background and copy it into the new image before you draw your animation on top each frame. If you use a GPU, that copy is insignificant.
maxzor has quit [Remote host closed the connection]