-
Notifications
You must be signed in to change notification settings - Fork 171
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
Not screenshot #1595
Comments
It seems that downloading the screenshot texture from GPU to CPU fails in a way unexpected in Smithay code:
There's eglinfo output: https://github.com/user-attachments/files/17801961/egl.txt System:
|
What format is the framebuffer in this case? (The full compositor log should show this.) If the framebuffer uses ARGB, but niri is trying to read ABGR the driver might not be happy about this and doesn't do the swizzle for us. Note that unsupported-pixel-format is a matchable Which leads to fun combinations of e.g. Mesa allowing to read BGRA on BGRA framebuffers, but nvidia doesn't, but is happy to do the swizzle for us. As a result this API is designed to be failable, so compositors could try both. |
According to drm_info from https://github.com/user-attachments/files/17797382/drm_info.txt, the primary plane is XRGB8888. (Which may be notable considering niri only passes Argb/Abgr as supported color formats.) During a screenshot, niri always creates a new Abgr8888 texture and renders to it from scratch, then downloads the result to CPU. |
No it's not. Internally smithay maps these to their X-variants for buffer allocation, if the A-variants aren't available, as the primary plane can obviously be opaque (if no underlays are present). (The GL Buffers are still alpha-variants to allow for blending.)
Ah, so you are controlling the framebuffer- (the texture in this case) and read-format by not reading back directly from the plane buffer. In that case the gl-format and type should be So the only reason I could think of is PBO's being unsupported, which we use for asynchronous read-back (which is also very heavily used in the multi-renderer). Reading about them, they are technically a GL ES 3.0 feature, if neither So we probably need a new capability and a synchronous pixel download to fix this... |
I don't know if I've got any useful input here, but I'm running into the same issue with i915. eglinfo
Or as a file: XCGs.txt |
In niri wm, where the smithay library is used, screenshots do not work! In the detailed thread YaLTeR/niri#807, they refer to smithay
The text was updated successfully, but these errors were encountered: