hakurei/internal/pipewire/testdata, branch developlow-level userspace tooling for Rosa OShttp://src.rosa.moe/hakurei/atom/internal/pipewire/testdata?h=develop2025-11-27T15:35:10Zinternal/pipewire: store sample iovec continuously2025-11-27T15:35:10ZOphestracat@gensokyo.uk2025-11-27T15:34:32Zurn:sha1:72a2601d7461c0e2e24a3f97f19392dc30ee4c68
This removes the need for manual splitting. The understanding of the format is robust enough to allow this to happen anyway.
Signed-off-by: Ophestra <cat@gensokyo.uk>
internal/pipewire: shorten test data filenames2025-11-27T11:06:01ZOphestracat@gensokyo.uk2025-11-27T11:06:01Zurn:sha1:2bafde99e352ffec2e35a1e45aaf6c26bf864485
These were getting very annoying to type.
Signed-off-by: Ophestra <cat@gensokyo.uk>
internal/pipewire: implement Core::Done2025-11-26T10:02:21ZOphestracat@gensokyo.uk2025-11-26T10:02:21Zurn:sha1:2698ca00e8fad5f7243c1e1b4c078d322854917c
The message in the sample does not correspond to any known method call. The spec does not mention what to do with messages like this, but all existing usage code simply drops it.
Signed-off-by: Ophestra <cat@gensokyo.uk>
internal/pipewire: additional Client::Info test case2025-11-26T07:28:57ZOphestracat@gensokyo.uk2025-11-26T07:27:46Zurn:sha1:a55c209099c96101288350043817c5dc50fdb158
This appears to add *one single entry* compared to the message before it. The inefficiency of this protocol is beyond imagination.
Signed-off-by: Ophestra <cat@gensokyo.uk>
internal/pipewire: additional Client::Info test case2025-11-26T07:17:38ZOphestracat@gensokyo.uk2025-11-26T07:17:38Zurn:sha1:10ff276da187868be1fa136ffd41ee2904c2cea8
This message follows the other Client::Info event before it. No idea why.
Signed-off-by: Ophestra <cat@gensokyo.uk>
internal/pipewire: implement Client::Info2025-11-26T07:05:46ZOphestracat@gensokyo.uk2025-11-26T07:05:46Zurn:sha1:fd4d379b6777168c3251c85d153dbdf6b82f2b35
Everything is already supported, as usual.
Signed-off-by: Ophestra <cat@gensokyo.uk>
internal/pipewire: implement Core::BoundProps2025-11-25T09:40:19ZOphestracat@gensokyo.uk2025-11-25T09:37:50Zurn:sha1:77f5b89a4180600179d4f0d1683b063b43372811
Very straightforward type, everything is already supported.
Signed-off-by: Ophestra <cat@gensokyo.uk>
internal/pipewire: implement Core::Info and generation footer2025-11-25T06:16:12ZOphestracat@gensokyo.uk2025-11-25T06:15:20Zurn:sha1:cfeb7818eb3d7f3e83492bab092adce8f90f83c1
These are not directly related but are first encountered on the same message in the capture.
Signed-off-by: Ophestra <cat@gensokyo.uk>
internal/pipewire: implement Core::Sync2025-11-24T23:52:06ZOphestracat@gensokyo.uk2025-11-24T23:52:06Zurn:sha1:fc3d78fe010f9e3c22a058723bf816570553c0da
Once again, already entirely supported, the offset is not yet fully verified but makes intuitive sense. Will verify this on future occurrences of the message.
Signed-off-by: Ophestra <cat@gensokyo.uk>
internal/pipewire: implement Core::GetRegistry2025-11-24T23:34:19ZOphestracat@gensokyo.uk2025-11-24T23:34:19Zurn:sha1:591637264a76771d36531a3e51e7db40ef853421
This struct is entirely supported, so this change is very straightforward.
Signed-off-by: Ophestra <cat@gensokyo.uk>