Core dump when trying to share the screen #190
Comments
|
Just as a quick Note: the corresponding drm_format should be Out of curiosity what gpu are you using? Can you please test #191 |
|
I will test it asap, and give you feedback whether or not it solved the issue for me :) I know I'll get a stern no-no, but I have a Nvidia GPU (believe me, trying to get wayland to work on it punishment in and of itself... 😢) |
|
This fixes the crash, but not my screen sharing issues :D I will have to keep looking for the reason for those. Thanks for your really really quick help though! |
In the same boat. Trying to look through the issues with sway + proprietary Nvidia drivers (510.54 currently). After applying the patch, crash goes away but pipewire seems very unhappy with the value it gets. For testing I'm just using Screen Capture API test. I'm rocking very similar setup on my laptop with AMD GPU and it works fine there. Probably a lot of rough edges in case of Nvidia driver. |
I'd just asked, because different gpus and setups make specific errors more likely. I don't mind adding support for a format since this isn't only applicable to one vendor.
If you can report that this MR works with a client we will consider merging it. |
|
I tried it now, the only difference in logs against what I posted is more less this (left side is with #152 patch): |
|
Is there any way I can help with moving this issue forward? :) |
|
If I remember correctly there is not much from our side to do: We can merge #191 but your problem is that this format is not supported by the other end. PipeWire currently doesn't do video format conversion and so the negotiation fails and no link is established. So you might want to open a bug request for libwebrtc. |
|
@columbarius |
|
Both use |
It is shared, just Firefox doesn't keep up so they carry a year old copy of WebRTC, but once Firefox does a rebase they will be again on par with screen sharing support. I also have Nvidia driver (v510) and screen sharing works for me in both KDE and GNOME (these are the ones I test my code with). I'm also not sure adding support for BGR will help here as WebRTC uses only BGRA, BGRx, RGBA, RGBx. |
So only with wlroots based wayland compositors there are issues, am I getting you right? |
Right: I meant
Great to hear. May I ask you for your distro and if you could test OBS from flathub-beta? |
|
@Gleydar Then your best bet is to look if wlroots/sway has the option to force a format. xdpw only supports the format used by wlroots for the surface which is recorded. |
|
Hm, I don't think there is a way to do that, but I might need to dig into that. |
Fedora 36. OBS from flathub-beta works for me. I already used OBS before, just not from flathub-beta.
I haven't tried. I can try to install Sway on Fedora and see if it works for me. |
Interesting when it just works for you ootb.
If you could try sway with xdpw build from master that would be great. It looks like Nvidia doesn't support implicit modifiers and we now support explicit modifiers. Even if it works I'm interested to see the DEBUG log from the screencast. |
I just built the xdpw from master and it still fails, on unsupported wl_shm format - log gist |
|
Oh right, please remove the |
|
I tried to do this diff --git a/src/screencast/screencast_common.c b/src/screencast/screencast_common.c
index 038cf7a..426ca69 100644
--- a/src/screencast/screencast_common.c
+++ b/src/screencast/screencast_common.c
@@ -302,9 +302,9 @@ uint32_t xdpw_format_drm_fourcc_from_wl_shm(enum wl_shm_format format) {
case WL_SHM_FORMAT_BGRA1010102:
return (uint32_t)format;
default:
- logprint(ERROR, "xdg-desktop-portal-wlr: unsupported wl_shm "
+ logprint(WARN, "xdg-desktop-portal-wlr: unsupported wl_shm "
"format 0x%08x", format);
- abort();
+ return (uint32_t)format;
}
}but then xdpw cannot convert the format to I'm not sure how it should be converted considering this comment? So is it, in fact, possible to somehow use this video format in |
|
Ok to summarize:
Sry for sending you on the patch route. I hoped the format used with dmabuf transport could be different and one of the supported ones. |
|
Sry miss click |
|
Would it be feasible to add software conversion of the buffer from BGR to BGRx? I don't know exactly where in the code the buffer gets passed to PipeWire, but if you've got any tips on that I might be able to write a rudimentary routine. I'm on the (now open-source-ish) NVIDIA driver 515.43 on Sway. |
Not really. We would have to spin up our own renderer and add intermediate copies and stuff. The better way is to pursue a videoconvert plugin for PipeWire which would do the convertion. This would be useful for all clients. |
|
Regardless of the conversion issue: is aborting the correct thing to do here? I'm not very familiar with Wayland internals, but it'd seem to me that it'd be best to somehow send that error to be displayed by whomever requested the screen sharing to be initiated instead of dumping core. |
|
FWIW, applying this patch to diff --git a/types/output/render.c b/types/output/render.c
index 985b93a9..7df1894f 100644
--- a/types/output/render.c
+++ b/types/output/render.c
@@ -284,20 +284,5 @@ struct wlr_drm_format *output_pick_format(struct wlr_output *output,
}
uint32_t wlr_output_preferred_read_format(struct wlr_output *output) {
- struct wlr_renderer *renderer = output->renderer;
- assert(renderer != NULL);
-
- if (!renderer->impl->preferred_read_format || !renderer->impl->read_pixels) {
- return DRM_FORMAT_INVALID;
- }
-
- if (!output_attach_back_buffer(output, NULL)) {
- return false;
- }
-
- uint32_t fmt = renderer->impl->preferred_read_format(renderer);
-
- output_clear_back_buffer(output);
-
- return fmt;
+ return DRM_FORMAT_XRGB8888;
}With this patch in place, OBS and friends work just fine. |
|
Hi, Thanks |
I preloaded the |
ghost
mentioned this issue
Sorry to ask a bit OT question, but is there a to force a format on Sway? 😉 If you don’t know that, could be please help me formulate the question for the Sway devs, as I have no idea how to describe that. 😉 Thanks! 🙏 |
ghost
mentioned this issue
|
Hey! Are there any new fixes for this? Or is the only way to fix this still having to patch it and compile it myself (which also means I'll also have to compile everything else that depends on wlroots so my wm and stuff)? Are there no plans for that patch to be merged into wlroots? Does it even still work after a year? |
|
The patch is quite the hack and unlikely to ever be merged: it simply hardcodes one particular DRM format and some graphics cards might not actually support this. As to whether it still works: no idea, sorry. Personally I gave up on Wayland for this year and went back to X11. |
|
I’ll probably try to apply the patch then, since Wayfire doesn’t have a feature to force the pixel format yet
I can definitely understand that, making wayland usable is indeed way too much work. I too did not switch to wayland, I’m trying to do so rn and yikes so much stuff just doesn’t work.
Ohhh okay, I thought something like “if nvidia” with the patch inside could fix that so that’s why I asked |
This won't be fixed in wlroots or xdpw. The compositor desides on the used format based on the supported hardware. The goal is to do a format convertion in PipeWire such that browsers can use the format xdpw offers. There is a protoype, but sadly I won't have till the end of the year to finish it. In the meantime please use the "hack" if it works for you. |
|
xdpw won't crash anymore when using 24bit colour formats, but since they are not commonly supported you might still need the "hack". |
Does anyone have an updated version of this patch for wlroots 0.16.2? I am still getting |
|
Hey, @ibrokemypie! I’ve edited the patch to work on current(?) wlroots back in October. You can find it here if you’d like. It works for me and fixes the problem. To make my own life easier I actually published it on my repository for openSUSE Tumbleweed (because it’s a pain in the ass to conciliate compiled packages with package manager packages), so if that’s what you use you could probably add my repo and install it too. Note that it’s possible that my patch won’t work if you’re trying to use the current wlroots branch - but it does work on the latest release (or at least with the latest release available on openSUSE repos) and that’s probably what you’d want to use. That said, you should probably know that wlroots unfortunately works like shit on NVidia (flashing windows, etcetera. Quite unusable, at least on my machine). You should try it out yourself to see if it works fine for you, of course, but personally I am getting more interested in the evolution of Louvre and Smithay since they both officially support NVidia. In fact, I’m starting to get interested in either migrating Wayfire to louvre from wlroots (since wayfire is awesome and currently what I’m trying to migrate to since it’s the only compositor out there that mimics essential features of my current Compiz workflow) as a side project or start making my own smithay compositor (not sure at all which would be less of a pain in the ass tbh) - this is really just a random idea I had for a side project that would make it feasible for myself to migrate to wayland tho, so don’t really expect anything. |
It’s nice to know it’s a planned feature! Thanks for your reply and of course take your time 💖 |
I'm getting a reproducible core dump when trying to share my screen via WebRTC with the following error message:
Currently, I'm using manjaro with the -git version of the following packages:
All other packages are the most up to date normal versions.
The text was updated successfully, but these errors were encountered: