ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
jmdaemon has joined #wayland
molinari is now known as Guest3063
molinari has joined #wayland
Guest3063 has quit [Ping timeout: 480 seconds]
marler8997 has joined #wayland
<marler8997>
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?
fmuellner has quit [Ping timeout: 480 seconds]
<ManMower>
marler8997: run "wayland-info"
<marler8997>
Thx ManMower, just built it and seems to have worked!
<Arnavion>
Also a compositor can support screen capture through the xdp+pipewire interface without exposing it as a wayland interface
<marler8997>
Yeah I've got the Xdp+Pipewire solution working, but it's buggy on some distros so I'm exploring alternatives as well.
<marler8997>
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!?!
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
maxzor__ has quit [Ping timeout: 480 seconds]
Serus has quit [Quit: WeeChat 3.7]
Serus has joined #wayland
floof58 is now known as Guest3070
floof58 has joined #wayland
Guest3070 has quit [Ping timeout: 480 seconds]
ukiran has joined #wayland
ukiran85 has joined #wayland
ukiran has quit [Ping timeout: 480 seconds]
___nick___ has quit []
___nick___ has joined #wayland
smallville7123 has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
smallville7123 has quit [Quit: Konversation terminated!]
ukiran85 has quit [Ping timeout: 480 seconds]
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
julio7359 has joined #wayland
that_guy_ has quit [Remote host closed the connection]
that_guy has joined #wayland
Company has quit [Quit: Leaving]
ukiran has joined #wayland
ukiran has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
m5zs7k has quit [Ping timeout: 480 seconds]
m5zs7k has joined #wayland
dcz_ has joined #wayland
dcz has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
kts has joined #wayland
molinari has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
tzimmermann has joined #wayland
ukiran has joined #wayland
kts has quit [Quit: Leaving]
ukiran has quit []
ukiran has joined #wayland
smallville7123 has joined #wayland
ukiran has left #wayland [#wayland]
ukiran has joined #wayland
<ukiran>
pq, where can i get the updated wayland-protocol implementation for color management ?
smallville7123 has quit [Ping timeout: 480 seconds]
ukiran has joined #wayland
smallville7123 has joined #wayland
mokee has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
maxzor__ has joined #wayland
kts has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
cvmn has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
manuel_ has joined #wayland
Fxzxmic has joined #wayland
<pq>
heeen, no.
<pq>
ukiran, there are no implementations in wayland-protocols or libwayland. All the implementations will be in compositors and application toolkits.
<ukiran>
yeah..but related to the protocol extensions, the support will be added in the protocol only right
eroc1990 has quit [Read error: Connection reset by peer]
eroc1990 has joined #wayland
manuel1985 has joined #wayland
<pq>
ukiran, sorry?
manuel_ has quit [Read error: Connection reset by peer]
<pq>
I will be working on at least a Weston implementation once I'm happy with the protocol specification.
<ukiran>
do you have any idea when this color-management protocol design gets freeze ?
<pq>
I'm quite confident it will be this year.
<JEEB>
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 :)
<pq>
JEEB, HDR cannot work without understanding color management, so understanding color management *first* seemed like the obvious way to start.
<pq>
applies to WCG too, which is practically a part of HDR
<pq>
in the end, that "stretch goal" is actually a very simple addition compared to WCG or HDR support.
<JEEB>
it is a freeform definition of a subset of transfers yes, and for gamut (primaries) I think either same or wider set
<JEEB>
(since IIRC you can't really define PQ or so in current-gen ICC profiles)
<ukiran>
pq, nice. i had gone through the link which u referred related to blending policy in weston. that is informative..
<pq>
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).
<pq>
and yes, ICCv4 does not seem suitable for describing HDR per se, not without the CICP amendment at least.
<pq>
it is good for WCG, though
<JEEB>
yup
<ukiran>
thanks for that. adding a small example explanation gives more understanding by considering default blending space and output space.
<pq>
bnasically the ICC profile approach is limited to what it can say about the profile connection space, I believe
<pq>
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.
devilhorns has joined #wayland
<pq>
*I'm not sure
<pq>
ukiran, cool :-)
<pq>
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.
ppascher has quit [Quit: Gateway shutdown]
<pq>
concrete examples are good, but only after you have the principles
<ukiran>
principles of understanding of the colorspaces ?
<ukiran>
Is libdisplay-info library is going to used by weston later for edid parsing ?
<ukiran>
edid *decoding*
<pq>
Weston will use libdisplay-info.
<pq>
ukiran, Weston is a Wayland compositor, and you can find a "Wayland compositor" in the winsys color pipeline doc.
<pq>
*a* compositor, not the only one
<ukiran>
Yes.. am aware of that.
<ukiran>
am making the setup of swick's wayland protocol (color) changes. Is there any compatible weston repo (pq) inorder to avoid the build issues ?
fmuellner has joined #wayland
<pq>
ukiran, what do you mean? What are you doing?
<pq>
There is no implementation of the current protocol spec anywhere yet that I know of.
<ukiran>
you mean to say, there is no blending policy implementation done in your local repos ?
<ukiran>
using GL shaders
<pq>
well, there is no protocol implementation to feed into that policy, either
<pq>
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.
<pq>
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.
<pq>
I have no private Weston branches for this, all the work I did so far has landed in Weston upstream.
<pq>
Vitaly might have some experiments with HDR, but not a protocol implementation.
<ukiran>
okay.
<pq>
The GL shaders are already in Weston upstream and could roughly handle HDR as well, if something was generating the right parameters for them.
<pq>
the shaders just apply arbitrary operations to numbers, they don't know or care what they mean
<ukiran>
here is the older commit where the client can tell its colorspace information to the compositor through protocol.
floof58 has quit [Remote host closed the connection]
floof58 has joined #wayland
Moprius has joined #wayland
floof58 has quit [Remote host closed the connection]
floof58 has joined #wayland
aaron465 has joined #wayland
Net147 has quit [Quit: Quit]
Net147 has joined #wayland
floof58 is now known as Guest3135
floof58 has joined #wayland
lmaoman has left #wayland [#wayland]
Guest3135 has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Ping timeout: 480 seconds]
ii8 has joined #wayland
<ii8>
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?
<ii8>
I'm using it like this `wl_cursor_theme_load(getenv("XCURSOR_THEME")...)`, not sure if that's always right
Szadek has quit [Ping timeout: 480 seconds]
Szadek has joined #wayland
kts has quit [Ping timeout: 480 seconds]
<pq>
maybe the theme of that name is simply not existing? Or not in the search paths.
<pq>
Looks like it won't automatically fall back to "default" theme if the named theme is not found.
<ii8>
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.
<pq>
oh, it does fall back
<ii8>
So even if I do `wl_cursor_theme_load(NULL...)` sometimes it doesn't return a theme
MajorBiscuit has joined #wayland
<pq>
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.
<ii8>
Or rather, the theme has no cursors
<ii8>
sorry
<ii8>
So it returns a theme, but if I try to load even just the "default" cursor from it, it doesn't have it.
<pq>
if a theme has zero cursors, literally, it falls back, eventually ending up with a built-in theme.
<pq>
ah, yes
<pq>
different themes may have differently named cursors
<SardemFF7>
[expanding !refs and #refs] it could be done though, had some ideas about the implementation in my code base
<SardemFF7>
thanks
<heeen>
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
<heeen>
fullscreen is not good enough for this usecase because some ui elements are supposed to be visible at the same time.
<daniels>
QML tries desperately to do quite a few copies
<heeen>
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
<daniels>
jesus
<emersion>
…
<heeen>
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
<heeen>
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
agd5f_ has joined #wayland
<heeen>
but using opengl to composit video frames was a non-starter for obvious reasons
<daniels>
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
<daniels>
I mean it may have improved since then, but tbh I'm not sure how you'd ever make QML/QtCompositor performant
<heeen>
well maybe not obvious, but it was an embedded platform with dedicated video processing, video motion interpolation and what have you
<heeen>
daniels and I actually met at that customer way back :)
<heeen>
hm that is two more blits than I would have imagined
<daniels>
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
<heeen>
does this apply to any opengl compositor or is it a peculiarity of qml
<heeen>
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
<daniels>
oh no, that's specifically how QML is implemented, and also partly how it's designed
<daniels>
more sensible compositors like weston either zerocopy things if possible, or one at most
<pq>
or two copies, if the source is a wl_shm buffer, because of glTexImage2D
<heeen>
how deep have you looked into this, do you feel like theres room for improvement or would it require changing too much of qtquick
<daniels>
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
smallville7123 has quit [Ping timeout: 480 seconds]
ukiran has joined #wayland
adia4 has quit []
adia4 has joined #wayland
Leopold_ has joined #wayland
rv1sr has quit []
rv1sr has joined #wayland
jmdaemon has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
<marler8997>
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?
<pq>
a D-bus interface, yes, I believe - not a Wayland interface
<emersion>
depends on the impl
<emersion>
wlroots uses a wayland protocol for this
<marler8997>
ah, emersion from grim
<emersion>
the D-Bus → Wayland adapter is xdg-desktop-portal-wlr
<emersion>
on wlroots, xdg-desktop-portal is a second-class citizen
<marler8997>
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?
<emersion>
the wayland protocol only works on compositors that implement it, and e.g. mutter doesn't want to implement it
<marler8997>
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?
<emersion>
s/distro/compositor/, but yeah, that's the idea
<marler8997>
Ok that makes sense, do you know which component provides the "selection UI" for the screencast session, is that the Wayland impl or Xdp?
<emersion>
it's the xdg-desktop-portal impl
<emersion>
on wlroots it
<emersion>
's xdg-desktop-portal-wlr
<emersion>
there is also xdg-desktop-portal-gnome for instance
<emersion>
i don't remember off-hand whether the D-Bus screenshot/cast impl is in xdg-desktop-portal-gnome, or in mutter directly
<marler8997>
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)
<pq>
What Wayland's D-Bus interface?
<marler8997>
I had that question and am currently trying to find it in "screen-cast.c", I see "impl_connection" which looks promising
<kennylevinsen>
the underlying implementation differs between compositors
<davidre>
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
<kennylevinsen>
Not every compositor, but there are a few approaches
jmdaemon has joined #wayland
<marler8997>
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
<davidre>
But it sounds you're making yourself do more work by wanting to implement all the things
<davidre>
then necessary
<marler8997>
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
devilhorns has quit []
<marler8997>
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
<marler8997>
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 :)
<jadahl>
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
<jadahl>
if there are issues specific to your hardware, first figure out the portal backend, then report a bug to that portal backend
<marler8997>
yeah I'll try to look into a way to reproduce/identify/fix this bug, I'm exploring both options right now
<jadahl>
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
<marler8997>
all of the above, this is an application for hundreds of distros
Leopold__ has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
<marler8997>
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)
<daniels>
*XDG
<daniels>
you would need to have an XDG portal running inside the shared distro, but it is certainly doable
<marler8997>
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
<emersion>
weston doesn't support xdg-desktop-portal
<daniels>
emersion: given WSLg does seamless desktop, you'd want to forward the request to the host anyway so you could choose any window
<marler8997>
good to know, weston was what we used at HP and that's where I implemented the DRM-based capturer
<emersion>
hm, maybe… sounds "fun"
<emersion>
a DRM-based capture has several downsides: (1) requires root (2) racy (3) no proper format negotiation
<daniels>
yeah, I'd definitely not recommend that
<daniels>
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
<emersion>
i wouldn't call an xdg-desktop-portal impl "easy"…
<emersion>
the -wlr one required a lot of work
<marler8997>
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
<marler8997>
emersion I'm impressed you came up with all the downsides so quickly, you know your stuff in this area :)
<emersion>
not the first time someone asks about this :P
<marler8997>
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
jmdaemon has quit [Ping timeout: 480 seconds]
<ramcq>
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
<ramcq>
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.
<marler8997>
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?
<ramcq>
depends on the compositor but that's how it works in GNOME AFAIK
<marler8997>
ok thanks for chiming in with that
Leopold__ has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
maxzor__ has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
<SardemFF7>
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
<emersion>
gitlab omits it sometimes
<SardemFF7>
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