Patches have been landed. What's missing still in KWin at the moment is support for multi-plane buffers since we assume one texture per window internally. This looks to me like a bigger rewrite and should go into a separate task.

Since direct scanout or sampling can be done interchangeable at any point in time send the formats + modifiers in both results (intersection).

Regarding our rendering APIs:
This makes only sense when using OpenGl/EGL, not with QPainter.

Some good overview on what we need to do is given here: https://www.x.org/wiki/Events/XDC2017/widawsky_fb_modifiers.pdf

<Sho_> bshah: since there's no takers, i suggest you commandeer the revisions and finish them to the comments
<bshah> Okay, cool

Congrats on the great video, and thank you for your hard work!

Thank you so much Lucas!

So I made a few screen recordings, which include:

Unlikely, Gnome's shell runs in-process with the compositor, they don't need any IPC for the same use case.

afaik gnome already has this, do they have some sort of protocol there?

mart/plasmavirtualdesktop branch on kwayland, i started the xml file for it, I'm trying to document it as well, to see if i'm getting the protocol right

After much research my current plan looks like this:

As I mentioned to @Kanedias on IRC, there is also remote desktop portal which I proposed as a GSoC task, see https://community.kde.org/GSoC/2018/Ideas#Project:_Remote_desktop_portal.

I use a 33 point custom curve loaded via XF86VidModeSetGammaRamp, not a single value. Today's displays need some 'S' shaped curve, but unfortunately needs fine tuning for each display.

Hard requirements have been met by the two patches. Soft requirement was dropped, something to look into in the future.

In T4465#129202, @cfeck wrote:

Test image for (sRGB) gamma calibration: http://imagezero.maxiom.de/files/sRGB-gamma.png

In T7785#134387, @romangg wrote:

Can the remote access protocol be extended in this way? It would make sense by its name to facilitate remote input support here as well.

In T7785#134386, @Kanedias wrote:

We should think about input support as now remote sessions are limited to view-only.

Can the remote access protocol be extended in this way? It would make sense by its name to facilitate remote input support here as well.

This finally is ready to proceed, thanks everybody. D10965 to go. I'll begin working on KRfb integration with pipewire stream this week.
We should think about input support as now remote sessions are limited to view-only.

In T7785#133501, @romangg wrote:

One remaining question:

xdg-desktop-portal-kde automatically takes up querying KWin for the GBM buffers, converts them to Gl what process does this for xdg-desktop-portal-kde

Xdg-desktop-portal-kde does it on its own, same way like kwrr (I actually took that part from kwrr).

Thanks for the answers. Sounds fine to me. Not sure if we only want to support the portals stuff and by that indirectly make it a standard in a broader sense, but if it works fine for everybody and there are no other solutions available, I'm certainly not against it.

In T7785#131835, @romangg wrote:

So for an overview we now have:

• D1230, that enables GBM buffer passing in KWin,
• D1231, that implements a remote access interface in KWayland,
• D10965, that enables xdg-desktop-portal-kde to talk to KWin via the remote access interface in KWayland.
  
  So an application is now supposed to talk via DBus to xdg-desktop-portal to initiate a video transfer and the backend code in xdg-desktop-portal-kde automatically takes up querying KWin for the GBM buffers, converts them to Gl (what process does this for xdg-desktop-portal-kde?) and sends them via PipeWire to the application. Is this correct?

So for an overview we now have:

@romangg , @davidedmundson , @graesslin , should we merge D1230 & D1231? D10965 for xdg-desktop-portal depends on this code.

@jgrulich For situation where deleting KWayland::Client::Output doesn't help - please see D10929

In T7785#130844, @Kanedias wrote:

AFAIK Mesa 17.3.x had a regression that caused lockups on intel iGPUs. Many of them were finally nailed down only in 17.3.6, see here
Can you try new version on your Fedora 27 laptop?

I think I know what's the problem with delete output. In KWayland in output.cpp: WaylandPointer<wl_output, wl_output_destroy> output. While this is technically correct it shouldn't destroy output right away.
It should call wl_output_release that will notify destruction to the server so it will know this client has no more bound outputs and RemoteAccess interface and stop sending buffers.

Yep, I managed to get remote stream too, though it doesn't look so good as yours yet, Jan :)
I'll be pushing changes with removing GSource and rewriting it with QSocketNotifier to kwin-remote-receiver, you can take a look if interested.

