This has mostly seemed to work fine until now; but there's a collision
happening in chromium where if the source is being shown in the Window
Picker it collides with the (also null) Dialog ID and is ignored. While
we could patch that code to not count Null as a collision, there's the
potential for other (future) code to simply ignore a capture source
that it thinks is Null.
Fixed: chromium:1295375
Change-Id: I4356084f0af97f4d56632938b0d9a24d327f7107
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251500
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36008}
With more GPUs it might happen that server used different render
node from the one we pick from the list. This would cause DMA-BUF to
fail to import so we use Wayland client library to obtain wl_display in
order to initialize EGLDisplay using same render node and have previous
approach as a fallback. Also everyone else uses EGL_LINUX_DMA_BUF_EXT
target for importing EGLImages from DMA-BUF file descriptors so use it
as well to be sure we import buffers same way as they are produced.
Bug: chromium:1290566
Bug: webrtc:13429
Change-Id: I32bbb0bdb28c08b6e7fcb3f94009f82a2041b6ee
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/250661
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35997}
Moving the template specialization into the header causes ODR
violation when the header file is included in other units. Making
the specialization inline to avoid this problem.
Bug: chromium:1291247
Change-Id: I090548c1c3dd07a8c46b87ae90ebdd45a60a5cde
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251200
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35969}
This is a reland of 325789c4576b60147ee1ef225d438cbb740f65ff
Original change's description:
> Mark all bool conversion operators as explicit
>
> An explicit bool conversion operator will still be used implicitly
> when an expression appears in "bool context", e.g., as the condition
> in an if statement, or as argument to logical operators. The
> `explicit` annotation prevents conversion in other contexts, e.g.,
> converting both a and b to bool in an expression like `a == b`.
>
> Bug: None
> Change-Id: I79ef35b1ea831e6011ae472900375ae8a3e617ab
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/250664
> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Niels Moller <nisse@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#35927}
Bug: None
Change-Id: Ie057dfc8c0b5c498e2c8daff7620172c89f0e011
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251380
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35962}
In case we fail to import a DMA-BUF with given modifier, we can try to
drop the modifier we failed to use and renegotiate stream parameters
in order to use a different modifier or fallback to shared memory buffers.
Bug: chromium:1290566
Change-Id: I617513bdd67a43f62b647a172e0c166af138b3f9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249798
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35957}
This allows us to keep always some frame around so we can return it
everytime consumer asks us to capture a frame as before we either
returned current frame or nothing as there was no new frame available.
This will be needed in order to support mouse cursor separately as
DesktopAndCursorComposer requires frame everytime, even if it's the
same one as before so we can combine it with the mouse cursor.
Bug: webrtc:13429
Change-Id: Ice87968846870c0a880ab469d9e052b4978e658c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/239362
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35956}
This reverts commit 325789c4576b60147ee1ef225d438cbb740f65ff.
Reason for revert: Breaks downstream clients.
Original change's description:
> Mark all bool conversion operators as explicit
>
> An explicit bool conversion operator will still be used implicitly
> when an expression appears in "bool context", e.g., as the condition
> in an if statement, or as argument to logical operators. The
> `explicit` annotation prevents conversion in other contexts, e.g.,
> converting both a and b to bool in an expression like `a == b`.
>
> Bug: None
> Change-Id: I79ef35b1ea831e6011ae472900375ae8a3e617ab
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/250664
> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Niels Moller <nisse@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#35927}
TBR=mbonadei@webrtc.org,nisse@webrtc.org,tommi@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I392cd0c7bd96c90e0db20831864418adb7d58bc3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251080
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35929}
An explicit bool conversion operator will still be used implicitly
when an expression appears in "bool context", e.g., as the condition
in an if statement, or as argument to logical operators. The
`explicit` annotation prevents conversion in other contexts, e.g.,
converting both a and b to bool in an expression like `a == b`.
Bug: None
Change-Id: I79ef35b1ea831e6011ae472900375ae8a3e617ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/250664
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35927}
This fixes a crash introduced with recent move of Scoped class for
glib objects into a separated implementation.
Bug: chromium:1291247
Change-Id: I49d56bc0811f52434213516f51ca9e8712692e15
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/250840
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35922}
Adds missing RTC_NO_SANITIZE("cfi-icall") attributes to a few needed
functions for PipeWire initialization. These are methods that call (or
call methods that end up inlined and call) function pointers as a result
of dlopen'ing a lib. For ShareScreencastStream, the generated
InitializeStubs method appears to trigger this; while the egl_dmabuf
destructor appears to need this due to the EglDestroyContext and
EglTerminate calls that it makes.
Bug: webrtc:13659
Change-Id: Idb4af985293224957a50d17d9042524af2b66138
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/250702
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35918}
Moves the `Scoped` template (meant for clearing up the references) into
separate utils so as to allow for reuse in future. Other portal instances
e.g. remote desktop portal will benefit from this later.
Bug: chromium:1291247
Change-Id: Ie36415573edcbe4f697cf97b568243f09f26915d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249400
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#35916}
This reverts commit 7b370b935ec0dac991da08f9da227df9ce245fd5.
Reason for revert: Breaking WebRTC in Chrome rolls. Roll can be found here https://chromium-review.googlesource.com/c/chromium/src/+/3436384/. Example failed build https://ci.chromium.org/ui/p/chromium/builders/try/chromeos-amd64-generic-rel-compilator/65973/overview. Failures seem to be in ChromeOS with the nearby library:
error: no viable conversion from 'rtc::RefCountedObject<CreateSessionDescriptionObserverImpl> *' to 'rtc::scoped_refptr<CreateSessionDescriptionObserverImpl>'
Original change's description:
> Delete implicit conversion from raw pointer to scoped_ref_ptr
>
> Followup to https://webrtc-review.googlesource.com/c/src/+/242363
>
> Bug: webrtc:13464
> Change-Id: I44358e8cfedeea92aac4ef47c540aff9a4865cdc
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/247362
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
> Commit-Queue: Niels Moller <nisse@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#35897}
TBR=mbonadei@webrtc.org,nisse@webrtc.org,tommi@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: Ib0beb44421519c8393131c55564c62c9b4d91504
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:13464
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/250621
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35905}
1) Fixes crash on dlclose when using NVidia driver
2) Closes EGLDisplay and EGLContext on destruction
3) Prints correct errors for EGL calls
Bug: chromium:1290566
Change-Id: Icfb3cad2e7c054030821479be7e48d77a4e0d5e6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249795
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35833}
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}
