transparent screenshot with grim #1438
Comments
|
Anything I can do do help with this bug? |
|
This seems to only happen on Nouveau. Are you using Nouveau? |
|
Yes. |
|
I'm also affected by this bug. My card: |
|
I believe this is a wlroots bug - see my comment in https://bugs.freedesktop.org/show_bug.cgi?id=109330#c5. init_drm_plane_surfaces uses GBM_FORAMT_XRGB8888 while the config is chosen for GBM_FORMAT_ARGB8888. |
|
Okay, so the situation is more complicated. Tried to apply the patch (https://hastebin.com/awiwunojox.php), but it doesn't work on my GPU because the primary plane doesn't support ARGB (so it refuses the alpha framebuffer altogether). |
|
If I recall correctly, weston had some logic to fallback to an opaque format if the alpha one wouldn't work. |
|
Yeah, we could do that, but it wouldn't fully fix the issue: we'll still use a ARGB visual with a XRGB framebuffer on some GPUs. I guess the better solution is not to use GL APIs to know if the buffer has an alpha channel, but rather track framebuffer formats and be able to query them from the renderer. This can't be done with the current design, but I think the renderer redesign pull request will help. |
|
Ideally you'd have a way of passing the format the plane is initialized with to the logic that selects a GL config that uses that plane as a front buffer. That way there's never any mismatch. |
|
The new renderer does away with EGL configs and exclusively uses EGL images to draw to. This should remove any possibility for a framebuffer mismatch. |
|
As said in the FDO issue, we're allowed to use ARGB for the framebuffer format and then call |
We create the EGL config with GBM_FORMAT_ARGB8888, but then initialize GBM BOs with GBM_FORMAT_XRGB8888. This mismatch confuses Mesa. Instead, we can always use GBM_FORMAT_ARGB8888, and use DRM_FORMAT_XRGB8888 when calling drmModeAddFB2. Fixes swaywm#1438
|
Users affected by this bug: can you try out #1509? |
|
@emersion: thank you, this fixed the bug for me. screenshot is fine now with grim 1.0 stable! here's the PKGBUILD I used to build wlroots with your patch https://git.project-insanity.org/snippets/49 |
|
It seems to have fixed the bug for me too. I had a weird bug where I wasn't able to click some applications (maybe related to xwayland) but I probably did something wrong when updating wlroots with https://github.com/colemickens/nixpkgs-wayland on NixOS. Thanks! |
|
@bbigras: maybe you also have to install the newest sway git version beside of wlroots git |
We create the EGL config with GBM_FORMAT_ARGB8888, but then initialize GBM BOs with GBM_FORMAT_XRGB8888. This mismatch confuses Mesa. Instead, we can always use GBM_FORMAT_ARGB8888, and use DRM_FORMAT_XRGB8888 when calling drmModeAddFB2. Fixes swaywm#1438
|
@onny yes that was probably it. In the end I cherry-picked the commit. Thanks! |
Feel free to rename the title. I was asked to open an issue here. emersion/grim#17 (comment)
Screen captures using grim result in transparent pictures.
NVIDIA Quadro FX 580 with nouveau. Dual screen
grim emersion/grim@9c2e630
wlroots c70b8f6
sway version swaywm/sway@d440468
sway -d 2> ~/sway.log
WAYLAND_DEBUG=client grim > test.png 2>&1
The text was updated successfully, but these errors were encountered: