muvm-guest: pwbridge: actually read fd indexes in the Transport msg [fix pipewire on x86_64]#204
Merged
slp merged 1 commit intoAsahiLinux:mainfrom Dec 2, 2025
Merged
Conversation
Collaborator
|
I've just gave this a try on Fedora Asahi 43, and I can confirm works fine as-is, without this PR. I think we need to know why is actually switching places... |
Contributor
Author
spa_pod_builder_add_struct(b,
SPA_POD_Fd(pw_protocol_native_add_resource_fd(resource, readfd)),
SPA_POD_Fd(pw_protocol_native_add_resource_fd(resource, writefd)),
SPA_POD_Int(mem_id),
SPA_POD_Int(offset),
SPA_POD_Int(size));The order of evaluation of call args in C is unspecified, so it just happens to have the opposite order between targets and/or compilers. The protocol does not rely on it, they can be added in any order, the index is returned and written into the struct. |
valpackett
force-pushed
the
val/kwootowwltmt
branch
from
78e912a to
5b0481a
Compare
valpackett
changed the title
valpackett
requested review from
WhatAmISupposedToPutHere,
alyssarosenzweig,
slp and
teohhanhui
as code owners
valpackett
force-pushed
the
val/kwootowwltmt
branch
from
5b0481a to
91a459c
Compare
Contributor
Author
|
Added actual message parsing now \o/ This should work everywhere. |
WhatAmISupposedToPutHere
requested changes
Nov 20, 2025
valpackett
force-pushed
the
val/kwootowwltmt
branch
from
91a459c to
eff8aa6
Compare
The message payload contains indexes for the attached file descriptors. We must use them instead of relying on the order, which was never guaranteed, and *actually* differs in practice between architectures in compilers because current PipeWire code calls the fd-attaching function inside of function call arguments, which *don't* have a defined evaluation order in the C language standard. Signed-off-by: Val Packett <val@invisiblethingslab.com>
valpackett
force-pushed
the
val/kwootowwltmt
branch
from
eff8aa6 to
e5b8416
Compare
Contributor
Author
|
friendly ping for another (hopefully final) review :) |
WhatAmISupposedToPutHere
approved these changes
Nov 28, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Looks like at some point, PipeWire swapped around the order of the attached fds, so audio playback has been broken here. As a hotfix, follow the change. [..]The message payload contains indexes for the attached file descriptors.
We must use them instead of relying on the order, which was never guaranteed,
and actually differs in practice between architectures in compilers
because current PipeWire code calls the fd-attaching function inside of
function call arguments, which don't have a defined evaluation order
in the C language standard.