ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
guru_ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
Brainium_ has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
caveman has quit [Remote host closed the connection]
glennk has joined #wayland
Hypfer has quit [Quit: Ping timeout (120 seconds)]
Hypfer has joined #wayland
<vyivel>
confused by text-input-unstable-v3 wording
crazybyte has quit [Read error: Connection reset by peer]
crazybyte has joined #wayland
<vyivel>
"After […] disable request all state information is invalidated", but zwp_text_input_v3.disable is marked as double-buffered… is there a reason for it to be?
<vyivel>
also, zwp_text_input-v3.enable desc states that it "resets all state", which i don't think mutter does, for example
sima has joined #wayland
mxz_ has joined #wayland
Hypfer is now known as Guest9217
Hypfer has joined #wayland
Guest9217 has quit [Ping timeout: 480 seconds]
melonai has quit []
melonai has joined #wayland
melonai has quit []
privacy has joined #wayland
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
leon-anavi has joined #wayland
mvlad has joined #wayland
VeTun has joined #wayland
<VeTun>
Hi there, is this the right channel to ask questions concerning wayland or is this a pure developer channel?
tzimmermann has joined #wayland
VeTun has quit [Remote host closed the connection]
VeTun has joined #wayland
manuel1985 has joined #wayland
<vyivel>
VeTun: the former
<VeTun>
@vyivel thanks for the reply, ill just shoot then :)
<VeTun>
Im using KDE 6 with wayland. Garuda Linux / Arch based. My setup got an nvidia gpu 555 beta drivers. Also an intel-igpu. 2 physical screens connected to the intel i-gpu and the gaming screen is connected to the nvidia gpu. All three dispalys work. But apparently the nvidia card does all the work. Lets say i put a video on one of the displays connected to the intel i-gpu. I would expect the intel i-gpu to do the
<VeTun>
video decoding / hardware acceleration. But in fact the nvidia card does. Any clues about this behavior?
<vyivel>
this is a question for a kde channel
<vyivel>
wayland itself, being a protocol, is not responsible for this
<VeTun>
So its about kwayland compositor?
<vyivel>
kwin, yes
<VeTun>
Thank you, a lot - now i know where to seek help next :)
<nickdiego[m]>
Should fractional_scale_v1.preferred_scale getting applied (new re-scaled frame) right away when it's received cause any problem? I've been experiencing some distorted/blurriness when testing it on Chromium, which seems consistent in Mutter and KWin, so I wonder if there's some "timing" requirement not mentioned in the spec
<zamundaaa[m]>
There's no timing requirement, but the app has to actually use the preferred_scale, which afaik Chromium still doesn't do. It tries to guess a scale from the wl_output, which doesn't work
nazarewk[m] has quit [Quit: Client limit exceeded: 20000]
<nickdiego[m]>
zamundaaa: Hi, yeah, I mean, I'm implementing it and running into that issue while testing my wip impl. I've put more details here https://gitlab.gnome.org/GNOME/mutter/-/issues/3527 and am experiencing similar distortions in KWin
<zamundaaa[m]>
Ah, good
<zamundaaa[m]>
Are you using the exact scale factor you get through Wayland? Slight changes in the value can cause client and compositor to disagree on what amount of pixels the window takes up
<zamundaaa[m]>
Also, are you using subsurfaces?
<nickdiego[m]>
Yeah, scale/120, etc. In this case there shouldn't be rounding issues, as I'm testing with 300% scale. The problem manifests when I move across displays with different scales (and is particularly noticeable when the difference is larger, eg: 1 vs 3)
<jadahl>
if its GNOME, there is the risk it's the /120 limitation being the reason, i.e. different results of buffer sizes since the protocol can't pass the scale without too much loss
<nickdiego[m]>
no subsurfaces in this case
<jadahl>
ah, 300%, then no risk
<nickdiego[m]>
Hi jadahl
<nickdiego[m]>
feels more like a race condition
<nickdiego[m]>
eg: if I postpone the new frame to be generated after 2 seconds (or 500ms) after preferred_scale is received it works as expected
<nickdiego[m]>
ie: maybe the "move window to display X" animation has already been done it shouldn't be a problem?
<zamundaaa[m]>
From the Wayland side there's no race, you can render for the new scale at any point in time, before or after the preferred_scale event was received
<nickdiego[m]>
zamundaaa: ok, thanks! that answers my first question
<nickdiego[m]>
so presumably compositor bugs.. unless I'm still missing something from Chromium side
<jadahl>
perhaps it uses the scale of one monitor, but aligns to the pixel grid of the other
<jadahl>
but it should always be aligned with 300%
<nickdiego[m]>
I did an interesting experiment: instead of applying the preferred scale right away, doing it upon wl_surface.enter and wl_surface.leave (as it is currently done in chromium's impl) and it seems to happen less often though it results in issues
<nickdiego[m]>
jadahl: who's "it" in this case? the compositor, right?
garnacho has quit [Quit: garnacho]
garnacho has joined #wayland
<jadahl>
nickdiego[m]: alignment is done by the compositor
lsd|2 has joined #wayland
Brainium has joined #wayland
<nickdiego[m]>
ok, sorry I'm not familiar with that, is it somewhat related to wp_viewport source/destination?
<nickdiego[m]>
jadahl: A different I in the logs is that when instantly applying the `preferred_scale` under mutter, `wp_viewport` requests are issued before the `wl_surface.leave` (leaving the 300% scaled output), which is not the case in the non-buggy impl ([these](https://notes.nickdiego.dev/chromium/proposal/wayland-per-window-scaling#With+%60WaylandPerSurfaceScale%60+enabled) are the logs I'm referring to)
<nickdiego[m]>
* jadahl: A difference I see in the logs is that when instantly applying the `preferred_scale` under mutter, `wp_viewport` requests are issued before the `wl_surface.leave` (leaving the 300% scaled output), which is not the case in the non-buggy impl ([these](https://notes.nickdiego.dev/chromium/proposal/wayland-per-window-scaling#With+%60WaylandPerSurfaceScale%60+enabled) are the logs I'm referring to)
<jadahl>
nickdiego[m]: its related to fractional scaling, but not relevant when using 300%, as in, it's about the fact that compositors should align the clients top/left corner with the physical pixel grid of a monitor
<nickdiego[m]>
jadahl: thanks for the explanation! So, any hint on how I could confirm if that's a compositor bug or a client issue? Or is it already confirmed? :)
lbia_ has quit [Remote host closed the connection]
lbia has joined #wayland
<jadahl>
nickdiego[m]: the alignment shouldn't cause these problems if the scales are integers, so still a bit puzzled
manuel1985 has quit [Quit: Leaving]
feaneron has joined #wayland
<jadahl>
nickdiego[m]: in the notes, something I'm wondering. you get preferred_scale 3.0, allocate a 3328 x 2304 buffer, then set viewport with dst 965 x 662. the source, however matches dst * scale. is it intentional to just show part of the buffer?
vulpes2[m] has quit []
lbia has quit [Ping timeout: 480 seconds]
dani-g5x[m] has quit [Quit: Client limit exceeded: 20000]
<nickdiego[m]>
jadahl: yeah, tbh I don't know the reason for that buffer size difference (it's done by chromium's gpu process) and as it also happens in the baseline impl (non-buggy, `WaylandPerSurfaceScale` disabled) I'm just assuming it's ok
rolf has joined #wayland
rolf has quit []
rasterman has quit [Quit: Gettin' stinky!]
lbia has joined #wayland
tzimmermann has quit [Quit: Leaving]
<colinmarc>
if I configure a xdg_toplevel as suspended in the initial configure, is it still required to submit an initial content update? will I confuse clients by doing that?
<vyivel>
colinmarc: iirc it's fine and clients should reply with ack + bufferless commit (i think?)
<vyivel>
…actually ack while unmapped makes little sense
<colinmarc>
yeah, that's my confusion
<colinmarc>
I will play around and see what happens
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
Brainium has quit [Read error: Connection reset by peer]