Make PipeWire stream shared through DesktopCaptureOptions (similar to
X11 implementation sharing XDisplay) so we can implement better cursor
support with our own MouseCursorMonitor implementation.
Bug: webrtc:13429
Change-Id: I781482aa29cee0c105c42e5109f28e95dde9881b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238174
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35765}
When screencast session is closed, there won't be any other stream we
can reconnect to and in that case we are supposed to disconnect our
stream to prevent accidentally connecting to any other stream in case it
gets assigned same node ID from PipeWire
Bug: webrtc:13429
Change-Id: Iec8e93a108c789c32cb93e1460e693fabc247491
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/241086
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35728}
Updates all webrtc code, to have a small followup cl to just add the
"explicit" keyword. Patchset #24 passed all webrtc tests, with explicit.
Bug: webrtc:13464
Change-Id: I39863d3752f73209b531120f66916dc9177bf63a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242363
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35718}
We need to check the PipeWire server version in order to be sure we can
advertise DMA-BUF support, because it doesn't mean the version of
PipeWire we built our code against will run against the same PipeWire
version. Also do not announce DMA-BUF support for PipeWire older than
0.3.24 as this will not be working. For DMA-BUF modifiers support we
need the PipeWire version to be at least 0.3.33 on both sides (client
and server). Last but not least minor fix is not to announce
modifier-less DMA-BUF support when we don't have required extension.
Bug: chromium:1233417
Change-Id: If2a0a2328b893ccbeab61cb4039029b8a113a1ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246440
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35699}
This reverts commit e51937dfc5567b6ce53bd1211799dbdaff8b268e.
Reason for revert: This change was not intended to land yet.
Original change's description:
> PipeWire capturer: advertise DMA-BUF support when really supported
>
> We need to check the PipeWire server version in order to be sure we can
> advertise DMA-BUF support, because it doesn't mean the version of
> PipeWire we built our code against will run against the same PipeWire
> version. Also do not announce DMA-BUF support for PipeWire older than
> 0.3.24 as this will not be working. For DMA-BUF modifiers support we
> need the PipeWire version to be at least 0.3.33 on both sides (client
> and server). Last but not least minor fix is not to announce
> modifier-less DMA-BUF support when we don't have required extension.
>
> Bug: chromium:1233417
> Change-Id: Iee035d61bbc9d5878621555c365751ee4edc9d28
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239649
> Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> Commit-Queue: Jan Grulich <grulja@gmail.com>
> Cr-Commit-Position: refs/heads/main@{#35696}
TBR=tommi@webrtc.org,jansson@google.com,sprang@chromium.org,grulja@gmail.com,mfoltz@chromium.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I2aff8ca2650aa14932c0bd15bdc4f30f406f91de
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1233417
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246401
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Owners-Override: Christoffer Jansson <jansson@google.com>
Commit-Queue: Christoffer Jansson <jansson@google.com>
Cr-Commit-Position: refs/heads/main@{#35697}
We need to check the PipeWire server version in order to be sure we can
advertise DMA-BUF support, because it doesn't mean the version of
PipeWire we built our code against will run against the same PipeWire
version. Also do not announce DMA-BUF support for PipeWire older than
0.3.24 as this will not be working. For DMA-BUF modifiers support we
need the PipeWire version to be at least 0.3.33 on both sides (client
and server). Last but not least minor fix is not to announce
modifier-less DMA-BUF support when we don't have required extension.
Bug: chromium:1233417
Change-Id: Iee035d61bbc9d5878621555c365751ee4edc9d28
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239649
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#35696}
A version of WebRTC with the forward header is now present and it
will simplify the migration to the new header.
Bug: webrtc:13429
Change-Id: I14da7a9106e97f826d8ff3874a12ff66f03235e0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/241202
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35536}
This reverts commit 3a285224b62b04fc84ce027b0306bcf9ef26041f.
Reason for revert: Still breaking downstream projects due to not using forward headers. I will talk to Mark separately about the usage.
Original change's description:
> Reland "Linux capturers: organize X11 and Wayland implementations into separate folders"
>
> Bug: webrtc:13429
> Change-Id: I6e88de4f7ebcb64076312d83ac2c79db24f85ad8
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239841
> Commit-Queue: Mark Foltz <mfoltz@chromium.org>
> Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#35481}
TBR=grulja@gmail.com,mfoltz@chromium.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I1f75e3d89495f2a9a31d0f4406a3efdf0d95f74a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:13429
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/240064
Owners-Override: Christoffer Jansson <jansson@google.com>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Christoffer Jansson <jansson@google.com>
Cr-Commit-Position: refs/heads/main@{#35484}
This reverts commit 998e9bd5c55de253106b697af691169853a4e91f.
Reason for revert: Breaks downstream projects because some headers
have been renamed without providing a forward header for backwards
compatibility.
Original change's description:
> Linux capturers: organize X11 and Wayland implementations into separate folders
>
> Bug: webrtc:13429
> Change-Id: I2db727797c2ca2bd85937ff732ce3f68bb45469a
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238173
> Reviewed-by: Mark Foltz <mfoltz@chromium.org>
> Commit-Queue: Mark Foltz <mfoltz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#35471}
TBR=tommi@webrtc.org,sprang@chromium.org,mfoltz@chromium.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com,grulja@gmail.com
Change-Id: I2aadfeb30151fcbe1a8c05e856be989d60bb10a3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:13429
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239821
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#35472}
Add implementation of RTC_DCHECK_NOTREACHED equal to the RTC_NOTREACHED.
The new macros will replace the old one when old one's usage will be
removed. The idea of the renaming to provide a clear signal that this
is debug build only macros and will be stripped in the production build.
Bug: webrtc:9065
Change-Id: I4c35d8b03e74a4b3fd1ae75dba2f9c05643101db
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237802
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35348}
UpdateMonitors() crops the selected RANDR monitor to the root window,
in case X returns a monitor that lies outside it. But it wasn't enough.
SelectSource() alters the selection directly and doesn't call
UpdateMonitors(), so it also needs to crop. This fixes the case
where a virtual monitor is added, the screen resolution is reduced,
then the new monitor is selected (which now extends outside the reduced
screen size).
This CL also fixes an issue where the ScreenCapturerHelper would
sometimes expand a damage-region outside the DesktopFrame boundary.
This occurred because the helper's size was set to the full
pixel-buffer, so it didn't crop correctly to the monitor's rect.
This CL sets the helper's correct size, and removes some unnecessary
cropping now that the helper will do it correctly.
Bug: chromium:1266179
Change-Id: I8eb8f3302701be4f393934c0899f41def3512853
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237120
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35304}
We need to use RTC_NOT_SANITIZE("cfi-icall") everywhere where we do
function typecasting, otherwise doing official Chrome builds will result
into crash.
Bug: chromium:1262535
Change-Id: If7358ccab6bd626e494b7ecd3077aa29502080c1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236587
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35281}
This avoids an additional step where we originally copied content from
PipeWire buffer to a temporary location and from there to DesktopFrame.
This results into less copy operations and hopefully to faster
screensharing.
I didn't do some exact measures, but simply running htop while sharing a
4k screen I can see following results (usage per top 5 processes):
1) Without this change - 66%, 64%, 26% 23%, 10%
2) With this change - 41%, 39%, 19%, 17%, 12%,
Bug: webrtc:13239
Change-Id: I6a661ecc96bfeef370c1a5a3b9dc5e3c0fc665c8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231684
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35156}
This is a reland of f2177f6612079ccce9c320ea7e77bc934c684f5c
Original change's description:
> PipeWire capturer: implement proper DMA-BUFs support
>
> Currently both KWin (KDE) and Mutter (GNOME) window managers don't
> use DMA-BUFs by default, but only when client asks specifically for
> them (KWin) or when experimental DMA-BUF support is enabled (Mutter).
> While current implementation works just fine on integrated graphics
> cards, it causes issues on dedicated GPUs (AMD and NVidia) where the
> code either crashes or screensharing is slow and unusable.
>
> To fix this, DMA-BUFs has to be opened using OpenGL context and not
> being directly mmaped(). This implementation requires to use DMA-BUF
> modifiers, as they are now mandatory for DMA-BUFs usage.
>
> Documentation for this behavior can be found here:
> https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/doc/dma-buf.dox
>
> Bug: chromium:1233417
> Change-Id: I0cecf16d6bb0f576954b9e8f071cab526f7baf2c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227022
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#34889}
Bug: chromium:1233417
Change-Id: I308501d86ec18ab6df9bcee569c4b72df7926549
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231180
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35152}
This CL ensures that each DesktopFrame's updated-region is expressed in
the frame's own coordinates, where the top-left is always (0, 0).
For example, DesktopFrame::GetFrameDataAtPos() and its callers use
this coordinate system.
Previously, whenever a RANDR monitor with a non-zero offset was
selected, ScreenCapturerX11 would hit some DCHECKs when trying to
copy pixels from previous frames, or when capturing new pixels into
them from XDAMAGE regions.
Bug: None
Change-Id: I7b2e8d0449359ee7b263ad60af193e2bf89aa1f4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232085
Reviewed-by: Joe Downing <joedow@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35017}
The documentation for `OpenPipeWireRemote()` says:
> Open a file descriptor to the PipeWire remote where the camera nodes
> are available. The file descriptor should be used to create a
> pw_core object, by using pw_context_connect_fd.
In `InitPipeWire()` we already successfully requested the FD, but then
went on and used the unrestricted default socket.
This does not matter in non-sandboxed environments, as the stream we
want to use is available from both FDs. In flatpak sandboxes, however,
this requires to give full Pipewire access to the application.
Fix this by simply using the right, restricted FD, and while on it,
also make sure to not leak it.
This change has already landed in downstream in Firefox, see
https://phabricator.services.mozilla.com/D122904https://phabricator.services.mozilla.com/D124508
Bug: webrtc:13152
Change-Id: I3f8995c54c797e1a90a980f231e496a13cbe65b4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230803
Reviewed-by: Joe Downing <joedow@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#34983}
According to the RANDR 1.5 spec:
https://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt
RRSetMonitor and RRDeleteMonitor requests will generate a
ConfigureNotify event on the root window of the screen.
They do not appear to generate any RRScreenChangeNotify or other
similar event. So this CL causes ScreenCapturerX11's monitor list to be
updated on ConfigureNotify events. It is needed, for example, when
using a commandline such as "xrandr --setmonitor ..." to add monitors.
Bug: None
Change-Id: I1948a8b96800721409472ac6264c935abe169ec3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230882
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#34919}
This reverts commit 677195d3eb6a5f0bc1d31d794a5190ba281c0335.
Reason for revert: Broke WebRTC to Chrome rolls:
https://crrev.com/c/3141000
example: https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/790256/overview
The error is similar to the failure on previous attempt to land this CL. See: https://crrev.com/c/3135220, and crash https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/787945/overview
Original change's description:
> Reland "PipeWire capturer: implement proper DMA-BUFs support""
>
> This is a reland of f2177f6612079ccce9c320ea7e77bc934c684f5c
>
> Original change's description:
> > PipeWire capturer: implement proper DMA-BUFs support
> >
> > Currently both KWin (KDE) and Mutter (GNOME) window managers don't
> > use DMA-BUFs by default, but only when client asks specifically for
> > them (KWin) or when experimental DMA-BUF support is enabled (Mutter).
> > While current implementation works just fine on integrated graphics
> > cards, it causes issues on dedicated GPUs (AMD and NVidia) where the
> > code either crashes or screensharing is slow and unusable.
> >
> > To fix this, DMA-BUFs has to be opened using OpenGL context and not
> > being directly mmaped(). This implementation requires to use DMA-BUF
> > modifiers, as they are now mandatory for DMA-BUFs usage.
> >
> > Documentation for this behavior can be found here:
> > https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/doc/dma-buf.dox
> >
> > Bug: chromium:1233417, webrtc:13137
> > Change-Id: I0cecf16d6bb0f576954b9e8f071cab526f7baf2c
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227022
> > Commit-Queue: Tommi <tommi@webrtc.org>
> > Reviewed-by: Tommi <tommi@webrtc.org>
> > Reviewed-by: Erik Språng <sprang@webrtc.org>
> > Cr-Commit-Position: refs/heads/main@{#34889}
>
> Bug: chromium:1233417, webrtc:13137
> Change-Id: I7d5763dd5db708cee20a31e559b26db0287f40d6
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230946
> Reviewed-by: Tommi <tommi@webrtc.org>
> Commit-Queue: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#34903}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1233417, webrtc:13137
Change-Id: I64e2ce864f69e6097aba65ade04af7166e407409
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231135
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34915}
The desktop capturer uses a circular queue (currently of length 2) to
implement a double-buffer scheme. This allows a C++ API consumer to keep
a reference to the latest captured image without the pixels being
overwritten by a pending capture request.
The DCHECK was intended to warn that the application is still holding a
reference to a recycled frame that is being captured into. This made
sense when the capturer implementations were originally part of the
Chromoting host process. Now that the capturers are part of the WebRTC
C++ library, a DCHECK seems too harsh. A DCHECK should be reserved for
impossible conditions, but this one triggers simply because an API
consumer holds onto a reference for too long. This CL changes these
DCHECKs into log warnings.
The DCHECK is sometimes triggered by the Chromoting host process
(because of the recent change to use the standard encoding pipeline).
This is tracked by http://crbug.com/1239746.
Bug: None
Change-Id: Iad9ef38b4800315bd17c93b27d287e115d4fe54c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230881
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#34910}
This is a reland of f2177f6612079ccce9c320ea7e77bc934c684f5c
Original change's description:
> PipeWire capturer: implement proper DMA-BUFs support
>
> Currently both KWin (KDE) and Mutter (GNOME) window managers don't
> use DMA-BUFs by default, but only when client asks specifically for
> them (KWin) or when experimental DMA-BUF support is enabled (Mutter).
> While current implementation works just fine on integrated graphics
> cards, it causes issues on dedicated GPUs (AMD and NVidia) where the
> code either crashes or screensharing is slow and unusable.
>
> To fix this, DMA-BUFs has to be opened using OpenGL context and not
> being directly mmaped(). This implementation requires to use DMA-BUF
> modifiers, as they are now mandatory for DMA-BUFs usage.
>
> Documentation for this behavior can be found here:
> https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/doc/dma-buf.dox
>
> Bug: chromium:1233417, webrtc:13137
> Change-Id: I0cecf16d6bb0f576954b9e8f071cab526f7baf2c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227022
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#34889}
Bug: chromium:1233417, webrtc:13137
Change-Id: I7d5763dd5db708cee20a31e559b26db0287f40d6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230946
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34903}
This reverts commit f2177f6612079ccce9c320ea7e77bc934c684f5c.
Reason for revert: Broke WebRTC to Chrome rolls:
https://chromium-review.googlesource.com/c/chromium/src/+/3135220
example: https://ci.chromium.org/ui/p/chromium/builders/try/fuchsia-x64-cast/431230/overview
ERROR at //third_party/webrtc/modules/desktop_capture/linux/egl_dmabuf.cc:26:11: Include not allowed.
#include "rtc_base/sanitizer.h"
^-------------------
It is not in any dependency of
//third_party/webrtc/modules/desktop_capture:desktop_capture_generic
The include file is in the target(s):
//third_party/webrtc/rtc_base:sanitizer
which should somehow be reachable.
Original change's description:
> PipeWire capturer: implement proper DMA-BUFs support
>
> Currently both KWin (KDE) and Mutter (GNOME) window managers don't
> use DMA-BUFs by default, but only when client asks specifically for
> them (KWin) or when experimental DMA-BUF support is enabled (Mutter).
> While current implementation works just fine on integrated graphics
> cards, it causes issues on dedicated GPUs (AMD and NVidia) where the
> code either crashes or screensharing is slow and unusable.
>
> To fix this, DMA-BUFs has to be opened using OpenGL context and not
> being directly mmaped(). This implementation requires to use DMA-BUF
> modifiers, as they are now mandatory for DMA-BUFs usage.
>
> Documentation for this behavior can be found here:
> https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/doc/dma-buf.dox
>
> Bug: chromium:1233417, webrtc:13137
> Change-Id: I0cecf16d6bb0f576954b9e8f071cab526f7baf2c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227022
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#34889}
TBR=mbonadei@webrtc.org,tommi@webrtc.org,sprang@webrtc.org,mfoltz@chromium.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com,grulja@gmail.com
Change-Id: I2c573f17adbb216156cd72f62f4dbb7328f8fb6a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1233417, webrtc:13137
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230944
Reviewed-by: Olga Sharonova <olka@webrtc.org>
Commit-Queue: Olga Sharonova <olka@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34892}
Currently both KWin (KDE) and Mutter (GNOME) window managers don't
use DMA-BUFs by default, but only when client asks specifically for
them (KWin) or when experimental DMA-BUF support is enabled (Mutter).
While current implementation works just fine on integrated graphics
cards, it causes issues on dedicated GPUs (AMD and NVidia) where the
code either crashes or screensharing is slow and unusable.
To fix this, DMA-BUFs has to be opened using OpenGL context and not
being directly mmaped(). This implementation requires to use DMA-BUF
modifiers, as they are now mandatory for DMA-BUFs usage.
Documentation for this behavior can be found here:
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/doc/dma-buf.dox
Bug: chromium:1233417, webrtc:13137
Change-Id: I0cecf16d6bb0f576954b9e8f071cab526f7baf2c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227022
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34889}
We already default to PipeWire 0.3 and there is no reason to keep
continue supporting an old version of PipeWire which is not maintained
anymore, wont't get any update or new features. It also makes the code
easier to understand since we can remove all ifdefs we had to support
two versions simultaneously.
Bug: chromium:1146942
Change-Id: I7156e1784ebfad111485a2944199563568a75eec
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227345
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34765}
CL partially auto-generated with:
git grep -l "\bassert(" | grep "\.[c|h]" | \
xargs sed -i 's/\bassert(/RTC_DCHECK(/g'
And with:
git grep -l "RTC_DCHECK(false)" | \
xargs sed -i 's/RTC_DCHECK(false)/RTC_NOTREACHED()/g'
With some manual changes to include "rtc_base/checks.h" where
needed.
A follow-up CL will remove assert() from Obj-C code as well
and remove the #include of <assert.h>.
The choice to replace with RTC_DCHECK is because assert()
is because RTC_DCHECK has similar behavior as assert()
based on NDEBUG.
This CL also contains manual changes to switch from
basic RTC_DCHECK to other (preferred) versions like
RTC_DCHECK_GT (and similar).
Bug: webrtc:6779
Change-Id: I00bed8886e03d685a2f42324e34aef2c9b7a63b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/224846
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34442}
We need to specify that the cursor should be included in the stream as
by default xdg-desktop-portal defaults to hidden cursor.
Bug: chromium:1202526
Change-Id: Ic4742da2e51f7ed28cb9d7b6b0c069c1fa7d0cee
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214782
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34137}
Set we don't use full stream width. This follows same code as in PW 0.3
case, it was just accidentally omitted.
Bug: chromium:682122
Change-Id: Ifb9200a14387ba9b9da3246c9c4e30306393c4e6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214700
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Wez <wez@google.com>
Cr-Commit-Position: refs/heads/master@{#34124}
This is not defined anywhere, including chromium.
Bug: None
Change-Id: If5e89880570a80dd5720e48ebaefb0eb2c37fab3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215360
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#34105}
On a 32bit system, this reduces the allocation size of the flag
down from 12 bytes to 8, and removes the need for a vtable (the extra
4 bytes are the vtable pointer).
The downside is that this change makes the binary layout of the
flag, less compatible with RefCountedObject<> based reference counting
objects and thus we don't immediately get the benefits of identical
COMDAT folding and subsequently there's a slight binary size increase.
With wider use, the binary size benefits will come.
Bug: none
Change-Id: I04129771790a3258d6accaf0ab1258b7a798a55e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215681
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33793}
Adds a new "rtc_pipewire_version" build option to specify version of
PipeWire we want to build against. We use version "0.2" by default
which is version of PipeWire we currently have in sysroot and which
is supported even on older systems like RHEL7 and Debian.
Bug: chromium:1146942
Change-Id: Ib74b52fa87623a3f960e419916b01586aaeba47f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195441
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32768}
Changes:
1) Scoped class
This is a special class for GLib based objects which we need to manually
delete with different functions. Wrapping these objects into Scoped class
will destroy them automatically when they go out of scope.
2) Window sharing support
Unlike screen sharing, with window sharing we are required to obtain more
information from the PipeWire stream, like video crop metadata, which we
use to properly set size of our buffer.
3) Support for DmaBuf and MemFd buffer types
As of now, we expected the PipeWire stream will provide only plain data
which we just need to copy to our buffer. We now add support for new
buffer types, which are often preferred for better effeciency.
4) Minor bugfixes:
a) Additionally accept PipeWire streams using alpha channels (BGRA, RGBA)
b) Add lock over PipeWire loop to prevent potential issues until we fully
intialize everything we need
c) When obtaining buffers, make sure we work with the latest one
Bug: chromium:682122
Change-Id: I64638d5dcbe18e7280550dca0b01b17c511ac98a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194100
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#32763}
This reverts commit 84524e6b196153e35910111f61c36489ec2bd1d7.
Reason for revert: https://webrtc-review.googlesource.com/c/src/+/160649/33#message-a83e8959e03a274642ca2ce1abb9ea0099f08097 + suspected in breaking WebRTC to Chromium rolls https://chromium-review.googlesource.com/c/chromium/src/+/2468139
Original change's description:
> Improve screen sharing with PipeWire on Wayland
>
> Currently, sharing a screen or a window on Wayland opens unnecessary
> preview dialog on Chromium side, which is then followed by a similar
> dialog on xdg-desktop-portal side. The Chromium dialog is useless on
> Wayland, as it doesn't show anything. This is because Chromium doesn't
> have access to screen content as in case of X11 session. To fix this, we
> want to avoid showing the preview dialog in case we find that we run on
> Wayland and only pick a screen or a window from the dialog that comes
> from xdg-desktop-portal.
>
> This patch splits BaseCapturerPipeWire class, moving portal related code
> into XdgPortalBase, which does all the DBus communication and which is
> supposed to be reused by BaseCapturerPipeWire when the user confirms
> the dialog from xdg-desktop-portal. The XdgPortalBase is extended to
> support multiple calls at once, where each call is identified by Id.
>
> Relevant change on Chromium side will be in a different review.
>
> Bug: chromium:682122
> Change-Id: I2bcd07d16a5eb3b902db63ea9a164c5bd39c23a0
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/187492
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Commit-Queue: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32388}
TBR=mbonadei@webrtc.org,tommi@webrtc.org,sprang@webrtc.org,guidou@webrtc.org,mfoltz@chromium.org,grulja@gmail.com
Change-Id: I1a9748ced5626903b12214d677c7b8919c2ac385
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:682122
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/188380
Reviewed-by: Olga Sharonova <olka@webrtc.org>
Commit-Queue: Olga Sharonova <olka@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32398}
Currently, sharing a screen or a window on Wayland opens unnecessary
preview dialog on Chromium side, which is then followed by a similar
dialog on xdg-desktop-portal side. The Chromium dialog is useless on
Wayland, as it doesn't show anything. This is because Chromium doesn't
have access to screen content as in case of X11 session. To fix this, we
want to avoid showing the preview dialog in case we find that we run on
Wayland and only pick a screen or a window from the dialog that comes
from xdg-desktop-portal.
This patch splits BaseCapturerPipeWire class, moving portal related code
into XdgPortalBase, which does all the DBus communication and which is
supposed to be reused by BaseCapturerPipeWire when the user confirms
the dialog from xdg-desktop-portal. The XdgPortalBase is extended to
support multiple calls at once, where each call is identified by Id.
Relevant change on Chromium side will be in a different review.
Bug: chromium:682122
Change-Id: I2bcd07d16a5eb3b902db63ea9a164c5bd39c23a0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/187492
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32388}
This reverts commit 9b87037073f1811bcdae30967167f30b364e6879.
Reason for revert: Causing compile failures that prevent rolling into chrome.
See https://ci.chromium.org/p/chromium/builders/try/cast_shell_linux/726007https://chromium-review.googlesource.com/c/chromium/src/+/2461647
Original change's description:
> Improve screen sharing with PipeWire on Wayland
>
> Currently, sharing a screen or a window on Wayland opens unnecessary
> preview dialog on Chromium side, which is then followed by a similar
> dialog on xdg-desktop-portal side. The Chromium dialog is useless on
> Wayland, as it doesn't show anything. This is because Chromium doesn't
> have access to screen content as in case of X11 session. To fix this, we
> want to avoid showing the preview dialog in case we find that we run on
> Wayland and only pick a screen or a window from the dialog that comes
> from xdg-desktop-portal.
>
> This patch splits BaseCapturerPipeWire class, moving portal related code
> into XdgPortalBase, which does all the DBus communication and which is
> supposed to be reused by BaseCapturerPipeWire when the user confirms
> the dialog from xdg-desktop-portal. The XdgPortalBase is extended to
> support multiple calls at once, where each call is identified by Id.
>
> Relevant change on Chromium side will be in a different review.
>
> Bug: chromium:682122
> Change-Id: If8afd36da66231eb154cdc00114908ac897ee4cf
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/160649
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32342}
TBR=mbonadei@webrtc.org,jamiewalch@chromium.org,tommi@webrtc.org,sprang@webrtc.org,tomas.popela@gmail.com,grulja@gmail.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:682122
Change-Id: I41518f795e34b84374bc8208b711cfeb0a070578
No-Try: True
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/187352
Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32365}
Currently, sharing a screen or a window on Wayland opens unnecessary
preview dialog on Chromium side, which is then followed by a similar
dialog on xdg-desktop-portal side. The Chromium dialog is useless on
Wayland, as it doesn't show anything. This is because Chromium doesn't
have access to screen content as in case of X11 session. To fix this, we
want to avoid showing the preview dialog in case we find that we run on
Wayland and only pick a screen or a window from the dialog that comes
from xdg-desktop-portal.
This patch splits BaseCapturerPipeWire class, moving portal related code
into XdgPortalBase, which does all the DBus communication and which is
supposed to be reused by BaseCapturerPipeWire when the user confirms
the dialog from xdg-desktop-portal. The XdgPortalBase is extended to
support multiple calls at once, where each call is identified by Id.
Relevant change on Chromium side will be in a different review.
Bug: chromium:682122
Change-Id: If8afd36da66231eb154cdc00114908ac897ee4cf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/160649
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32342}
When Chromium displays the selection dialog for screens it gets the thumbnails by calling SelectSource for the first monitor then CaptureFrame, then SelectSource for the next monitor then CaptureFrame, and so on. With 1 or 2 screens this does not show any issues, but with 3 or more screens the program may crash.
The queue of frame buffers is actually just 2 frame buffers that get swapped every time a frame is captured. When you have one monitor both buffers will be sized for it's resolution. When you have two monitor the first buffer is sized for the first monitor and the second buffer for the second monitor. Since the monitors are selected in turn monitors and frame buffers stay matched up and things work fine. With a third monitor the first buffer is sized for the first monitor, but then later reused to capture the third monitor. If the resolution of the third monitor does not match the first we either crash or have extra junk in the frame from when we captured the first monitor.
Bug: chromium:396091
Change-Id: I7b5ee914b02fee48c09422cee1e320396c9550c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174520
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#31229}
