fix pipewire portal by removing blocks parameter

[Mic92]

Summary
When this parameter is enabled than pipewire reports the following error:

HyperHDR:
Pipewire: updated parameters 0
Pipewire: core error reported
Pipewire: stream reports error 'error alloc buffers: Invalid argument' Pipewire: core reports error 'error alloc buffers: Invalid argument'

Pipewire:
pipewire[1850759]: pw.context: params Spa:Enum:ParamId:Buffers: 1:0 Invalid argument (input param) pipewire[1850759]: pw.context: Object: size 168, type Spa:Pod:Object:Param:Buffers (262148), id Spa:Enum:ParamId:Buffers (5)
pipewire[1850759]: pw.context: Prop: key Spa:Pod:Object:Param:Buffers:BlockInfo:size (3), flags 00000000
pipewire[1850759]: pw.context: Int 33177600
pipewire[1850759]: pw.context: Prop: key Spa:Pod:Object:Param:Buffers:buffers (1), flags 00000000
pipewire[1850759]: pw.context: Choice: type Spa:Enum:Choice:Range, flags 00000000 28 4
pipewire[1850759]: pw.context: Int 16
pipewire[1850759]: pw.context: Int 2
pipewire[1850759]: pw.context: Int 16
pipewire[1850759]: pw.context: Prop: key Spa:Pod:Object:Param:Buffers:BlockInfo:stride (4), flags 00000000
pipewire[1850759]: pw.context: Int 15360
pipewire[1850759]: pw.context: Prop: key Spa:Pod:Object:Param:Buffers:BlockInfo:dataType (6), flags 00000000
pipewire[1850759]: pw.context: Choice: type Spa:Enum:Choice:Flags, flags 00000000 20 4
pipewire[1850759]: pw.context: Int 12
pipewire[1850759]: pw.context: Prop: key Spa:Pod:Object:Param:Buffers:blocks (2), flags 00000000
pipewire[1850759]: pw.context: Int 3
pipewire[1850759]: pw.context: params Spa:Enum:ParamId:Buffers: 0:0 Invalid argument (output param)
pipewire[1850759]: pw.context: Object: size 216, type Spa:Pod:Object:Param:Buffers (262148), id Spa:Enum:ParamId:Buffers (5)
pipewire[1850759]: pw.context: Prop: key Spa:Pod:Object:Param:Buffers:buffers (1), flags 00000000
pipewire[1850759]: pw.context: Choice: type Spa:Enum:Choice:Range, flags 00000000 28 4
pipewire[1850759]: pw.context: Int 2
pipewire[1850759]: pw.context: Int 2
pipewire[1850759]: pw.context: Int 16
pipewire[1850759]: pw.context: Prop: key Spa:Pod:Object:Param:Buffers:blocks (2), flags 00000000
pipewire[1850759]: pw.context: Int 1
pipewire[1850759]: pw.context: Prop: key Spa:Pod:Object:Param:Buffers:BlockInfo:size (3), flags 00000000
pipewire[1850759]: pw.context: Int 33177600
pipewire[1850759]: pw.context: Prop: key Spa:Pod:Object:Param:Buffers:BlockInfo:stride (4), flags 00000000
pipewire[1850759]: pw.context: Choice: type Spa:Enum:Choice:Range, flags 00000000 28 4
pipewire[1850759]: pw.context: Int 15360
pipewire[1850759]: pw.context: Int 15360
pipewire[1850759]: pw.context: Int 2147483647
pipewire[1850759]: pw.context: Prop: key Spa:Pod:Object:Param:Buffers:BlockInfo:align (5), flags 00000000
pipewire[1850759]: pw.context: Int 16
pipewire[1850759]: pw.context: Prop: key Spa:Pod:Object:Param:Buffers:BlockInfo:dataType (6), flags 00000000
pipewire[1850759]: pw.context: Choice: type Spa:Enum:Choice:Flags, flags 00000000 20 4
pipewire[1850759]: pw.context: Int 14
pipewire[1850759]: pw.link: (103.0.0 -> 79.0.0) allocating -> error (error alloc buffers: Invalid argument) (ready-ready)

This happens with pipewire 1.0.0 and pipewire master.

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Code style update
• Refactor
• Docs
• Build-related changes
• Other, please describe:

If changing the UI of web configuration, please provide the before/after screenshot:

Does this PR introduce a breaking change? (check one)

• Yes
• No
• Don't know

If yes, please describe the impact and migration path for existing setups:

The PR fulfills these requirements:

