[kwin] [Bug 461063] New: xdg_toplevel.set_fullscreen does not center surface and doesn't add black background/padding/bars
https://bugs.kde.org/show_bug.cgi?id=461063 Bug ID: 461063 Summary: xdg_toplevel.set_fullscreen does not center surface and doesn't add black background/padding/bars Classification: Plasma Product: kwin Version: 5.26.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: robert.ma...@posteo.de Target Milestone: --- SUMMARY >From the xdg-shell spec: ``` If the surface doesn't cover the whole output, the compositor will position the surface in the center of the output and compensate with with border fill covering the rest of the output. The content of the border fill is undefined, but should be assumed to be in some way that attempts to blend into the surrounding area (e.g. solid black). If the fullscreened surface is not opaque, the compositor must make sure that other screen content not part of the same surface tree (made up of subsurfaces, popups or similarly coupled surfaces) are not visible below the fullscreened surface. ``` STEPS TO REPRODUCE 1. run `weston-simple-egl -f -r` (requires very recent weston version, not released yet) OBSERVED RESULT The client surface is not centered, content behind it is visible. EXPECTED RESULT The client surface is not centered, content behind it is covered. ADDITIONAL INFORMATION This is currently not widely used by clients, however Wine-Wayland, once merged and enabled, will rely on it. Similar bugs are or where present in Mutter and Exo. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 445346] GStreamer with waylandsink in KDE Plasma Wayland session: Video doesn't update (works in GNOME or using Weston)
https://bugs.kde.org/show_bug.cgi?id=445346 --- Comment #9 from Robert Mader --- (In reply to Nate Graham from comment #8) > There isn't going to be a 5.23.6 (non-LTS Plasma versions only get five > bugfix releases). So unless your distro's packagers backport it, we'll have > to wit until Plasma 5.24 in a week or so. Thanks for pointing that out! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 445346] GStreamer with waylandsink in KDE Plasma Wayland session: Video doesn't update (works in GNOME or using Weston)
https://bugs.kde.org/show_bug.cgi?id=445346 --- Comment #7 from Robert Mader --- Just tested on 5.23.5 and unfortunately the fix is not yet backported. Would be very glad if it made it into 5.23.6 :) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 448470] New: Gstreamer waylandsink does not update video content
https://bugs.kde.org/show_bug.cgi?id=448470 Bug ID: 448470 Summary: Gstreamer waylandsink does not update video content Product: kwin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: robert.ma...@posteo.de Target Milestone: --- SUMMARY When running the Gstreamer waylandsink example demo, the content/pattern/"test video" never gets updated and is stuck on the first frame. STEPS TO REPRODUCE ``` git clone g...@gitlab.freedesktop.org:gstreamer/gstreamer.git cd gstreamer meson build cd build ninja cd .. ./gst-env.py cd subprojects/gst-plugins-bad/tests/examples/waylandsink/ ../../../../../build/subprojects/gst-plugins-bad/tests/examples/waylandsink/waylandsink ``` OBSERVED RESULT The test video/pattern is never updated after the first frame EXPECTED RESULT See test test video/pattern animating SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.23.4 ADDITIONAL INFORMATION This works as intended on Weston and Mutter. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438972] The zwp_pointer_gestures_v1 protocol is broken with GTK
https://bugs.kde.org/show_bug.cgi?id=438972 Robert Mader changed: What|Removed |Added Summary|Support the |The zwp_pointer_gestures_v1 |zwp_pointer_gestures_v1 |protocol is broken with GTK |protocol| --- Comment #3 from Robert Mader --- Urgh, sorry, it's already supported - just something with GTK is broken, on either side. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438972] Support the zwp_pointer_gestures_v1 protocol
https://bugs.kde.org/show_bug.cgi?id=438972 --- Comment #2 from Robert Mader --- P.S. as little extra motivation: one of the main Firefox Webrender devs runs KDE and would love to debug pinch zoom on his main device :) So implementing would make some people very happy. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438972] Support the zwp_pointer_gestures_v1 protocol
https://bugs.kde.org/show_bug.cgi?id=438972 --- Comment #1 from Robert Mader --- Firefox tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1717391 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 438972] New: Support the zwp_pointer_gestures_v1 protocol
https://bugs.kde.org/show_bug.cgi?id=438972 Bug ID: 438972 Summary: Support the zwp_pointer_gestures_v1 protocol Product: kwin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: robert.ma...@posteo.de Target Milestone: --- SUMMARY GTK3/4 as well as Mutter and wlroots (oddly not Weston) implement the zwp_pointer_gestures_v1 protocol to allow pinch and zoom gestures on touchpads. It is used in apps such as Firefox, Gnome Web and evince and allows to make the touchpad experience match closer that of other OSes. It would be great to have it supported in Kwin as well. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/pointer-gestures/pointer-gestures-unstable-v1.xml -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 434631] wp_viewporter support
https://bugs.kde.org/show_bug.cgi?id=434631 Robert Mader changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Robert Mader --- Err, looks like it's already supported. Sorry, never mind. And awesome! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 434631] wp_viewporter support
https://bugs.kde.org/show_bug.cgi?id=434631 --- Comment #2 from Robert Mader --- Initial support for this landed in Firefox nightly (https://bugzilla.mozilla.org/show_bug.cgi?id=1699985) You can turn it on by setting `gfx.webrender.compositor.force-enabled` to `true` using the Wayland backend. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 422426] Implement Wayland Primary Selection Protocol bridge with XWayland
https://bugs.kde.org/show_bug.cgi?id=422426 --- Comment #24 from Robert Mader --- (In reply to Nate Graham from comment #23) > What do you mean exactly? "that" == what? The bug title is "Implement Wayland Primary Selection Protocol bridge with XWayland", which actually has little to do with "make primary selection work in the GTK Wayland backend" apart from both being about primary selection. Primary selection will still not work between QT-Wayland and e.g. Chromium or Pidgin. In order to fix that kwin will need to translate between primary selection of Wayland and X11 - that's not yet done, so the bug should get reopened. I/we just high jacked this bug and talked about the protocol not working between QT-Wayland and GTK-Wayland because it (this bug) was linked in the GTK issue :) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 422426] Implement Wayland Primary Selection Protocol bridge with XWayland
https://bugs.kde.org/show_bug.cgi?id=422426 --- Comment #22 from Robert Mader --- (In reply to Nate Graham from comment #21) > Awesome, let's mark as fixed and re-open if anyone finds it still broken. > Great work Robert and Vlad! Robert, do you know what GTK version your merge > requests will be released with? That would be 4.2.x/4.3 and 3.24.29 :) However, that's actually not what this bug is about IIUC - Xwayland still needs a helping hand from kwin. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 422426] Implement Wayland Primary Selection Protocol bridge with XWayland
https://bugs.kde.org/show_bug.cgi?id=422426 --- Comment #20 from Robert Mader --- (In reply to Nate Graham from comment #19) > Since all three of those are merged, does this mean that full primary > selection functionality with GTK apps is now achieved? If I understood Vlad correctly, then yes :) Would be good if somebody could confirm this - and also test Firefox if possible. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 422426] Implement Wayland Primary Selection Protocol bridge with XWayland
https://bugs.kde.org/show_bug.cgi?id=422426 --- Comment #17 from Robert Mader --- As for GTK 3 and 4 this should now be fixed by the following MRs: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3357 https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3374 https://invent.kde.org/plasma/kwayland-server/-/merge_requests/216 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 422426] Implement Wayland Primary Selection Protocol bridge with XWayland
https://bugs.kde.org/show_bug.cgi?id=422426 Robert Mader changed: What|Removed |Added CC||robert.ma...@posteo.de --- Comment #16 from Robert Mader --- Can anyone test https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3357 and confirm that it fixes the issue on kwin? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 434631] wp_viewporter support
https://bugs.kde.org/show_bug.cgi?id=434631 --- Comment #1 from Robert Mader --- FTR, the new FF backend can already be tested quite easily - if you want to give it a go to check if it runs well on KWin: ``` git clone https://github.com/servo/webrender.git cd webrender/example-compositor/compositor cargo run native [large|small|scroll] swap 1300 520 ``` -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 434631] New: wp_viewporter support
https://bugs.kde.org/show_bug.cgi?id=434631 Bug ID: 434631 Summary: wp_viewporter support Product: kwin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: robert.ma...@posteo.de Target Milestone: --- This is a feature request for support of the wp_viewporter protocol[1]. There is some preexisting work pending[2] which unfortunately did not yet make it mainline yet. Context: While there's many interesting use-cases for the protocol (Xwayland among them), the main reason for the request is an experimental Firefox backend I'm working on[3]. It makes use of subsurfaces and viewports in order to offload certain work like scrolling from the browser to the Wayland compositor. Similar approaches in DirectComposition and CoreAnimation have been proven to offer significant power savings and are used by Firefox (and others) for a while now. There is now a working demo client which makes use of Webrender, using that technology[4]. All compositors but Weston so far have shown deficits to run it, therefore I'm now trying to give compositor devs headsups so things are in place once the new backend is production ready :) 1: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/stable/viewporter/viewporter.xml 2: https://phabricator.kde.org/D26171 3: https://bugzilla.mozilla.org/show_bug.cgi?id=1699754 4: https://bugzilla.mozilla.org/show_bug.cgi?id=1695500 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428499] Frame callbacks not send on 'empty' commits
https://bugs.kde.org/show_bug.cgi?id=428499 --- Comment #12 from Robert Mader --- Great, thanks a lot! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428499] Frame callbacks not send on 'empty' commits
https://bugs.kde.org/show_bug.cgi?id=428499 --- Comment #6 from Robert Mader --- > does Firefox continuously creates frame callbacks (even if nothing has been > changed) or only on demand? Not completely continuous, but always if FF *may* repaint soon. > The compositor tries to avoid repainting as much as possible. Yeah, that was also a motivation in Mutter to move frame callback handling completely outside of the paint code eventually (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218). Totally agree that this is quite involving to really get right :/ FTR.: the FF patch was pushed back at least another train, so will not ride to release before 86 in February. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428499] Frame callbacks not send on 'empty' commits
https://bugs.kde.org/show_bug.cgi?id=428499 --- Comment #3 from Robert Mader --- Some more notes here: we just enabled the frame callback based vsync emulation by default on the Wayland backend in Firefox 85. The Wayland backend is not enabled by default yet and 85 will only released in the end of January, however users explicitly enabling it and running nightly or soon beta will run into this issue. Therefore I personally am quite eager to see it resolved :) The benefit of using frame callbacks are twofold: on one hand we can run at refresh rate on non-60Hz monitors, on the other we can stop rendering when the compositors stops sending callbacks, for example when the window is completely covered, reducing power consumption. So overall quite desirable. I'm do not know how kwin handles callbacks, but I'd like to point out to how mutter initially handled this: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/839/diffs?commit_id=d49d10b14f4e0fa80e6867979b26fab383610b39 While the solution is not optimal (and thus was later replaced with a more comprehensive solution mentioned above already), something similar might work for kwin as well - and in mutter it was only 4 lines. Hoping you find time and energy to look into this soon, best regards -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428499] Frame callbacks not send on 'empty' commits
https://bugs.kde.org/show_bug.cgi?id=428499 --- Comment #2 from Robert Mader --- Yeah, the correct forwarding of bugs it an area for improvement :/ Now that I have an account here I'll try to do that more regularly. For FF<->Gnome and FF<->wlroots it appears to work mostly by having some accidental overlap between devs who work on both projects. There is, however, a list of known KWin-only bugs at https://bugzilla.mozilla.org/show_bug.cgi?id=1609115 - maybe one of you finds time to go through them and check if there's still something actionable? Concerning this bug I'd like to highlight the Mutter solution (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218) which decoupled frame callback emission from drawing all together. There's a list of scenarios where things can go wrong otherwise - for example if damage only happens in a part of a surface that's off-screen (see https://gitlab.gnome.org/GNOME/mutter/-/issues/817#note_738633). Just so you have that in mind when drafting a solution. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428499] New: Frame callbacks not send on 'empty' commits
https://bugs.kde.org/show_bug.cgi?id=428499 Bug ID: 428499 Summary: Frame callbacks not send on 'empty' commits Product: kwin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: platform-drm Assignee: kwin-bugs-n...@kde.org Reporter: robert.ma...@posteo.de Target Milestone: --- SUMMARY The Firefox Wayland backend uses a rather unconventional but, according to spec and with a clear consensus of Weston, Gnome and wlroots devs, valid method to use frame callbacks: it tries to emulate vsync by constantly requesting frame callbacks in a dedicated loop for the main surface - even though it may not trigger any repaints (i.e. doesn't attach new buffers nor submits any damage). KWin currently gets stuck when this happens (as did other compositors until they got fixed :) ) STEPS TO REPRODUCE 1. start Firefox (preferably >=83) with the Wayland backend enabled (`MOZ_ENABLE_WAYLAND=1`) 2. enable `widget.wayland_vsync.enabled` (and preferably `gfx.webrender.all`) in `about:config` 3. restart the browser OBSERVED RESULT Firefox does not update its content EXPECTED RESULT Firefox should work pretty much as normal SOFTWARE/OS VERSIONS KDE Plasma Version: has been confirmed for up to 5.20 ADDITIONAL INFORMATION Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1616894 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 427528] Cursor gets stuck as a grabbing hand after grabbing something in Firefox
https://bugs.kde.org/show_bug.cgi?id=427528 Robert Mader changed: What|Removed |Added CC||robert.ma...@posteo.de --- Comment #12 from Robert Mader --- (In reply to Vlad Zahorodnii from comment #10) > However, I've noticed that dnd and copy pasting stop working in firefox > after you use it for a while. What's more interesting is that I can > reproduce the same issue with weston... For the record: this is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1622107 and a known issue, on all compositors. -- You are receiving this mail because: You are watching all bug changes.
