00:56wlb: weston Issue #918 opened by Nils K (septatrix) On-screen keyboard not working in kiosk shell https://gitlab.freedesktop.org/wayland/weston/-/issues/918
04:30wlb: weston Merge request !1539 opened by Chien Phung (chienpv) Request dump surface with DMA buffer from clients https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1539
05:32vyivel: confused by text-input-unstable-v3 wording
05:33vyivel: "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?
05:35vyivel: also, zwp_text_input-v3.enable desc states that it "resets all state", which i don't think mutter does, for example
07:20VeTun: Hi there, is this the right channel to ask questions concerning wayland or is this a pure developer channel?
07:29vyivel: VeTun: the former
07:30VeTun: @vyivel thanks for the reply, ill just shoot then :)
07:35VeTun: 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
07:35VeTun: video decoding / hardware acceleration. But in fact the nvidia card does. Any clues about this behavior?
07:38vyivel: this is a question for a kde channel
07:38vyivel: wayland itself, being a protocol, is not responsible for this
07:38VeTun: So its about kwayland compositor?
07:39vyivel: kwin, yes
07:39VeTun: Thank you, a lot - now i know where to seek help next :)
07:40VeTun: bye
08:43MrCooper: zamundaaa[m]: in the context of https://gitlab.freedesktop.org/xorg/xserver/-/issues/1677, does kwin use the Wayland surface contents for Xwayland windows, or does it maybe use the contents of an X window pixmap?
09:28wlb: weston/main: Marius Vlad * 16 commits https://gitlab.freedesktop.org/wayland/weston/compare/05e5405651054c580b248c4ab2791ed8d66369e3...984d36aaca54d6a210283d18038a4ecefefaa960
09:28wlb: weston Merge request !1533 merged \o/ (Rework placeholder rendering for weston-direct and content censoring https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1533)
09:38wlb: weston/main: Daniel Martinez * clients: fix surface viewport memory leak https://gitlab.freedesktop.org/wayland/weston/commit/2bce7269922d clients/window.c
09:38wlb: weston Merge request !1537 merged \o/ (Fix Surface Viewport Memory Leak https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1537)
10:07zamundaaa[m]: MrCooper: it uses the Wayland surface contents
10:07MrCooper: thanks for confirming
10:34wlb: weston/main: Marius Vlad * gitlab-ci.yml: Avoid running CI for merge pipelines https://gitlab.freedesktop.org/wayland/weston/commit/bc5524422332 .gitlab-ci.yml
10:34wlb: weston Merge request !1536 merged \o/ (gitlab-ci.yml: Remove possible duplicate pipelines https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1536)
12:38nickdiego[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
12:44zamundaaa[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
12:46nickdiego[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
12:47zamundaaa[m]: Ah, good
12:48zamundaaa[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
12:49zamundaaa[m]: Also, are you using subsurfaces?
12:52nickdiego[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)
12:52jadahl: 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
12:52nickdiego[m]: no subsurfaces in this case
12:52jadahl: ah, 300%, then no risk
12:52nickdiego[m]: Hi jadahl
12:53nickdiego[m]: feels more like a race condition
12:54nickdiego[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
12:54nickdiego[m]: ie: maybe the "move window to display X" animation has already been done it shouldn't be a problem?
12:55zamundaaa[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
12:56nickdiego[m]: zamundaaa: ok, thanks! that answers my first question
12:56nickdiego[m]: so presumably compositor bugs.. unless I'm still missing something from Chromium side
12:58nickdiego[m]: I collected some WAYLAND_DEBUG logs [here](https://notes.nickdiego.dev/chromium/proposal/wayland-per-window-scaling#Debugging%20a%20Mutter%20issue) for both the buggy and baseline impl, though protocol-wise they don't seem to point out to any issue
12:59jadahl: nickdiego[m]: is blurry on both monitors or just one of them?
13:01nickdiego[m]: jadahl: both, though more noticeable when moving from the 4K (scale 3) to the FHD one (scale 1)
13:02nickdiego[m]: this [screen recording](https://drive.google.com/file/d/15SgSFUdw0vuYnW8H81FkPvRpk-txx2I_/view?usp=sharing) is for the scale=1 display, hopefully the distortion can be seen (?)
13:04jadahl: perhaps it uses the scale of one monitor, but aligns to the pixel grid of the other
13:04jadahl: but it should always be aligned with 300%
13:04nickdiego[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
13:05nickdiego[m]: jadahl: who's "it" in this case? the compositor, right?
13:11jadahl: nickdiego[m]: alignment is done by the compositor
13:16nickdiego[m]: ok, sorry I'm not familiar with that, is it somewhat related to wp_viewport source/destination?
13:21nickdiego[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)
13:21nickdiego[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)
13:23jadahl: 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
13:23wlb: weston/main: Pekka Paalanen * 10 commits https://gitlab.freedesktop.org/wayland/weston/compare/bc5524422332ed41728b0946f0c709358d2ffff8...5e84f9167c45f4fa9e17da96e512a934c650bbc8
13:23wlb: weston Merge request !1499 merged \o/ (clients/image: use CM&HDR protocol extension to present image with embedded ICC https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1499)
13:38nickdiego[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? :)
13:59wlb: weston Merge request !1540 opened by Marius Vlad (mvlad) gitlab-ci.yml: Remove dependency on docs-build to publish docs https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1540 [CI]
14:57jadahl: nickdiego[m]: the alignment shouldn't cause these problems if the scales are integers, so still a bit puzzled
15:03jadahl: 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?
15:49nickdiego[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
16:38colinmarc: 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?
16:49vyivel: colinmarc: iirc it's fine and clients should reply with ack + bufferless commit (i think?)
16:50vyivel: …actually ack while unmapped makes little sense
16:50colinmarc: yeah, that's my confusion
16:50colinmarc: I will play around and see what happens
17:26wlb: weston Merge request !1541 opened by Marius Vlad (mvlad) frontend: Use simple_heads_changes for head enablement https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1541 [RDP backend]
19:03wlb: weston Merge request !1542 opened by Derek Foreman (derekf) compositor: Check buffer validity before attaching to renderer https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1542 [Core compositor]