• When resolving a specific issue, it's referenced in the PR's body (e.g. Fixes: #xxx[,#xxx], where "xxx" is the issue number)

To avoid wasting your time, it's best to open a feature request issue first and wait for approval before working on it.

Other information:

[awawa-dev]

Hi
Thank you for reporting the issue and submitting PR. I would like to ask if you could evaluate and test for yourself whether, instead of removing this parameter, you can add a guard for Pipewire 1.0.0 or newer, because otherwise it would force regression testing for older versions of this library (and the variety of graphics cards does not make it easier)?
For example:
#if !PW_CHECK_VERSION(1, 0, 0)
SPA_PARAM_BUFFERS_blocks, SPA_POD_Int(1),
#endif
Unless you also encountered the problem on lower versions of pipewire also? What OS did this problem occur on and what graphics card do you have?

[Mic92]

Hardware: iGPU on Intel 13th Gen.
OS: Linux

What is this parameter used for, that I am disabling?

[awawa-dev]

Number of planes for specific DRM format. RGBx/BGRx formats should have 1 plane. There should be more info about updated DRM mode in the console output, if you run HyperHDR from the command line. And what distribution are you using?

BTW if possible, runtime pw_get_library_version should be instead of PW_CHECK_VERSION. But here's where things get complicated.

[Mic92]

It's on NixOS, but that shouldn't really matter because it's the same kernel/mesa/pipewire that everyone is using as well.

Here is the full log of HyperHDR:

Pipewire: Got response from portal Start
Received restoration token: c1b4160b404b
Pipewire: format property size 3840 x 2160
Pipewire: format property source_type = 1
Connecting to Pipewire interface for stream: 3840 x 2160
Session type: wayland , X11 detected: no
PipewireEGL: EGL initialized for HyperHDR. Version: 1.5
PipewireEGL: Found 43 DMA-BUF formats
PipewireEGL: got DMA format list (count = 43)
PipewireEGL: Found unsupported by HyperHDR 'AB4H' DMA format
PipewireEGL: Found unsupported by HyperHDR 'XB4H' DMA format
PipewireEGL: Found unsupported by HyperHDR 'AB48' DMA format
PipewireEGL: Found unsupported by HyperHDR 'XB48' DMA format
PipewireEGL: Found unsupported by HyperHDR 'AR30' DMA format
PipewireEGL: Found unsupported by HyperHDR 'XR30' DMA format
PipewireEGL: Found unsupported by HyperHDR 'AB30' DMA format
PipewireEGL: Found DRM_FORMAT_ARGB8888 DMA format (AR24)
PipewireEGL: Found DRM_FORMAT_ABGR8888 DMA format (AB24)
PipewireEGL: Found DRM_FORMAT_XRGB8888 DMA format (XR24)
PipewireEGL: Found DRM_FORMAT_XBGR8888 DMA format (XB24)
PipewireEGL: Found unsupported by HyperHDR 'AR15' DMA format
PipewireEGL: Found unsupported by HyperHDR 'RG16' DMA format
PipewireEGL: Found unsupported by HyperHDR 'R8  ' DMA format
PipewireEGL: Found unsupported by HyperHDR 'R16 ' DMA format
PipewireEGL: Found unsupported by HyperHDR 'GR88' DMA format
PipewireEGL: Found unsupported by HyperHDR 'GR32' DMA format
PipewireEGL: Found unsupported by HyperHDR 'YUV9' DMA format
PipewireEGL: Found unsupported by HyperHDR 'YU11' DMA format
PipewireEGL: Found unsupported by HyperHDR 'YU12' DMA format
PipewireEGL: Found unsupported by HyperHDR 'YU16' DMA format
PipewireEGL: Found unsupported by HyperHDR 'YU24' DMA format
PipewireEGL: Found unsupported by HyperHDR 'YVU9' DMA format
PipewireEGL: Found unsupported by HyperHDR 'YV11' DMA format
PipewireEGL: Found unsupported by HyperHDR 'YV12' DMA format
PipewireEGL: Found unsupported by HyperHDR 'YV16' DMA format
PipewireEGL: Found unsupported by HyperHDR 'YV24' DMA format
PipewireEGL: Found unsupported by HyperHDR 'NV12' DMA format
PipewireEGL: Found unsupported by HyperHDR 'P010' DMA format
PipewireEGL: Found unsupported by HyperHDR 'P012' DMA format
PipewireEGL: Found unsupported by HyperHDR 'P016' DMA format
PipewireEGL: Found unsupported by HyperHDR 'P030' DMA format
PipewireEGL: Found unsupported by HyperHDR 'NV16' DMA format
PipewireEGL: Found unsupported by HyperHDR 'AYUV' DMA format
PipewireEGL: Found unsupported by HyperHDR 'XYUV' DMA format
PipewireEGL: Found unsupported by HyperHDR 'Y410' DMA format
PipewireEGL: Found unsupported by HyperHDR 'Y412' DMA format
PipewireEGL: Found unsupported by HyperHDR 'Y416' DMA format
PipewireEGL: Found unsupported by HyperHDR 'YUYV' DMA format
PipewireEGL: Found unsupported by HyperHDR 'UYVY' DMA format
PipewireEGL: Found unsupported by HyperHDR 'Y210' DMA format
PipewireEGL: Found unsupported by HyperHDR 'Y212' DMA format
PipewireEGL: Found unsupported by HyperHDR 'Y216' DMA format
Pipewire: state CONNECTING (1, 0)
Pipewire: the stream is connected
Pipewire: core info reported. Version = 1.1.0
Pipewire: state PAUSED (2, 1)
Pipewire: got new video format selected
Pipewire: got new video format selected
Pipewire: got new video format selected
Pipewire: video format = 8 (Spa:Enum:VideoFormat:BGRx)
Pipewire: video size = 3840x2160 (RGB order = false)
Pipewire: framerate = 0/1
Pipewire: DMA buffer available. Format: XR24. Modifier: ???U.
Pipewire: MemFD buffer available
Pipewire: MemPTR buffer available
Pipewire: updated parameters 0
Pipewire: got new video format selected
Pipewire: video format = 8 (Spa:Enum:VideoFormat:BGRx)
Pipewire: video size = 3840x2160 (RGB order = false)
Pipewire: framerate = 0/1
Pipewire: DMA buffer available. Format: XR24. Modifier: ????.
Pipewire: MemFD buffer available
Pipewire: MemPTR buffer available
Pipewire: updated parameters 0

It seems that also BGRx is used here.

[awawa-dev]

I tested prebuild v20beta1 on Ubuntu 24.04, it has pipewire 1.0.0. I do not receive the error you described, but DMA also is not reported by Pipewire (EGL is detected correctly), maybe I'm missing something eg. Intel drivers version free or non-free? I have 12th gen Intel. How did you enable Pipewire logging?

[Mic92]

I am using the mesa driver (v23.1.9). I am not enabling specific pipewire logging option (no configuration in /etc at all). Pipewire runs as a systemd user-space service here: journalctl --user -u pipewire -n 1000 -f

The same could be probably reproduced by stopping the pipewire process and starting it in a terminal.

[awawa-dev]

No changes, I cannot lead to a similar situation as yours

I think I have everything I need installed. Pipewire does not offer DMA for this graphics mode using rather the latest drivers for Intel 12th.

There may be another explanation: the development version of Pipewire leads to contradictions and the apparent presence of DMA mode at an early stage, but when trying to actually acquire it via dialogue it results in an error. If the number of plans (1) does not match, it may simply mean that there is a DMA mode for YUV modes available somewhere (usually 2 or 3), but it is not useful here and we did not even ask for it.

Even though you removed this parameter, do DMA-Buffers actually work? I have a request for a full console log of HyperHDR before and after the patch, because I cannot repeat it in my environment/hardware and I think I have exhausted all possibilities.

[Mic92]

$ ./bin/hyperhdr >/tmp/log.txt 2>&1

Logs in less are best watched with less -r log.txt because of ansi colors

Before:

• log.txt
• curl -L https://github.com/awawa-dev/HyperHDR/files/13884657/log.txt | less -r

After:

• log.txt
• curl -L https://github.com/awawa-dev/HyperHDR/files/13884644/log.txt | less -r

And again the full pipewire log (the only interesting event is the error generated by the first command):
pipewire.txt

[Mic92]

I can potentially also ask someone with an 12 Gen Intel CPU to run hyperhdr on same OS as me.

[Mic92]

If the parameter is not passed, does it break hyperhdr? For me everything seems to work fine. I can see my screen in the webinterface and the ambient lights work.

[awawa-dev]

We cannot remove it: if we do not use hardware acceleration, we assume that BGRx/RGBx is in a uniform contiguous address space and this condition takes care of it. Without it, memory would be compromised while processing in HyperHDR. With DMA buffers, however, this does not have to be the rule and, as you can see, EGL can deal with it. In fact, other parameters: 'size', 'stride' or 'align' are not needed for EGL, but it's a bit too late for such experiments before a stable release. I will come back to this in the future, but for now I remove 'blocks' if DMA is detected. Verifying the pipewire version does not seem necessary because the described effect was caused by the specific behavior of graphics drivers. I would like to ask you to check if it works for you.

BTW what DM and compositor do you use in X?

[Mic92]

KDE/Wayland

[awawa-dev]

Ok, I've got it. On KDE (kubuntu 24.04), hardware acceleration works immediately on Intel and you don't need to do anything else. I managed to get the same problem as you and this PR fixes the issue. If it works for you too, I think we can merge PR.

So KUbuntu with KDE wins here for Intel, on the other hand Ubuntu has also implemented Pipewire protocols for x11 (on KUbuntu/x11 it wont start capturing session).

[Mic92]

Works here.

[awawa-dev]

Great! Just one more minor correction because Valgrind found jump depends on uninitialised value in spa_video_info and merging.