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.
We use a size_t that can be 64bit while EGL uses 32bit for the
underlying value. Writes from our graphics function can leave high bits
uninitialized and cause iteration of the format list to overlfow.
fixes#9844
We were passing the core pipewire pointer where renegotiation expected
the stream pointer. Somehow this worked, probably because the two are
very close.
fixes#9733
After the cmake 3.0 rebuild glad was transitioned to a static library.
This lead to the glad symbols being uninitialized and crashes when they
are used in some cases.
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.
Cameras and audio streams will use the async output routines, but
not screencasting. This needs to be handled differently in the
processing callback.
As it is, the code is starting to get a bit messy, as we're now
dealing with two different frame processing approaches. Later on,
this code will be cleaned up and split in more logical pieces.
Co-authored-by: Georges Basile Stavracas Neto
<georges.stavracas@gmail.com>
So far we've been treating format info on a per-connection basis,
but now that a single connection is capable of hosting multiple
streams, and each stream might negotiate a different format, it
is necessary to move format info to each stream individually.
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.
PipeWire supports 10bit colour formats with little endian order.
Adding two new formats required increasing the buffer size for building
PipeWire buffers.
This formats are supported since PipeWire 0.3.41. To allow building
against
older PipeWire versions we will hide those formats. Complications when
running on a host with an older PipeWire version are not expected, since
format negotiation is only done via the numerical values.
Compositors did not agree on how to communicate invalid buffers until
recently, so e0a4d8628d resulted in
regressions on KDE. This restores our old behavior which is too
conservative but mostly works on old and new compositors (which contain
similar workarounds to pass in invalid but non-zero sizes for dma-bufs).
Once all old compositors are out of use we can remove this workaround
and then compositors can remove their random size workaround.
Pipewire desktop portal capture assumes premultiplied alpha, so make
sure to use the right blend equation to make translucent pixels work
correctly.
This is still broken for emissive pixels (alpha < color) since OBS seems
to unpremultiply at some point during blending, but it works properly
for translucent pixels (emissive pixel support requires an end-to-end
premultiplied pipeline).
