| Age | Commit message (Collapse) | Author |
|---|
|
This avoids timing out on systems running very slowly.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
This package solves a very specific stubbing use case, in a less than elegant manner.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
The interface does not expose underlying kernel notification mechanisms. This change removes the need to poll in situations were the next call might block.
This is made cumbersome by the SyscallConn interface left over from a previous implementation, it will be replaced in a later commit as the current implementation does not make use of any net.Conn methods other than Close.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
This method can result in an error targeting it, so it is handled here. This change also causes a call to Create to also Core::Sync, as it should have done.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
This change also implements pending destructible check on Sync. Destruction method should always be implemented as a wrapper of destructible.destroy.
Signed-off-by: Ophestra <cat@gensokyo.uk>
|
|
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>
|
