ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
gaweringo has quit [Quit: gaweringo]
hergertme has joined #wayland
nerdopolis has quit [Read error: Connection reset by peer]
nerdopolis has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
CME has quit [Ping timeout: 480 seconds]
karolherbst has quit [Ping timeout: 480 seconds]
whot has quit [Quit: WeeChat 2.7.1]
CME has joined #wayland
vincejv has quit [Remote host closed the connection]
vincejv has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
DPA has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
paulk-bis has joined #wayland
paulk has quit [Ping timeout: 480 seconds]
DPA has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
vincejv has quit [Remote host closed the connection]
vincejv has joined #wayland
alarumbe has quit [Ping timeout: 480 seconds]
alarumbe has joined #wayland
chiku has quit []
Sid127 has joined #wayland
Sid127 has quit [Ping timeout: 480 seconds]
Sid127 has joined #wayland
vincejv has quit [Remote host closed the connection]
leon-anavi has joined #wayland
tzimmermann has joined #wayland
vincejv has joined #wayland
Sid127 has quit [Ping timeout: 480 seconds]
Sid127 has joined #wayland
sima has joined #wayland
leonanavi has joined #wayland
leon-anavi has quit [Remote host closed the connection]
MrCooper__ is now known as MrCooper
garnacho has joined #wayland
mripard has joined #wayland
rgallaispou has joined #wayland
karolherbst has joined #wayland
<staceee>
question about viewporter: if the src and dst rectangle ratio missmatch, is the output stretched?
<staceee>
or is there some blank space at one corner? if so, is the buffer centered somehow?
<vyivel>
staceee: stretched
<davidre>
stacee strecthed in my readin
<davidre>
> If the destination size is set, it causes the surface size to become dst_width, dst_height. The source (rectangle) is scaled to exactly this size.
<staceee>
arf
flokli has quit [Quit: WeeChat 4.5.1]
flokli has joined #wayland
glennk has joined #wayland
rasterman has joined #wayland
<staceee>
but I should be able to do that with xdg_positionner right?
<staceee>
how they would interract with each-other?
<davidre>
xdg_positioner is completely orthogonal
<staceee>
ah it position xdg_surface, not wl_surface in xdg_surface, right?
<MrCooper>
specifically a child relative to its parent
<vyivel>
viewport is responsible for mapping a part of a buffer to a surface, xdg_positioner is responsible for providing rules to position a surface in the global space
bodiccea_ has quit [Remote host closed the connection]
<vyivel>
position/resize, to be precise
<staceee>
ok alternatively, can I enforce a window dimension ratio somehow?
<staceee>
to be sure it match my buffer ratios
<vyivel>
what are you trying to do
<staceee>
working on a vnc client. I'm trying to offload the scaling to the compositor, using viewporter. But I don't want to stretch the buffer
bodiccea_ has joined #wayland
peeterm has quit [Quit: Leaving]
<staceee>
so either I can position it inside the top level, or I stretch the buffer in a surface with a matching geometry
<vyivel>
put the buffer into a subsurface, put viewport-scaled buffer into it while preserving aspect ratio, then center the subsurface within the toplevel
<vyivel>
uh
<vyivel>
the first part of that sentence doesn't make sense but you get what i mean hopefully
<staceee>
mhh
* vyivel
isn't fully awake yet
<staceee>
subsurface? is that xdg-shell specific?
<vyivel>
nope, see wl_subcompositor in the core protocol
<staceee>
okay thanks!
peeterm has joined #wayland
<pq>
staceee, FYI, a Wayland client always sets the size of its wl_surfaces. A compositor either uses that, or disconnects the client with a protocol error when the protocol spec mandates so. Size mismatch between compositor and client points of view on a wl_surface simply cannot exist.
<staceee>
meant ratio missmatch
<pq>
there cannot be a ratio mismatch
<pq>
staceee, xdg_surface is an additional interface on a wl_surface. It's not "another" surface as if it had geometry or anything, so there is no concept of positioning a wl_surface in xdg_surface.
<staceee>
viewporter would stretch on ratio missmatch
<pq>
staceee, only if you tell viewporter to do so.
<staceee>
right
<ifreund>
the client can also commit a size that does not match what the compositor sent in the configure event
<ifreund>
for example, mpv does this to maintain the aspect ratio of its window if it is not tiled
<ifreund>
(which does make things quite tricky for the compositor to handle correctly in some cases)
<pq>
The sub-surface suggestion is a good one. You can keep your window decorations etc. UI separate from the remote screen contents and off-load the scaling to the compositor. It does raise a question, though:
<pq>
What is the benefit of off-loading a VNC screen image scaling to the compositor?
bodiccea_ has quit [Remote host closed the connection]
<MrCooper>
e.g. it allows the compositor to scan out the client buffer directly in some cases?
<pq>
It's from VNC, does it live in a dmabuf?
<pq>
Is there GPU-accelerated VNC image decoding?
bodiccea has joined #wayland
feaneron has joined #wayland
iomari891 has joined #wayland
<MrCooper>
admittedly I don't know if there's any VNC client with GPU acceleration, it seems plausible in principle at least though
<MrCooper>
even if not though, it means the compositor can scale the buffer contents with the GPU
narodnik2 has joined #wayland
kts has joined #wayland
<staceee>
wlvncc got some GPU related feature
<staceee>
what I'm primarly trying to do is to support fractionnal scaling
<staceee>
on the client side
<staceee>
and secondary benefit would be better performance I guess
<staceee>
We would skip one scaling, and positionning
<emersion>
i would be fine (degrudgingly :P ) with !113 if it didn't make everything inert
<pq>
emersion, what would you do instead?
<emersion>
same as linux-dmabuf not throwing everything on the floor if the client keeps using an old buffer with a format no longer advertised
<pq>
...wait, that's supposed to work?
<pq>
or just silently not work?
<swick[m]>
sure, why not? A global is just an object and destroying an object don't have a knock-on effect (if not explicitly defined).
<pq>
Does that mean that clients are good to continue using the image descriptions they already got, and creating new ones if they had the old global bound?
<swick[m]>
that's how I understand it at least
<pq>
What's the expected outcome of that, given the compositor may have lost its capability to use those image descriptions?
<pq>
Or should the compositor delay its loss of capability?
<swick[m]>
I don't think there is any meaning behind it, it's just how things are, if left unspecified
<pq>
What's the incentive for clients to get back to good working state?
<swick[m]>
if color management support is supposed to be something that can be removed and added by the compositor, then it's not useful behavior
<swick[m]>
I'm just trying to say that I think this behavior just naturally happens if you don't explicitly design the behavior for adding/removing a feature
<pq>
AFAIU that's exactly what mahkoh wants, when the end user tells his compositor to switch from a color-managing renderer to one that cannot.
<swick[m]>
Yes, but to me it's not even clear if that's a good goal to have
<pq>
Me neither, yet I lack solid counter-rationale.
<swick[m]>
well, the implementations for it that we could come up with are:
<swick[m]>
1. if a client doesn't handle global remove, everything will become inert and the colors look wrong, (also probably racy even if the client handles the global remove)
<swick[m]>
2. if a client doesn't handle global remove, it will receive protocol errors, but even if it handle it, clients still might because it's racy
<pq>
right
<swick[m]>
a more fundamental issue: if the compositor stops doing color management, then how does it composite surfaces with already committed image description state?
<pq>
badly
<pq>
That's a good question to raise.
<pq>
I'm running out of time today, let's see tomorrow.
<swick[m]>
o/
surrogatefour has joined #wayland
surrogatefour has quit [Remote host closed the connection]
<ifreund>
I'd personally prefer a "manager_manager" object with a destroy event over using global_remove
<pq>
We could easily add a "please, stop using this" event in the global interface. Though, clients might not hang on to it to get the event.
<emersion>
ifreund: why?
<DemiMarie>
pq: I think a renderer with no color management is broken. All renderers should support it.
<pq>
DemiMarie, nah, it's a fine design decision to assume everything is in sRGB as long as everything makes the same assumption.
<LaserEyess>
maybe a dumb question, but would something like https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/180 help for this? I mean, ultimately, isn't what he wants just some way for the compositor to say "things have changed, make sure you redo your buffers with the new assumptions"?
<ifreund>
emersion: it dodges the global_remove race for one...
<emersion>
we've fixed the race
<ifreund>
oh? do we have something better than delaying the destroy on the server side by a few seconds now?
<ifreund>
Maybe that is a 100% fix in practice but it feels ugly to me
riteo has quit [Remote host closed the connection]
<emersion>
we could add something in wl_fixes if we wanted to, but shrug, it's good enough
<emersion>
we have bigger fish to fry imho
<ifreund>
fair
<ifreund>
I just can't stop wishing that global_remove didn't exist and we had wl_seat_manager and wl_output_manager objects rather than advertising multiple instances of the same global
<pq>
ifreund, what would be the difference?
<ifreund>
I think it would be simpler to use and understand for both clients and compositors
<ifreund>
having globals follow 3? different patterns of behavior isn't great
<ifreund>
(normal advertise once never destroy globals, wl_seat/wl_output "multi" globals, and the third advertise once maybe destroy and re-create kind that color management might and apparently some others are?)
agd5f has quit [Read error: No route to host]
agd5f has joined #wayland
alarumbe has quit [Ping timeout: 480 seconds]
<MrCooper>
does any compositor actually send WL_SURFACE_ERROR_DEFUNCT_ROLE_OBJECT?
<MrCooper>
git grep comes up empty in mutter, kwin & weston
rgallaispou has quit [Quit: Leaving.]
alarumbe has joined #wayland
<ifreund>
MrCooper: wlroots code appears to
<MrCooper>
good, I wonder if nautilus popups survive that :)