8 Commits

Author SHA1 Message Date
Georges Basile Stavracas Neto
3d7663f417 linux-pipewire: Explicitly enumerate portal capture types
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
2022-04-09 16:45:02 -07:00
Georges Basile Stavracas Neto
e7815dff66 linux-pipewire: Explicitly enumerate cursor modes
The ScreenCast portal defines 3 cursor modes [1]:

 * Hidden: no visible cursor (value: 1)
 * Embedded: cursor is drawn in the frames (value: 2)
 * Metadata: cursor is sent as stream metadata (value: 4)

The values are power-of-two due to be used as flags.

Explicitly listing these values in an enum improves legibility
of the code, so do that instead of hardcoding 1, 2, and 4.

[1] https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.portal.ScreenCast.xml#L302-L316
2022-04-09 16:45:02 -07:00
Georges Basile Stavracas Neto
1267081e5c linux-pipewire: Move fetching cursor mode to portal.c
The portal.c file was introduced after the PipeWire code landed, and
handles acquiring a D-Bus connection to the portal interface, and also
has helpers to get properties from portals. The available cursor modes
property fits nicely in portal.c.

Move fetching the cursor mode to portal.c.
2022-04-09 16:45:02 -07:00
Georges Basile Stavracas Neto
2534e549f9 linux-pipewire: Remove ellipses from log messages
Ellipses in log messages bring a tone of vagueness and insecurity
that does not match the geist of the OBS Studio community. We're
a bold, industry-leading community producing software that is at
the heart of the biggest services of today's world. When it comes
to PipeWire and Wayland adoption, we're quite literally the app
that protocols and portals are designed for.

Therefore, it is unacceptable that the log messages in the PipeWire
capture don't communicate how strong of a community we are. Not
only that, these ellipses bring harm on the long run. After all,
who on their right mind would design protocols, portals, and user
interactions for an app that doesn't even log their messages in
accordance to its community values?

Our logs must shout strength. They must reflect that OBS Studio
is here to stay. Readers of such logs must fasten their seatbelts
before opening these files. Competition tremble with dread and
fear when presented with these logs. Only extreme metal singers
should be able to read these logs out loud.

No compromise.

Remove ellipses from PipeWire log messages.
2022-04-09 16:45:02 -07:00
Georges Basile Stavracas Neto
25fe22a489 linux-pipewire: Properly capitalize log messages
They are inconsistently capitalized, some with sentence capitalization,
some completely lower-cased.

Capitalize all log messages using sentence capitalization.
2022-04-09 16:45:02 -07:00
Georges Basile Stavracas Neto
6216f4555b linux-pipewire: Log more PipeWire-related info
The information that we currently log is not enough to give proper
support, and at best allows us to know that the first few steps of
negotiation worked.

Transform a few key debug messages into infos.
2022-04-09 16:45:02 -07:00
Joshua Ashton
9903d73f36 linux-capture: Don't initialize format info if init_obs_pipewire fails
The pointer has been freed by this point so it just segfaults.

Signed-off-by: Joshua Ashton <joshua@froggi.es>
2022-04-07 08:41:19 -03:00
Georges Basile Stavracas Neto
a147315f33 project: Migrate PipeWire capture into linux-pipewire
The capture ids are preserved, so that it's compatible with the
previous code. No code changes were necessary whatsoever.
2022-03-20 20:53:39 -03:00