We already use RTC_NO_SANITIZE("cfi-icall") for most of the code and
it looks this one can be triggered recently with pw_loop_signal_event()
call.
Bug: webrtc:13659
Change-Id: I4dbb88f32de861e05be18254640db90b0f58c5e5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261300
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36787}
https://webrtc-review.googlesource.com/c/src/+/259457 was a
cherry-pick to M102; as such changes were not made there to keep the
merge to just what had already landed. This addresses the issues raised
on that CL.
Bug: chromium:1316478
Change-Id: I94fad0aa6fe9c67aee5a2f2158524d75b51db48e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/259660
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36631}
ChromeOS will use DPI (see crrev.com/c/3322917), but the
DesktopAndCursorComposer assumed pixels were used.
Test: Manually ensured it works
Bug: b/208370410
Change-Id: I5fee50d408fd204273946009e6653d4e60d1e458
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/259502
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jeroen Dhollander <jeroendh@google.com>
Cr-Commit-Position: refs/heads/main@{#36597}
While the target has a restricted visibility, since it was in rtc_base_approved
public deps, a lot of targets were able to bypass the visibility check.
So we remove the visibility restrictions and use the dependency explicitely
everywhere instead.
Bug: webrtc:8603
Change-Id: I94a03fdf7f94c54ab72081a58dd648e2cca73d17
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258944
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36566}
There is a crash report from the Windows OS API
where it repro only win10, not a Win11.
Unfortunately, Microsoft can't access the dump file or
hasn't repro internally so we decided to disable the WGC
fallback use in the OS other than Win11 now.
Once the change (support WGC fallback) reaches to Microsoft Edge
and it produce crash report, Edge team will take the
dump file to the Windows OS API owner for Win10 level fix (or
bring the Win11 fix to Win10).
Bug: chromium:1312937
Change-Id: I5335e2c57076d4fab08e9c74ade599259cff10d7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258821
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36558}
XDG desktop portal utils implicitly rely on few portal interfaces.
This change makes those interfaces explicit.
Bug: chromium:1291247
Change-Id: I3c300f33d04bfa8857ac9f1f9d634dbfc077e591
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258720
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36557}
Versions of Windows before Win11 will crash when `CreateForMonitor` is
called, but the system has no attached displays. This can be avoided by
adding a check to ensure at least one display is found before we return
true in `IsMonitorValid`. Previously we would early return `true` if the
"monitor" we were checking was the `kFullDesktopScreenId`.
Bug: chromium:1316478
Change-Id: I2562fe3834db574cf3706ee1d604472ac03f9ff3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258920
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#36555}
Remote desktop wrapper needs to create a barrier on when the screencast
portal is done (either succeeded or failed). This change adds an initial
enum to differentiate it from other values. CL also generalizes the
helper `PortalFailed` to `OnPortalDone` so as to account for both
failure/success scenarios.
Bug: chromium:1291247
Change-Id: I188f72533e75a88c9b30ce2bb093dae548cef7b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258540
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36526}
The Windows 2019 Enterprise SKU is based on RS5 but is missing support
for WGC. This changes adds a function IsWgcSupported which will check
that the API is actually present, which should be more robust than just
performing a version check.
Bug: webrtc:13932
Change-Id: Ib6a2278f316b9b86671df77fd37468c79564d655
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258163
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#36506}
Change adapts the `base_capturer_pipewire` so that a portal can be
injected in the capturer. This allows the remoting to inject its
own portal for the purpose of capturing desktop stream as long
as the injected portal provides implementation of the new interface
that is added as part of this change.
Additionally, a method has been exposed on the capturer to get
details about the portal session so that the remoting
implementation can use the same underlying session for controlling
inputs on the remote host.
Finally, desktop capturer interface is extended with a generic
method `GetMetadata` that is used to retrieve session related
information by CRD and relay it over to its input injector. Clients
provide override for the method and it eventually invokes the
underlying `GetSessionDetails` method on the portal instance.
Bug: chromium:1291247
Change-Id: I0dbd154eb16d4149f967c4a818eea51e7e6eb9a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257000
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36399}
Since 12.2, the orange/red indicator at the top right of the screen shows up as a window in the Chrome getDisplayMedia() picker, as it's not filtered out by the existing filters. Screenshots in the bug.
Bug: chromium:1297731, b/218211225
Change-Id: I0f87e8d2af42a5a2e3d84f69fe73596e9cf35622
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251841
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Tony Herre <herre@google.com>
Cr-Commit-Position: refs/heads/main@{#36350}
This reverts commit e1223747c27e22c4c4c3006af10d58aec9718b28.
Reason for revert: Breaks WebRTC roll into Chromium. E.g:
https://ci.chromium.org/ui/p/chromium/builders/try/cast_shell_linux/1166014/overview
Original change's description:
> wayland: Add a common interface for screencast and remote desktop portal
>
> Change adapts the `base_capturer_pipewire` so that a portal can be
> injected in the capturer. This allows the remoting to inject its
> own portal for the purpose of capturing desktop stream as long
> as the injected portal provides implementation of the new interface
> that is added as part of this change.
>
> Additionally, a method has been exposed on the capturer to get
> details about the portal session so that the remoting
> implementation can use the same underlying session for controlling
> inputs on the remote host.
>
> Finally, desktop capturer interface is extended with a generic
> method `GetMetadata` that is used to retrieve session related
> information by CRD and relay it over to its input injector. Clients
> provide override for the method and it eventually invokes the
> underlying `GetSessionDetails` method on the portal instance.
>
> Bug: chromium:1291247
> Change-Id: I81b7ce3b949d8be2e24e2d303d5fbc76a849209c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256400
> Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> Commit-Queue: Salman Malik <salmanmalik@google.com>
> Cr-Commit-Position: refs/heads/main@{#36323}
Bug: chromium:1291247
Change-Id: I73fbb1b9a103d61fd8d7f04bb8452b3e29da9025
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256801
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36331}
Change adapts the `base_capturer_pipewire` so that a portal can be
injected in the capturer. This allows the remoting to inject its
own portal for the purpose of capturing desktop stream as long
as the injected portal provides implementation of the new interface
that is added as part of this change.
Additionally, a method has been exposed on the capturer to get
details about the portal session so that the remoting
implementation can use the same underlying session for controlling
inputs on the remote host.
Finally, desktop capturer interface is extended with a generic
method `GetMetadata` that is used to retrieve session related
information by CRD and relay it over to its input injector. Clients
provide override for the method and it eventually invokes the
underlying `GetSessionDetails` method on the portal instance.
Bug: chromium:1291247
Change-Id: I81b7ce3b949d8be2e24e2d303d5fbc76a849209c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256400
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36323}
This is code that will be used to write tests and that makes sense to be
moved out and used somewhere else.
Bug: webrtc:13429
Change-Id: I2dd8f3111fdc9e6fa121c1e18644cbcf340b584e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256009
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36307}
DxgiOutputDuplicator objects hold a reference to the last frame that
they succesfully captured by maintaining a reference to the
SharedDesktopFrame that was passed as their target. This is done because
the DirectX capture APIs may fail to provide an update if there has been
no (or no substantial) change since the last capture call was made.
However, the higher levels of this capture stack
(DxgiDuplicatorController and ScreenCapturerWinDirectX), were unaware of
this, and assumed that the caller of CaptureFrame is the only one who
may have held a reference to the frame. Thus, when CaptureFrame is
called, the DirectX screen capturer assumes that the oldest frame in its
queue can be safely reused.
In the steady state, where capture is not being switched between
monitors, this is fine as there are no competing DxgiOutputDuplicators
being run and this assumption mostly holds true (or the frame is being
overwritten only when the DxgiOutputDuplicator is also done holding it).
However, when capture is being rapidly switched between multiple targets
(e.g. to show a preview of each of the available monitors), this can
result in a frame being held by one DxgiOutputDuplicator being passed to
another as a valid target and overwritten. In the common case of only a
single monitor this is essentially the same as steady state capture,
where there are no competing DxgiOutputDuplicator. In the other common
case of two monitors being captured, the fact that the
ScreenCaptureFrameQueue has two frames ends up masking this issue. Since
each monitor is captured in the same order, the same frame ends up
getting passed to each DxgiOutputDuplicator, so no data actually ends
up getting overwritten. In the case of 3 monitors, the 1st and 3rd
monitor end up sharing a frame, which when capture fails on one of them
surfaces as the other monitor being duplicately shown.
This change addresses the issue by ensuring that each screen that the
ScreenCapturerWinDirectX *actually attempts* to capture, gets it's own
FrameQueue, and thus essentially brings us back to the "steady state"
case for each monitor. Note that this does increase memory usage of
capturers that are switched between multiple targets by 2 frames/target
used (and actually attempted to be captured).
Alternatives considered:
DxgiOutputDuplicator makes a copy of the frame, rather than holding
a reference
This was rejected because adding an additional copy for every
capture upon getting a new frame, would expensive and could degrade
performance.
Allow the DxgiOutputDuplicators to "fail" when there has been no update
This would result in either a breaking change to the API for consumers
or would require the ScreenCapturerWinDirectX to track these last
captured frames; which would result in essentially the same approach,
but with less abstraction for re-using the frames.
Bug: chromium:1296228
Change-Id: I5442ec40e9f234046010b562b258db63693ccc6b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256043
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36295}
This CL addresses an issue where the desktop appears to freeze after
resizing the desktop in a curtained CRD session when using the DXGI
capturer. This problem does not reproduce when using the GDI capturer
nor does it reproduce when the Windows session is attached to the local
console.
After digging in, it appears that the DXGI DuplicateOutput API stops
providing updated frame data. No errors are returned but yet no data is
produced. The problem is that when in this condition, there isn't a
good way to discern between this problem and a case where the desktop
is actually static.
The DxgiDuplicatorController already contains logic to attempt to
capture a frame prior to returning success after reinitialization. This
logic works fine in the console case and occasionally works in the
detached session case. What I noticed in my reproductions was that DXGI
would produce a few frames before hanging (usually 1-2 but sometimes 3
or 4). My solution is to check the session state and adjust the number
of frames we attempt to capture (I also simplified the wait logic as
there was a bug in the time calc and it seemed more complicated than it
needed to be).
One option considered would be to introduced a new differ class higher
up in the stack which would run the GDI and DXGI capturers in parallel
(instead of in the fallback configuration as they are today) however
that seemed like overkill for this specific issue.
Bug: chromium:1307357
Change-Id: Idba4bb9b2aa7692040344d480be3f0d09b9ce9e9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256214
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@google.com>
Commit-Queue: Joe Downing <joedow@google.com>
Cr-Commit-Position: refs/heads/main@{#36286}
Change adds callbacks to the class so that the remote desktop portal can
still make use of this class for selecting sources but can provide its
own implementation on what to do after the sources are selected.
Furthermore, few getters are exposed in the class interface so as to
allow the remote desktop portal class to leverage them when sending the
captured pipewire frames onto the capture stream's consumer. Setters are
added for session, pipewire stream node id and few interfaces are made
public since remote desktop portal relies on them (e.g.
`SelectSources`).
The reason behind the change is that remote desktop portal depends on
screen cast portal for selecting sources. Also the setup to select
devices to control remotely as well as source selection should be
handled as part of the same session (and session should be
instantiated only once).
Currently, starting the screencast portal calls into a callback chain
that not only selects the sources but also starts the session but with
this change a consumer, such as remote desktop portal, can hook into
this callback chain by overriding the callbacks and provide a custom
callback chain from there onwards, if need be.
Bug: chromium:1291247
Change-Id: I983aff062ec2ddf52fdef5545fc58fede416e6ed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249862
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36285}
The diff capturer wrapper doesn't work if the frame doesn't have any
rectangle and a static image is observed while chromoting. This change
adds a rectangle to the frame object, as done by other capturers, and
this in turn ensures that the wrapper that calulcates diffs from one
frame to the next can do its job.
Bug: chromium:1291247
Change-Id: I5bf1981f34b3a88ad4d82a081fed1ce210f71ed0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251205
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36263}
Extract helper methods from screencast portal that can be
reused for remote desktop portal client.
Bug: chromium:1291247
Change-Id: I66d09c75f0c34d81c7ceff8998720fbbd1902ac8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249860
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36256}
Check whether there are any cursor metadata before we try to validate
and use them, otherwise we might crash on this.
Bug: webrtc:13429
Change-Id: I365da59a189b6b974cebafc94fec49d5b942efae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/255601
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36240}
getDisplayMedia capture the view of the screens and windows
in the capture dialog, but the issue is that captured view
of the Youtube somehow is blank. It repros only in certain
circumstances, for example, Canary channel.
If user reinstall the Canary as fresh new, we observed that
it doesn't repro.
Cause:
We aren't sure what's cause of this one yet.
Solution:
We decided to provide fallback WGC capturer when the main
capturer (GDI) shows blank. WGC could show yellow outline
in prior Win11 OS, but yellow outline looks better than
blank.
The blank detector and fallback capturer are what screen capturer
already supported. So, the solution will follow similar
pattern in the window capturer.
Bug: webrtc:13726
Change-Id: I620c817d259d7bb5c295adab11c4444349ab1c6c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/252625
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36224}
This CL fixes the issue where artifacts appear during capture with WGC
when the capture source is resized. A video of the issue is available
here: https://bugs.chromium.org/p/webrtc/issues/detail?id=9273#c44
The solution is to use CopySubresourceRegion instead of CopyResource to
only copy valid data into our texture. Additionally, we moved the call
to CreateMappedTexture to before the call to CopySubresourceRegion, as
the latter requires both textures to be of the same size.
Bug: webrtc:9273
Change-Id: I114458d95cbf58550ff653a985dd84db4741e0f8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/254100
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#36163}
We actually use headers from libepoxy (it's part of the sysroot) so this
was removed accicentally in one of previous changes and it just
magically worked as we include those headers with their full path
Bug: webrtc:13429
Change-Id: I4f5684521a76287a725272ce3833daae673d9332
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/252002
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36073}
Current implementation has mouse cursor as part of the screen itself
which means that everytime a cursor changes location, we have to update
whole screen content, which brings unnecessary load overhead. Using our
own mouse cursor monitor implementation allows us to track only mouse
cursor changes and update them separately for much better performance.
Bug: webrtc:13429
Change-Id: I224e9145f0bc7e45eafe4490de160f2ad4c8b545
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244507
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@{#36011}
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}
