This will allow consumers of obs_pipewire to handle the device
registry themselves. This is not useful for the screencast code
since there's always only one node in the registry, but it will
be used by the camera and audio code to list hardware devices.
This commit adds the screencast-specific 'cursor_visible' field
in an anonymous struct within the constructor struct.
This slightly improves the connection code by properly treating
construction-time information in a constructor struct. It allows
removing the extra function call that sets cursor visibility from
the Screencast portal code.
Admittedly that's not much, but again, this will be an important
distinction when introducing the Camera portal code, since some
camera properties will need to trigger renegotiation.
So that we can expand the number of construct-time connection
properties without changing the function signature every time.
This is mostly an ergonomic change for now, but it'll be very
useful when introducing the Camera portal code.
Sorry, this is a painful commit to review :(
Until now, the only consumer of the PipeWire code is the screen
cast portal code. This portal code only ever has one PipeWire
connection, and one PipeWire stream, every time a monitor or a
window is selected. This is reflected on obs_pipewire, which only
handles a single stream for any given connection.
For cameras and audio, however, a single PipeWire connection can
and most likely always will provide multiple streams. For example,
computers with multiple webcams will have one PipeWire connection
reporting multiple PipeWire nodes, one node for each camera.
This commit breaks this one-stream-per-connection assumption, and
makes obs_pipewire_connect_stream() return an independent object
(obs_pipewire_stream) that represents a single stream.
The screencast portal code continues to only ever have one connection
and one stream.
A trivial cosmetic change. This groups the constructor and
destructor together. Two sides of the same coin, yin and yang,
bound by their nature, and linked by their position in code.
This commit introduces an important distinction in the initialization
process that is essential to future camera and audio work: it splits
creating and connecting to the PipeWire socket, from connecting to
specific PipeWire nodes.
Right now, for the only consumer in existence - the ScreenCast portal
code - this distinction is irrelevant, but from an API perspective it
just makes sense to model it this way.
And let each portal pass the stream properties relevant to them.
This makes the pipewire.c more independent of the actual portal
by providing a wrapper to create a stream. This will be relevant
later, when linux-pipewire introduces more portals like the Camera
one.
Sorry this is such a massive commit. The entangled nature of the
code in pipewire.c makes it impossible to reasonably split this
in smaller commits.
Move all D-Bus / portals code from pipewire.c into the recently
introduced screencast-portal.c.
This is very much like previous commit, but there's a catch: there
already was an enumeration in place, which is replaced in this
commit. The obs_pw_capture_type enum was introduced before splitting
the portal code into a separate file, and the enum itself is specific
to the screencast portal, so the appropriate place to enumerate it
is in portal.h.
For completude, PORTAL_CAPTURE_TYPE_VIRTUAL was added to the enum,
even though we never used, and probably never will.
The values are still the same, since both the old and this new enum
were extracted from the screencast portal [1].
https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.portal.ScreenCast.xml#L290-300
