-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support XDG Desktop Portal / Pipewire screencasting #16
Comments
Current progress tracked in branch feature-xdg-portal |
Current status: the initial codebase is there, but rendering the imported DMA-BUF still seems to fail in some way (the resulting texture is black). Currently unimplemented are stream format negotiation and shm buffers. Of course this also needs to be cleaned up a whole lot and made more robust. |
I'm currently at a dead end; none of the debug info provided by MESA / GL is of any help to me right now (most debug flags don't output anything, since there aren't any GL errors, and the driver specific debug flags vomit out endless parameter dumps that aren't very useful), and the import of the DMA-BUF from pipewire succeeds, but drawing results in a black screen. I am not sure where the problem is, but so far I have only tested this on an Intel system. If you would like to test this, use these commands: git checkout feature-xdg-portal
cmake . -B build -DWITH_XDG_PORTAL_BACKEND=ON
cd build
make
./wl-mirror -v -b xdg-portal eDP-1 If this results in anything other than a black screen on your system, please let me know. |
I recently found some ugly use after free bugs in my pipewire feature branch, but after fixing those the black screen is still there, so that was not the cause it seems. |
Just compiled this branch (feature-xdg-portal) and tried this on my all AMD system
the only unlisted requirement i needed to compile was "libdrm-dev". When running
If i put the block with comment "// create xdg_output object" before the block with "// check for xdg_output_manager" i get:
But I'm not sure if that's any better. Happy to test anything you can do to get Gnome working 👍 |
Hi! Thanks for testing that branch!
Yes, the XDG portal branch AFAIK depends on the headers for libdrm for the
This is mainly because the registry event handling code was written very early on when I understood little about Wayland's object system. I need to rewrite that code significantly in order to make it more robust. GNOME sends globals in a different order than sway and This branch sadly doesn't work yet, even on sway, because of a really weird black screen issue with EGL / pipewire / DMA-BUFs that I haven't been able to figure out the cause of. Also, even if this branch works, you probably won't be able to move/resize the window on GNOME, since wl-mirror does not have client-side window decorations (yet). This is fixed in the TL;DR: There is still lots to do and a lot of stuff to fix, but progress is being made, and I hope I can get this to work in the near-ish future, but I can't guarantee anything since I'm pretty stuck with a basically undebuggable bug (the black screen). |
A lack of move/resize or decor isn't a problem for me, my use case is copying a fake 4800X1200 monitor onto three real 1600X1200 monitors to create a Eyefinity setup that is robust without having to do a variety of tweaks and hacks for each game or doing weird X11 things that won't be future proof. Wl-mirror seems perfect for that as i can fit the window to the three monitors and copy the fake, and run the game in exclusive full screen to capture the input. But anyway i won't hijack your thread, let me know if you need to test a debug build or something. |
My best guess for what is going wrong with the black screen in the I need to rewrite that whole code to actually negotiate formats since that is likely what's causing the issues. Documentation: https://docs.pipewire.org/page_dma_buf.html |
I'm not sure what happened, but as of today, with sway-git 1.10.r7384.05e895c-1, wlroots-git 0.19.0.r7159.775817e27-1, and pipewire 1.2.2-1, the xdg-portal branch has magically started working! I need to go back and clean it up, and also verify what the first versions are this works with, as well as test on more different GPU setups (testing this on my AMD integrated graphics right now). |
Tested this together with Libdecor now, also works on KDE and Gnome (see #17) |
Just a random question since I was curious, would it be possible to specify a window as a source and only display a part of it (crop using region)? |
with the XDG portal screenshare backend this should technically be possible (if the compositor supports window capture, which sway currently doesn't, but others do), though that's not finished yet. The main issue is that AFAIK we don't get the coordinates of the target window, so we can't easily know how to transform region coordinates from |
quick development update on this: I don't currently have a lot of time for wl-mirror, so I'm falling a bit behind on actually rewriting this to be in a state that I can release, but at least it's no longer blocked on black-screen bugs that I don't understand. |
This is the "standard" screencasting method for wayland. It's less convenient than the two sway-specific protocols in that you cannot specify the monitor or region directly, but it is the only method that will work on all compositors.
Tasks related to less direct selection of capture targets:
Implementation Tasks:
The text was updated successfully, but these errors were encountered: