PipewireEGL: failed to create a texture (reason = 'Arguments are inconsistent')

[dankmolot]

Bug report, debug log and your config file (FULL LOGS ARE MANDATORY)

debug log: https://pastebin.com/4gTe0Wyg
config: HyperHDR-21.0.0.0beta1-Backup-2024-12-29.json

I want also add that this issue probably related to Hyprland, since on KDE system capture was working.

Steps to reproduce

1. Launch Hyprland with uwsm
2. Install hyperhdr-git from AUR
3. LED Hardware is configured as Adalight with Awa protocol
4. Enable system capture with default settings (Automatic device, 10 fps, max stream width 512)
5. Select a primary monitor in popup menu from xdg-desktop-portal-hyprland

What is expected?

System capture will work as expected.

What is actually happening?

HyperHDR unable to capture system through pipewire (DmaBuf, egl) with error:

PipewireEGL: failed to create a texture (reason = 'Arguments are inconsistent')

System

None
- Database:        read/write

HyperHDR Server OS: 
- Distribution:   Arch Linux
- Architecture:   x86_64
- CPU Model:      AMD Ryzen 7 5800X 8-Core Processor
- CPU Type:       33
- Kernel:         linux (6.12.7-arch1-1 (WS: 64))
- Qt Version:     6.8.1
- OpenSSL:        OpenSSL 3.4.0 22 Oct 2024
- Browser:        Mozilla/5.0 (X11; Linux x86_64; rv:133.0) Gecko/20100101 Firefox/133.0 

Additional system information:

$ pacman -Q hyprland wayland pipewire wireplumber xdg-desktop-portal-hyprland xdg-desktop-portal-gtk mesa hyperhdr-git
hyprland 0.46.2-4
wayland 1.23.1-1
pipewire 1:1.2.7-1
wireplumber 0.5.7-1
xdg-desktop-portal-hyprland 1.3.9-3
xdg-desktop-portal-gtk 1.15.1-2
mesa 1:24.3.2-1
hyperhdr-git v21.0.0.0beta1.r5.c24549ce-1

$ glxinfo -B
name of display: :1
display: :1  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: AMD (0x1002)
    Device: AMD Radeon RX 6800 (radeonsi, navi21, LLVM 18.1.8, DRM 3.59, 6.12.7-arch1-1) (0x73bf)
    Version: 24.3.2
    Accelerated: yes
    Video memory: 16384MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
    VBO free memory - total: 14810 MB, largest block: 14810 MB
    VBO free aux. memory - total: 15792 MB, largest block: 15792 MB
    Texture free memory - total: 14810 MB, largest block: 14810 MB
    Texture free aux. memory - total: 15792 MB, largest block: 15792 MB
    Renderbuffer free memory - total: 14810 MB, largest block: 14810 MB
    Renderbuffer free aux. memory - total: 15792 MB, largest block: 15792 MB
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 16384 MB
    Total available memory: 32384 MB
    Currently available dedicated video memory: 14810 MB
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon RX 6800 (radeonsi, navi21, LLVM 18.1.8, DRM 3.59, 6.12.7-arch1-1)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.3.2-arch1.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.3.2-arch1.1
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.3.2-arch1.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

[awawa-dev]

Hi
Thank you for the detailed log. The problem that EGL reports concerns the list of texture attributes that are built here:

HyperHDR/sources/grabber/linux/pipewire/PipewireHandler.cpp

Line 782 in c24549c

QVector<EGLint> attribs;

As you can see, some of these parameters are directly the values ​​that Pipewire passes to us. Since the mechanism itself works on other systems, I suspect that Pipewire in this configuration passes us some parameters that are incorrect or at least unusual and require from us some special approach.

[dankmolot]

Hello!
Thank you for your fast response. I probably can try to locally build HyperHDR and see what attributes are passed.

[dankmolot]

Attrib values are:

_frameWidth: 2560
_frameHeight: 1440
_frameDrmFormat: 875713112
_frameDrmModifier: 546749187
newFrame->buffer->datas[0].fd: 70
newFrame->buffer->datas[0].chunk->offset: 0
newFrame->buffer->datas[0].chunk->stride: 10240

_frameDrmFormat here is XR24

Only file descriptor changes time from time. Any idea what is wrong or what to do next?

[awawa-dev]

