| Age | Commit message (Collapse) | Author |
|---|
|
This handles the error returned by Sync.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
This is emitted by PipeWire when a global object disappears, because PipeWire insists that all clients that had called Core::GetRegistry must constantly sync its local registry state with the remote.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
This improves readability as the offset is not immediately obvious.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
There is currently no known message that will get the PipeWire server to emit this event. It should be handled regardless.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
The PipeWire protocol does not work with Go abstractions. This change makes relevant methods call sendmsg/recvmsg directly.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
These are PipeWire spa_dict keys. Interestingly many keys in the sample are undefined and appear as magic strings in upstream source code.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
This should make things easier to navigate, and possible to fully automatically generate the constants in the future.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
These errors are recoverable and should not terminate event handling. Only terminate event handling for protocol errors or inconsistent state that makes further event handling impossible.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
This consumes the entire sample, is validated to send identical messages and correctly handle received messages.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
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>
|
|
These were getting very annoying to type.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
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>
|
|
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>
|
|
This message follows the other Client::Info event before it. No idea why.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
Everything is already supported, as usual.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
Very straightforward type, everything is already supported.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
These are not directly related but are first encountered on the same message in the capture.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
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>
|
|
This struct is entirely supported, so this change is very straightforward.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
These get very big later on, and would be painful to represent as the compound literal.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
