Allow to select both main type of ScreenCast (monitor, window)
with only one source type rather than adding a source type per
ScreenCast type.
This change is made as a new Screen Capture source type which
obsoletes the use of the previous Screen Capture (monitor-only)
and Window Capture.
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.
The D-Bus signal subscription is a very boring aspect of the
portals infrastructure that shouldn't really matter when reading
the code of pipewire.c.
Move it out to its natural place, portal.c.
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.
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.
When the linux-pipewire plugin is unloaded, make sure to cleanup
the D-Bus proxy for the ScreenCast portal too. This effectively
doesn't change anything, but it's always good to keep up with the
code hygiene.
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.
As we slowly split portal code from PipeWire code, what is currently
called pipewire-capture will become the screencast portal specific
code.
Preemptively rename the corresponding files and functions. Next commits
will continue the excision of portal code from pipewire.c.