The file description naturally changes every time, but we can't check if it's correct. If the app doesn't crash then it should be OK.
Yes, 875713112 is Xrgb8888 aka XR24 so it should be supported.
Frame width (2560) * pixel size(4) = 10240 = stride so it's typical.
I'm not sure about frameDrmModifier. Try to comment out this if section:

HyperHDR/sources/grabber/linux/pipewire/PipewireHandler.cpp

Line 799 in c24549c

if (_frameDrmModifier != DRM_FORMAT_MOD_INVALID)

Could you compare the results to KDE?

[dankmolot]

Removing DMA modifiers fixed the problem! Just to be sure, I commented these lines

HyperHDR/sources/grabber/linux/pipewire/PipewireHandler.cpp

Lines 799 to 803 in c24549c

	if (_frameDrmModifier != DRM_FORMAT_MOD_INVALID)
	{
	attribs << EGL_DMA_BUF_PLANE_MODIFIER_LO_EXT[i] << EGLint(_frameDrmModifier & 0xffffffff)
	<< EGL_DMA_BUF_PLANE_MODIFIER_HI_EXT[i] << EGLint(_frameDrmModifier >> 32);
	}

[awawa-dev]

Yes, that's the correct section. For some reason it doesn't like DrmModifier, I don't know why 🤷

Maybe _frameDrmModifier should be uint64_t (but probably it should make no difference)? Could you check it and enable the if section again?

HyperHDR/include/grabber/linux/pipewire/PipewireHandler.h

Line 160 in c24549c

int64_t _frameDrmModifier;

[dankmolot]

Changing to uint64_t haven't fixed the issue. I will try later install KDE and see how modifier differs.

[awawa-dev]

deleted comment
Never mind, my mistake

[awawa-dev]

@dankmolot I've prepared the workaround but can't test it under VirtualBox (no DRM support). Could you switch to pipewire_drm_workaround branch and compile&test it?

[dankmolot]

No problem, but I can't test it right now. Will be able to tell how it goes after around 3 hours

[dankmolot]

@awawa-dev
Your workaround algorithm with removing drm modifiers haven't worked properly, so I decided to do the same thing myself. Hope you don't mind!

Also your workaround spammed in output PipewireEGL: failed to create ... message, workaround in pull request sends this message only one time.

Pipewire: Using DmaBuf frame type. The hardware acceleration is ENABLED.
PipewireEGL: failed to create a texture (reason = 'Arguments are inconsistent'). Trying to remove DMA modifiers...
PipewireEGL: got the texture
PipewireEGL: succesfully rendered the DMA texture

[awawa-dev]

Considering the users, the vast majority of whom approach with extreme distrust and reluctance to compile anything on their own😉 I think that a solution that would retry creating a texture without additional parameters for DRM would be more appropriate. Even at the cost of one additional line in the logs, besides it would not change the current tested path if the texture could be created on the first attempt: it does not cost us anything and will free me from explaining the same problem when it resurfaces on github 😄 As I explained, I do not have hardware setup to check and correct the algorithm for DRM now and it will have to wait a few days but I'm sure it will work.

[dankmolot]

In KDE environment I get these values:

_frameDrmFormat = 875713112
_frameDrmModifier = 144115188622605059

Here is full log: https://pastebin.com/MXqq7eJf

[dankmolot]

Considering the users, the vast majority of whom approach with extreme distrust and reluctance to compile anything on their own😉 I think that a solution that would retry creating a texture without additional parameters for DRM would be more appropriate. Even at the cost of one additional line in the logs, besides it would not change the current tested path if the texture could be created on the first attempt: it does not cost us anything and will free me from explaining the same problem when it resurfaces on github 😄 As I explained, I do not have hardware setup to check and correct the algorithm for DRM now and it will have to wait a few days but I'm sure it will work.

That is totally fine! Thank you for figuring the problem and for being very responsive. I'm glad I can enjoy proper system capture :)

[dankmolot]

Discord also suffers from wrong dma modifiers:

[105796:0103/190637.618909:ERROR:egl_dmabuf.cc(608)] Failed to record frame: Error creating EGLImage - EGL_BAD_MATCH
[105796:0103/190637.618928:ERROR:shared_screencast_stream.cc(951)] Dropping DMA-BUF modifier: 144115188622605059 and trying to renegotiate stream parameters

[awawa-dev]

Well, this DRM bug is escalating quickly 😦 So let's not wait with workaround. I've fixed my code (one -1 too far) and committed the changes. Can you check your PR after changing to auto-retry if it works for you too? Then I will merge it.