AFAIK Mesa 17.3.x had a regression that caused lockups on intel iGPUs. Many of them were finally nailed down only in 17.3.6, see here
Can you try new version on your Fedora 27 laptop?

This is setup I use where the crash can be reproduced:

System:    Host: localhost.localdomain Kernel: 4.15.4-300.fc27.x86_64 x86_64 bits: 64 gcc: 7.3.1
           Desktop: KDE Plasma 5.12.2 (Qt 5.9.4) Distro: Fedora release 27 (Twenty Seven)
Machine:   Device: laptop System: LENOVO product: 20EGS0R60G v: ThinkPad W541 serial: N/A
           Mobo: LENOVO model: 20EGS0R60G serial: N/A UEFI [Legacy]: LENOVO v: GNET85WW (2.33 ) date: 12/07/2017
Battery    BAT0: charge: 87.9 Wh 100.0% condition: 87.9/99.5 Wh (88%) model: SANYO 45N1779 status: Full
CPU:       Quad core Intel Core i7-4810MQ (-MT-MCP-) arch: Haswell rev.3 cache: 6144 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 22348
           clock speeds: max: 3800 MHz 1: 2879 MHz 2: 2738 MHz 3: 2367 MHz 4: 3491 MHz 5: 3039 MHz 6: 2480 MHz
           7: 3277 MHz 8: 2736 MHz
Memory:    Using dmidecode: root required for dmidecode
Graphics:  Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller bus-ID: 00:02.0
           Card-2: NVIDIA GK107GLM [Quadro K1100M] bus-ID: 01:00.0
           Display Server: wayland (X.org 119.6 ) drivers: modesetting (unloaded: fbdev,vesa)
           Resolution: 1920x1080@59.96hz, 1920x1200@59.88hz, 1920x1080@59.96hz
           OpenGL: renderer: Mesa DRI Intel Haswell Mobile version: 4.5 Mesa 17.3.5 Direct Render: Yes

pw_remote_destroy - calls free(remote->error) even if it's not initialized, is this a bug?..

Can't make it crash, unfortunately.
@jgrulich , seems I need some cooperation to make it reliably fail, let's compare our specs.

@jgrulich hooray!

Related bug: https://bugs.kde.org/show_bug.cgi?id=350688

I have been finally able to stream data from KWin through xdg-desktop-portal-kde and receive them with xdg-portal-test-kde. There are still issues like to select just one screen which should be recorder or initialize pipewire stream based on screen resolution. Right now it streams content from all screens and has hardcoded resolution to 1920x1080, but basically it works. I will keep polishing that and implement missing functionality tomorrow or so.

Let's make sure we expose middle click emulation (i.e. middle click when both the left and right buttons are clicked at the same time). This was recently requested in https://bugs.kde.org/show_bug.cgi?id=383379

Test image for (sRGB) gamma calibration: http://imagezero.maxiom.de/files/sRGB-gamma.png

In T7785#128972, @Kanedias wrote:

@jgrulich , I think I found a way to make KWin send only needed buffers to support >1 monitor setup.

The remote access protocol sends buffers for all outputs bound by the client.
So instead of this:

connect(m_registry, &KWayland::Client::Registry::outputAnnounced, this, [this] (quint32 name, quint32 version) {
    qCDebug(XdgDesktopPortalKdeScreenCast) << "Binding output";
 
    if (!m_output) {
        m_output = m_registry->createOutput(name, version);
        connect(m_output, &KWayland::Client::Output::changed, this, [this] {
            qCDebug(XdgDesktopPortalKdeScreenCast) << "Output bound:" << m_output->manufacturer() << m_output->model();
        });
    }
});

you can wait for all outputs to be announced and collect them.
Then, after the user confirms its selection you bind the specified output and kwin starts sending you buffers associated with it.

Ok, guess I'm missing something then, I'll take a closer look, thanks!

@Kanedias, yes, I can connect with that code, you need pipewire running to be able to connect. I use it the same way mutter uses pipewire.

@jgrulich , were you able to connect the stream to pipewire with the code from xdg-desktop-portal-kde?
It says only "Stream stage changed: connecting" and then "protocol-native: got connection error" to me.

@jgrulich , I think I found a way to make KWin send only needed buffers to support >1 monitor setup.

Potentially relevant/mine-able for inspiration: D8168: kcm_input: Refactor the code and add support for libinput under X11