00:48marler8997: Hey I'm looking at screen capture on wayland-based systems. I see the "grim" tool uses wlr-screencopy-unstable-v1, but none of my distros support it. My understanding is that is a "wayland interface"? How would I go about seeing all the currently supported "interfaces" on my wayland compositors?
01:02ManMower: marler8997: run "wayland-info"
01:04marler8997: Thx ManMower, just built it and seems to have worked!
01:04Arnavion: Also a compositor can support screen capture through the xdp+pipewire interface without exposing it as a wayland interface
01:05marler8997: Yeah I've got the Xdp+Pipewire solution working, but it's buggy on some distros so I'm exploring alternatives as well.
01:05marler8997: On one of my distros, I open a "screencast session", select the screen using Xdp's UI but then it sends over a feed of the webcam!?!
06:47ukiran: pq, where can i get the updated wayland-protocol implementation for color management ?
06:47ukiran: Is it is present in https://gitlab.freedesktop.org/swick/wayland-protocols/-/tree/color
06:49ukiran: looks like https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
09:51pq: heeen, no.
09:54pq: ukiran, there are no implementations in wayland-protocols or libwayland. All the implementations will be in compositors and application toolkits.
09:57ukiran: yeah..but related to the protocol extensions, the support will be added in the protocol only right
10:01pq: ukiran, sorry?
10:02pq: I will be working on at least a Weston implementation once I'm happy with the protocol specification.
10:03ukiran: do you have any idea when this color-management protocol design gets freeze ?
10:04pq: I'm quite confident it will be this year.
10:06JEEB: this is probably since I come from a CICP background, and just looking at how windows/macOS did it (former letting you either do BT.2020+PQ or linear fp16 scRGB to the compositor for HDR, latter first enabling the former but then preferring the latter), it always felt funky for me that people wanted to have the stretch goal of ICC profiles from day 1 :)
10:08pq: JEEB, HDR cannot work without understanding color management, so understanding color management *first* seemed like the obvious way to start.
10:08pq: applies to WCG too, which is practically a part of HDR
10:09pq: in the end, that "stretch goal" is actually a very simple addition compared to WCG or HDR support.
10:10JEEB: it is a freeform definition of a subset of transfers yes, and for gamut (primaries) I think either same or wider set
10:10JEEB: (since IIRC you can't really define PQ or so in current-gen ICC profiles)
10:11ukiran: pq, nice. i had gone through the link which u referred related to blending policy in weston. that is informative..
10:12pq: ICC is much more than that, but for display purposes we only need to look at a small subset of it, which is still more than just a TF and primaries. An ICC profile is an arbitrary description of how device color space maps to to the profile connection space (a common space so you can combine different profiles).
10:13pq: and yes, ICCv4 does not seem suitable for describing HDR per se, not without the CICP amendment at least.
10:13pq: it is good for WCG, though
10:13JEEB: yup
10:14ukiran: thanks for that. adding a small example explanation gives more understanding by considering default blending space and output space.
10:14pq: bnasically the ICC profile approach is limited to what it can say about the profile connection space, I believe
10:15pq: I'm not what exactly it is missing, but I've seen enough to not attempt to describe any HDR as a valid ICC profile file.
10:15pq: *I'm not sure
10:16pq: ukiran, cool :-)
10:18pq: ukiran, in my mind, it is very easy to get lost in the details if one attempts to describe that by using concrete examples like "BT.2020 PQ" here and "BT.709" there.
10:19pq: concrete examples are good, but only after you have the principles
10:22ukiran: principles of understanding of the colorspaces ?
10:23pq: I mean compositor color pipelines
10:26ukiran: Okay.. https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/winsys_color_pipeline.rst this will talk about the weston color pipeline
10:27ukiran: Is libdisplay-info library is going to used by weston later for edid parsing ?
10:27ukiran: edid *decoding*
10:27pq: Weston will use libdisplay-info.
10:29pq: ukiran, Weston is a Wayland compositor, and you can find a "Wayland compositor" in the winsys color pipeline doc.
10:29pq: *a* compositor, not the only one
10:29ukiran: Yes.. am aware of that.
10:32ukiran: am making the setup of swick's wayland protocol (color) changes. Is there any compatible weston repo (pq) inorder to avoid the build issues ?
10:33pq: ukiran, what do you mean? What are you doing?
10:34pq: There is no implementation of the current protocol spec anywhere yet that I know of.
10:35ukiran: you mean to say, there is no blending policy implementation done in your local repos ?
10:35ukiran: using GL shaders
10:36pq: well, there is no protocol implementation to feed into that policy, either
10:37pq: Currently Weston assumes that all application content is always sRGB SDR. You can set an output profile from an ICC file, and Weston will do *something* to map colors somehow.
10:38pq: While Weston can put a monitor into HDR mode, the color management code does not handle HDR in any way yet, so the result is garbage.
10:39pq: I have no private Weston branches for this, all the work I did so far has landed in Weston upstream.
10:40pq: Vitaly might have some experiments with HDR, but not a protocol implementation.
10:41ukiran: okay.
10:44pq: The GL shaders are already in Weston upstream and could roughly handle HDR as well, if something was generating the right parameters for them.
10:45pq: the shaders just apply arbitrary operations to numbers, they don't know or care what they mean
10:50ukiran: here is the older commit where the client can tell its colorspace information to the compositor through protocol.
10:50ukiran: https://gitlab.freedesktop.org/swick/wayland-protocols/-/commit/3c2cbdb8ff283f7b495adae83d2ac2a4a50dc3ef
12:43ii8: Hello, could someone give me a tip on what's the correct thing to do if wl_cursor_theme_load doesn't find a cursor theme?
12:44ii8: I'm using it like this `wl_cursor_theme_load(getenv("XCURSOR_THEME")...)`, not sure if that's always right
12:54pq: maybe the theme of that name is simply not existing? Or not in the search paths.
12:57pq: Looks like it won't automatically fall back to "default" theme if the named theme is not found.
12:57ii8: Hm, yes, I understand that sometimes things are not properly configured. But I would still want the application to find a theme somehow, even if the user has not configured it right.
12:57pq: oh, it does fall back
12:57ii8: So even if I do `wl_cursor_theme_load(NULL...)` sometimes it doesn't return a theme
13:00pq: from what I can see, wl_cursor_theme_load() would only return NULL on out-of-memory, or if it cannot create and mmap a file in $XDG_RUNTIME_DIR.
13:00ii8: Or rather, the theme has no cursors
13:00ii8: sorry
13:01ii8: So it returns a theme, but if I try to load even just the "default" cursor from it, it doesn't have it.
13:01pq: if a theme has zero cursors, literally, it falls back, eventually ending up with a built-in theme.
13:01pq: ah, yes
13:02pq: different themes may have differently named cursors
13:03pq: this is one example: https://gitlab.freedesktop.org/wayland/weston/-/blob/main/clients/window.c#L999-1119
13:05emersion: related https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/94
13:05ii8: Oh ok, thank you. I though the "default" cursor would be always available, that was my misunderstanding.
13:05emersion: the default theme doesn't follow that spec
13:05emersion: err
13:06emersion: the fallback theme i mean
13:06ii8: Yes that spec is where I got the names from, but "left_ptr" isn't there which is what the fallback theme seems to use.
13:07emersion: yeah :/
13:07pq: I'm guessing the fallback theme comes from libxcursor which predates the cursor spec by some decades maybe.
13:08emersion: the cursor spec isn't even a spec, it's a draft wiki page
13:09pq: cursor-data.h has copyright 1999 :-)
13:10ii8: heh
13:10ii8: Perhaps libwayland-cursor should come with a new theme.
13:10pq: or add more wellknown name aliases
13:11emersion: this MR does it but for wlroots https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3651
13:30heeen: does any compositor apart from weston implement dmabuf feedback for scanout planes? does wlroots implement it?
13:32emersion: only for fullscreen
13:32emersion: it's being worked on for other planes
13:39emersion: SardemFF7: webhook still broken
13:39emersion: got 200 but doesn't show up on IRC
13:39emersion: ii8: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/291
13:43SardemFF7: ok, that one is weird, it was restarted correctly
13:43SardemFF7: but I seed some NULL assertion failing
13:44SardemFF7: emersion: could you nopaste me the hook payload so that I can test locally?
13:44emersion: yes
13:45emersion: would also be nice to expand issue/MR refs
13:45emersion: like #42 and !42
13:45emersion: we did that in #sway-devel and it's pretty helpful
13:45emersion: although i guess here this channel is used for unrelated weston stuff sadly
13:46SardemFF7: what do you mean expand?
13:47emersion: i mean this https://l.sr.ht/pGVt.png
13:47SardemFF7: ah, I see, “sadly” it’s not that kind of bot
13:47jadahl: heeen: mutter and kwin too implements it afaics
13:48emersion: ^ but just fullscreen
13:48jadahl: yea, for overlay planes there is only a wip mr
13:50emersion: SardemFF7: https://paste.sr.ht/~emersion/4cf1dca11266d25f5bd742b108f08100cd305b7e
13:50SardemFF7: [expanding !refs and #refs] it could be done though, had some ideas about the implementation in my code base
13:50SardemFF7: thanks
13:50heeen: I have a customer with a imx6/etnaviv product and I realized that compositing a barely screen sized app through the qml qtwayland compositor I implemented drops to 30fps
13:51heeen: fullscreen is not good enough for this usecase because some ui elements are supposed to be visible at the same time.
13:52daniels: QML tries desperately to do quite a few copies
13:53heeen: for an older customer we implemented some special logic that made the compositor draw a punch through that made the fbdev? plane beneath visible and then used the API of their hw blitter IIRC to show video feeds from hardware decoded frames
13:53daniels: jesus
13:53emersion: …
13:54heeen: daniels, without debugging from the top of my head I could imagine at least a wayland buffer -> texture transition, blitting that in the scene graph using a shader, then that all being rasterized to the eglfs plane
13:55heeen: in a later iteration they actually wrapped the hw blitter api in wayland I think. it helped with the lag that was caused by scrolling a video in chromium
13:56heeen: but using opengl to composit video frames was a non-starter for obvious reasons
13:56daniels: heeen: yeah, I think there's a blit for each buffer as it comes in (so it doesn't need to worry about wl_buffer lifetime and everything is just in an FBO), then maybe another blit to another FBO if it requires any transformation or combination, then everything gets composited to an FBO, then there's a copy from that one to the actual gbm_bo you want to display through KMS
13:57daniels: I mean it may have improved since then, but tbh I'm not sure how you'd ever make QML/QtCompositor performant
13:57heeen: well maybe not obvious, but it was an embedded platform with dedicated video processing, video motion interpolation and what have you
13:57heeen: daniels and I actually met at that customer way back :)
13:58heeen: hm that is two more blits than I would have imagined
13:59daniels: oh you were talking about that one - it wasn't even fbdev beneath, it was something even more weird where the hardware flipped to a different fixed buffer address every refresh cycle in a round-robin, and the multimedia pipeline 'guaranteed' frames always arrived in the right place at the right time, and the CPU side had no visibility into this
13:59heeen: does this apply to any opengl compositor or is it a peculiarity of qml
14:00heeen: at some point they managed to display two video streams simultaneously by having the video hw write to disjunct areas of the hw plane I think and then grabbing from there? not sure
14:02heeen: anyways, this project I'm working on now is actually open source https://github.com/basysKom/embedded-compositor
14:03heeen: development branch is more recent https://github.com/basysKom/embedded-compositor/tree/development
14:04daniels: oh no, that's specifically how QML is implemented, and also partly how it's designed
14:04daniels: more sensible compositors like weston either zerocopy things if possible, or one at most
14:08pq: or two copies, if the source is a wl_shm buffer, because of glTexImage2D
14:09heeen: how deep have you looked into this, do you feel like theres room for improvement or would it require changing too much of qtquick
14:11daniels: heeen: I stared at it for a while, concluded it would be extremely difficult to fix but maybe possible, talked to a friend who worked on Qt who suggested that it would be hugely invasive and not accepted upstream so would have to live in a Qt/QML fork
14:11heeen: hm sounds pretty conclusive then
14:14pq: The period of intensive Weston MR breaking has begun. The first chunk of https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/805 landed.
15:23marler8997: how does the xdg-desktop-portal screencast interface capture the screen on wayland-based distros? My guess is it would have to get it from the wayland server somehow but if it did then wouldn't there be an interface for this? Or maybe it has a side-channel to it?
15:24pq: a D-bus interface, yes, I believe - not a Wayland interface
15:25emersion: depends on the impl
15:25emersion: wlroots uses a wayland protocol for this
15:25marler8997: ah, emersion from grim
15:26emersion: the D-Bus → Wayland adapter is xdg-desktop-portal-wlr
15:26emersion: on wlroots, xdg-desktop-portal is a second-class citizen
15:27marler8997: so to be clear, on wayland impl's that don't support the new "screencopy" wayland interface, the wayland impl was providing a D-Bus service, that Xdp would communicate with to get the screenshot. My question then is, why go through Xdp at all instead of going directly to the wayland impl?
15:29emersion: the wayland protocol only works on compositors that implement it, and e.g. mutter doesn't want to implement it
15:30marler8997: So you're saying that Xdp aims to be a more distro-agnostic abstraction, so it can support connecting to the wayland impl through D-Bus or "Wayland" depending on the distro?
15:30emersion: s/distro/compositor/, but yeah, that's the idea
15:31marler8997: Ok that makes sense, do you know which component provides the "selection UI" for the screencast session, is that the Wayland impl or Xdp?
15:32emersion: it's the xdg-desktop-portal impl
15:32emersion: on wlroots it
15:32emersion: 's xdg-desktop-portal-wlr
15:32emersion: there is also xdg-desktop-portal-gnome for instance
15:33emersion: i don't remember off-hand whether the D-Bus screenshot/cast impl is in xdg-desktop-portal-gnome, or in mutter directly
15:34marler8997: Ok good to know. In this case I'll be experimenting add a backend for Wayland's direct D-Bus interface and see if it allows me to support more distros (I'm running into buggy behavior in Xdp)
15:35pq: What Wayland's D-Bus interface?
15:37marler8997: I had that question and am currently trying to find it in "screen-cast.c", I see "impl_connection" which looks promising
15:38kennylevinsen: the underlying implementation differs between compositors
15:39davidre: marler8997: Every compositor has its own dbus or wayland api for screencast. xdg-desktop-portal bridges that by providing an api for aplication and talks to xdg-desktop-portal-gnome, xdg-desktop-portal-wlr, xdg-desktop-portal-kde,... which talk the compositor specfici api
15:40kennylevinsen: Not every compositor, but there are a few approaches
15:41marler8997: davidre ok that confirms what emersion was saying, I'm looking for the various dbus/wayland APIs I can talk to directly so that I can also support those backends if/when there are issues with Xdp
15:41emersion: for wlroots it'd be https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/blob/master/unstable/wlr-screencopy-unstable-v1.xml
15:41davidre: I would trust emersion :D
15:42marler8997: noted
15:42davidre: But it sounds you're making yourself do more work by wanting to implement all the things
15:42davidre: then necessary
15:43marler8997: I've already implemented the Xdp interface and it's doing some strange things on some platforms. For example, sending the "webcam" instead of the selected screen
15:44marler8997: I figure Xdp is probably has to get the screen from Wayland, so maybe there's an interface (sounds like multiple) I can support in addition when people run into these issues
15:46marler8997: Back when I worked for HP, I wrote a screen sharing for development that used Drm to capture the screen by reading directly from the framebuffer:) It worked on our specific hardware, I also found some platforms had some "funky" ways of formatting the pixel data though :)
15:47jadahl: marler8997: there are multiple backends, and the backends are responsible for both showing sandbox portal interfaces and provide the actual shared content (screenshot/screencast/...). xdg-desktop-portal (and screen-cast.c which might have been what you found) is somewhat of a fancy "proxy" to the backends
15:48jadahl: if there are issues specific to your hardware, first figure out the portal backend, then report a bug to that portal backend
15:49marler8997: yeah I'll try to look into a way to reproduce/identify/fix this bug, I'm exploring both options right now
15:50jadahl: you're likely using either xdg-desktop-portal-gnome, xdg-desktop-portal-kde or xdg-desktop-portal-wlr, or xdg-desktop-portal-gtk instead of gnome if you are on an older distro
15:50marler8997: all of the above, this is an application for hundreds of distros
15:59marler8997: we've also thought about making our app available on Windows via WSL, WSLg is pretty interesting, they run a shared "system-wide" distro that runs Weston and XWayland. Xdp doesn't seems to work though, not sure if Xdp would need to be running inside the shared distro, meaning Microsoft would need to add support, or if Xdp/Weston could work with whatever WSLg exposes to the user distro (i.e. probably just the wayland socket)
15:59daniels: *XDG
16:00daniels: you would need to have an XDG portal running inside the shared distro, but it is certainly doable
16:00marler8997: daniels it sounds like it depends which backend Xdp is using, could be using just the wayland socket for example in which case it could work outside it
16:00emersion: weston doesn't support xdg-desktop-portal
16:01daniels: emersion: given WSLg does seamless desktop, you'd want to forward the request to the host anyway so you could choose any window
16:02marler8997: good to know, weston was what we used at HP and that's where I implemented the DRM-based capturer
16:02emersion: hm, maybe… sounds "fun"
16:03emersion: a DRM-based capture has several downsides: (1) requires root (2) racy (3) no proper format negotiation
16:03daniels: yeah, I'd definitely not recommend that
16:03daniels: weston does have sideband remoting support that's being improved atm, and it'd be easy to plug an XDG portal implementation on top of that
16:04emersion: i wouldn't call an xdg-desktop-portal impl "easy"…
16:04emersion: the -wlr one required a lot of work
16:05marler8997: yeah definitely agree with the downsides. Because it requires root would be a separate process but yeah, would be a pain...but, might be the only option for some distros/people
16:06marler8997: emersion I'm impressed you came up with all the downsides so quickly, you know your stuff in this area :)
16:06emersion: not the first time someone asks about this :P
16:08marler8997: Yeah this whole capture situation on Wayland reminds me of that xkcd situation, it sounds like Xdg tried to fix this, but, in reality if you want to support as many distros as possible it just added more backends to implement
16:08ramcq: the other point of the D-Bus portal is that it's a security boundary, a sandboxed app should be required to obtain user consent from a trusted UI component outside of the sandbox
16:09ramcq: the whole portal gambit is working surprisingly well at establishing some de-facto APIs for stuff which has always worked a bit badly if you mix apps from different desktop environments. kind of the missing "desktop API" that nobody was able to sort out after desktop files / d-bus and dconf, then everyone fell down a well.
16:10marler8997: yeah was curious about that, does the wayland impl only allow xdg to access the capture so everything has to go through the Xdp portal?
16:10ramcq: depends on the compositor but that's how it works in GNOME AFAIK
16:11marler8997: ok thanks for chiming in with that
19:11SardemFF7: emersion: weird thing about that webhook payload, it doesn’t have the object_attributes.action which is supposed to tell what was the event (here, "open"), and I don’t see the information elsewhere
19:12emersion: gitlab omits it sometimes
19:14SardemFF7: sounds weird, also, the handler is stateless so I can pop a message for every state=opened MR I think, that would be a bit spammy
19:16emersion: https://gitlab.freedesktop.org/emersion/glhf/-/blob/master/main.go#L247
19:18SardemFF7: so the only case when it’s missing is when it’s "open"? guess that could work
20:40wlb: wayland Issue #349 opened by Twaik Yont (twaik) Wayland server hangs with endless repeated `failed to accept: Bad file descriptor` message. https://gitlab.freedesktop.org/wayland/wayland/-/issues/349