07:22colinmarc: Explicit sync on nvidia is coming soon, I read somewhere. Does anyone know if the implicit-explicit-interop-via-ioctls-thing is supposed to be working already? And in particular on Vulkan? I've been trying for weeks to get it working on a 3080 in my compositor and I just get all-black dmabufs (but only above a certain size). I posted on the nvidia developer forums but the response has been bagel.
07:30MrCooper: colinmarc: the nvidia driver doesn't handle implicit sync at all, including those ioctls
07:34colinmarc: Ok, thank you for confirming that.
07:34colinmarc: I was just now reflecting on whether my issue is actually a sync issue (I don't have any flickering or anything, just... nothing) or whether that's a red herring and it's some other WSI incompatibility.
07:44MrCooper: if it was a synchronization issue, the expected contents should show up eventually (and before that I'd expect to see garbage instead of all black)
07:46cwegener: Could be this one? https://invent.kde.org/plasma/kwin/-/merge_requests/4770
07:47cwegener: I did some testing with Julian the other day related to that .. https://github.com/mahkoh/jay/issues/159
07:50colinmarc: I don't think so. I'm just doing the import to a VkImage and the VkImage is all black.
07:51colinmarc: But it's super weird, 800x640 works every time, but 800x642 and it's all black, every time. That's true for lots of different resolutions, but there's no pattern to the stride/size I can figure out.
07:54cwegener: Ah. Ok. Yeah. Sounds different.
09:22cwegener: colinmarc: I think I can also reproduce your issue in jay.
09:24cwegener: Turns out that the initial issue I was testing and that Julian worked around by following Xaver's approach of not sending the fence fd when the driver is NVidia is specific to OpenGL as the backend.
09:25cwegener: i.e. I believe that the workaround of not sending the fence fd only works for OpenGL
09:25cwegener: I just tested now with the Vulkan backend in jay ... and the screen is all black
09:47colinmarc: cwegener: huh that’s reassuring to hear at least! which card are you testing on? I had a friend unable to reproduce on a p1000
09:50colinmarc: I wonder if this combination (vulkan + new card + nvidia) is actually just not very commonly tested and the bug reports are getting lost in the sea of sync issues
09:53colinmarc: can you also try with very low resolutions?
11:48wlb: wayland Merge request !383 opened by Simon Ser (emersion) client: fix invalid doc command for WL_MARSHAL_FLAG_DESTROY https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/383 [Documentation]
12:00wlb: wayland Issue #456 opened by Simon Ser (emersion) doc: https://gitlab.freedesktop.org/wayland/wayland/-/issues/456 [Documentation]
12:00emersion: ops
12:00emersion: (fixed)
12:24wlb: weston Merge request !1505 opened by Pekka Paalanen (pq) Program KMS "Colorspace" property from config file https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1505 [Colour management], [Core compositor], [DRM/KMS backend], [Weston frontend]
12:25davidre: emersion: is the wl_signal thing locally or also for the website?
12:25davidre: for me locally wl_signal_add is correctly linked
12:26emersion: both
12:26emersion: https://wayland.freedesktop.org/docs/html/apc.html#Server-structwl__listener
12:26emersion: "register them as listeners to signals using #wl_signal_add, assuming"
12:32davidre: I wonder if the doxygen version matters if it works for me?
12:33emersion: have 1.10
12:33emersion: i have*
12:33emersion: ie latest
12:38davidre: I dont know how the website is build but debian on CI has 1.9.4
12:38davidre: I have 1.9.1
12:39wlb: wayland Merge request !384 opened by Juan Pablo Ugarte (juanpablougarte) server: add wl_event_loop_has_idle_pending() https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/384
12:44davidre: the website pipeline has 1.9.8
12:45emersion: are you sure you're not looking at the wl_signal doc comment, instead of wl_listener?
12:57davidre:uploaded an image: (76KiB) < https://matrix.org/_matrix/media/v3/download/kde.org/59504ca66b617268ef37c522a7b2a7b7232fdd8c1780581332972208128/Screenshot_2024-04-17_02%3A57%3A19.png >
12:58xjuan: good morning
12:58xjuan: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/384
12:58xjuan: do I need to also open an issue or a MR is enough?
12:59emersion: no need for an issue
13:00xjuan: great, its a simple mr
13:00xjuan: not sure about the naming of the new function
13:00wlb: weston Issue #887 closed \o/ (Black screen when take screenshot with writeback connector https://gitlab.freedesktop.org/wayland/weston/-/issues/887)
13:02xjuan: I tried to explain why its needed in the comments
13:02xjuan: but of course my use case is unusual
13:03emersion: i think it's a usual thing to do, to integrate tthe libwayland event loop inside some other event loop library :)
13:03xjuan: right but this is on the server side not the client
13:03xjuan: on the client maybe there is no need for idle sources
13:03xjuan: at least not wayland idle sources
13:03emersion: the client side doesn't use the event loop at all
13:04emersion: it's just one FD, after all
13:52wlb: wayland Merge request !384 closed (event-loop: add wl_event_loop_has_idle_pending())
14:28wlb: wayland-protocols Merge request !299 opened by Jonas Ådahl (jadahl) build: Bump version to 1.35 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/299
14:51wlb: wayland-protocols/main: Jonas Ådahl * build: Bump version to 1.35 https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/08d1c7276d41 meson.build
14:51wlb: wayland-protocols Merge request !299 merged \o/ (build: Bump version to 1.35 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/299)
14:52wlb: wayland-protocols New tag: 1.35 https://gitlab.freedesktop.org/wayland/wayland-protocols/tags/1.35
15:04wlb: wayland.freedesktop.org Merge request !77 opened by Jonas Ådahl (jadahl) releases: Add wayland-protocols 1.35 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/77
15:05wlb: wayland.freedesktop.org/main: Jonas Ådahl * releases: Add wayland-protocols 1.35 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/25c4f515d86e releases.html
15:05wlb: wayland.freedesktop.org Merge request !77 merged \o/ (releases: Add wayland-protocols 1.35 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/77)
16:42wlb: wayland-protocols Merge request !300 opened by Xaver Hugl (Zamundaaa) staging/tearing-control: clarify what happens after wl_surface destruction https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/300
16:47wlb: wayland-protocols Issue #192 opened by Simon Ser (emersion) Decide on best practices for addon object destrucion https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/192
16:49wlb: wayland-protocols Merge request !301 opened by Derek Foreman (derekf) Fix double-buffered state definitions by referring to wl_surface.commit instead https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/301
16:50Company: swick[m], zamundaaa[m], pq: as a followup from yesterday, what we've decided to do in GTK 4.16:
16:51Company: * We've special-cased the GTK background drawing now, so we can do whatever we decide on later, apps just set a ::black-background property
16:52Company: * I've decided that offloading will require black-pixel support because I don't want to deal with the extra feature dimension when delaing with things, so Kwin 6.0 will have to live without GTK graphics offloading
16:53Company: and everything else is still private to GTK, so we can change stuff as-needed
18:14mclasen: Company: my current thinking is to do another 4.14 release next weekend, and then flip to vulkan in main and do a 4.15 snapshot
18:22Company: mclasen: wrong channel? But sounds good to me
18:22mclasen: arf
18:23mclasen: since I'm already posting to the wrong channel, might as well advertise our post about single-pixel buffers here: https://blog.gtk.org/2024/04/17/graphics-offload-revisited/
20:14mjt: Hi! I've a laptop with small (12" wide) FullHD monitor, - that's about 160ppi (1920/12). I used cinnamon before, and everything worked fine there, - both the built-in monitor and external monitor with smaller ppi had comfort font sizes. Decided to give gnome on wayland a try, and immediately faced an issue with font sizes
20:14mjt: does wayland has a notion of ppi?
20:15mjt: I don't see how to find which ppi it detects/uses. At least xdpyinfo shows 96 which is obviously wrong
20:18colinmarc: Hi @mjt, wayland supports whole and fractional UI scaling (the latter only on some compositors). I'm not sure how to configure it in gnome, but there should be an option somewhere. Note that you'll have trouble with old apps that still use X11 via Xwayland (a translation layer).
20:20mjt: gnome has a way to change scaling factor. But it applies to *both* monitors
20:20mjt: so it is either one normal one huge, or one tiny one normal
20:21mjt: (I also often use my desktop monitor with smaller ppi value)
20:22colinmarc: I'd take that up with the gnome folks, as this is really a channel for discussing the protocol itself.
20:22mjt: I see
20:22mjt: thank you for the info anyway, the key for the start is to find out where the problem is
22:15cwegener: colinmarc: I'm testing mainly with an AD107M (RTX 4060 Mobile) in a PRIME system (Zephyrus G14 2023)
22:15cwegener: I already tried at a "low" resolution of 1920x1080 ... I'll see if I can find something lower than that.
22:24emersion: ty jadahl :)