This changes comes with several different refactorings all rolled into one,
unfotunately I couldn't find a way to pull them apart:
- First of all annotations now can either recorded (that is, we copy the value
and have the crash reporting code own the copy) or registered. Several
annotations are changed to use this functionality so that we don't need to
update them as their value change.
- The code in the exception handler is modified to read the annotations from
the mozannotation_client crate. This has the unfortunate side-effect that
we need three different bits of code to serialize them: one for annotations
read from a child process, one for reading annotations from the main process
outside of the exception handler and one for reading annotations from the
main process within the exception handler. As we move to fully
out-of-process crash reporting the last two methods will go away.
- The mozannotation_client crate now doesn't record annotation types anymore.
I realized as I was working on this that storing types at runtime has two
issues: the first one is that buggy code might change the type of an
annotation (that is record it under two different types at two different
moments), the second issue is that types might become corrupt during a
crash, so better enforce them at annotation-writing time. The end result is
that the mozannotation_* crates now only store byte buffers, track the
format the data is stored in (null-terminated string, fixed size buffer,
etc...) but not the type of data each annotation is supposed to contain.
- Which brings us to the next change: concrete types for annotations are now
enforced when they're written out. If an annotation doesn't match the
expected type it's skipped. Storing an annotation with the wrong type will
also trigger an assertion in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D195248
This patch makes it so that we avoid blocking all features with the
blocklist, and instead continue to allow the safe subset proscribed by
GfxInfoBase::OnlyAllowFeatureOnKnownConfig. Any feature allowed in an
unknown configuration should be allowed in a blanket blocklist entry,
unless we know for a fact that we need to also block them.
Differential Revision: https://phabricator.services.mozilla.com/D197963
Some features such as the GPU process (except on Android), backdrop
filter (because it always works with Software WebRender), ANGLE (because
it is generally good) and out of process WebGL (we generally want to
remote WebGL for sandboxing purposes) are special, and should not be
disabled simply because we are uncertain about our configuration. In
these situations, disable most features, but keep these enabled by
default.
Differential Revision: https://phabricator.services.mozilla.com/D197595
Some features such as the GPU process (except on Android), backdrop
filter (because it always works with Software WebRender), ANGLE (because
it is generally good) and out of process WebGL (we generally want to
remote WebGL for sandboxing purposes) are special, and should not be
disabled simply because we are uncertain about our configuration. In
these situations, disable most features, but keep these enabled by
default.
Differential Revision: https://phabricator.services.mozilla.com/D197595
v4l2test emits errors/warnings for every device which isn't an M2M
decoder, which can be quite a lot of devices. So only emit these as
warnings instead of critical errors. To see the output from v4l2test,
set gfx.logging.level = 5 in about:config.
Differential Revision: https://phabricator.services.mozilla.com/D181980
In GfxInfo, probe all V4L2 devices to see which of them can do M2M
hardware decode acceleration. Set the hardware decode support features
appropriately depending on what we find.
Differential Revision: https://phabricator.services.mozilla.com/D178780
Add separate options to control whether we build VA-API and/or V4L2
hardware video decode. These options default to enabled on the
platforms where these decoders are used.
The downstream MOZ_WAYLAND_USE_HWDECODE build option is used within the
FFmpeg platform and is only set when building against a supported
version of the FFmpeg libraries (i.e. not for ffmpeg57).
Differential Revision: https://phabricator.services.mozilla.com/D178945
- Run glxtest directly from GfxInfo::GetData() in case we're missing glx test data. That happens for unusual code paths
like profile manager run or xpcshell testing.
- Remove nsIGfxInfoDebug::fireTestProcess() hack to run glxtest in testsuite. We don't need that due this change.
Differential Revision: https://phabricator.services.mozilla.com/D175868
- Migrate glxtest pid and pipe fd variables to static members of GfxInfo on Linux
- Implement GfxInfo::FireGLXTestProcess() to run glxtest process.
Differential Revision: https://phabricator.services.mozilla.com/D175867
- Implement ManageChildProcess() to get data from child test process and process exit status. We use glib I/O routines there instead of
our custom implementation.
- Update GfxInfo::GetData() and GfxInfo::GetDataVAAPI() to use it.
Differential Revision: https://phabricator.services.mozilla.com/D175808
glxtest is run later when Firefox already spawns threads. Recently glxtest runs in forked process
which doesn't work correctly in multi-thread environment, so we need to move glxtest to different binary file
and launch it as stand alone code.
Differential Revision: https://phabricator.services.mozilla.com/D173486
- Implement fire_vaapi_process() which launch VA-API test utility on given DRM device.
- Implement GfxInfo::GetDataVAAPI() which gets VA-API test results
- Run VA-API tests when FEATURE_HARDWARE_VIDEO_DECODING is probed and only if it's enabled by GfxInfo.
Differential Revision: https://phabricator.services.mozilla.com/D171995
glxtest is run later when Firefox already spawns threads. Recently glxtest runs in forked process
which doesn't work correctly in multi-thread environment, so we need to move glxtest to different binary file
and launch it as stand alone code.
Differential Revision: https://phabricator.services.mozilla.com/D173486
- Implement fire_vaapi_process() which launch VA-API test utility on given DRM device.
- Implement GfxInfo::GetDataVAAPI() which gets VA-API test results
- Run VA-API tests when FEATURE_HARDWARE_VIDEO_DECODING is probed and only if it's enabled by GfxInfo.
Differential Revision: https://phabricator.services.mozilla.com/D171995
glxtest is run later when Firefox already spawns threads. Recently glxtest runs in forked process
which doesn't work correctly in multi-thread environment, so we need to move glxtest to different binary file
and launch it as stand alone code.
Differential Revision: https://phabricator.services.mozilla.com/D173486
- Implement fire_vaapi_process() which launch VA-API test utility on given DRM device.
- Implement GfxInfo::GetDataVAAPI() which gets VA-API test results
- Run VA-API tests when FEATURE_HARDWARE_VIDEO_DECODING is probed and only if it's enabled by GfxInfo.
Differential Revision: https://phabricator.services.mozilla.com/D171995
glxtest is run later when Firefox already spawns threads. Recently glxtest runs in forked process
which doesn't work correctly in multi-thread environment, so we need to move glxtest to different binary file
and launch it as stand alone code.
Differential Revision: https://phabricator.services.mozilla.com/D173486
- Implement fire_vaapi_process() which launch VA-API test utility on given DRM device.
- Implement GfxInfo::GetDataVAAPI() which gets VA-API test results
- Run VA-API tests when FEATURE_HARDWARE_VIDEO_DECODING is probed and only if it's enabled by GfxInfo.
Differential Revision: https://phabricator.services.mozilla.com/D171995
glxtest is run later when Firefox already spawns threads. Recently glxtest runs in forked process
which doesn't work correctly in multi-thread environment, so we need to move glxtest to different binary file
and launch it as stand alone code.
Differential Revision: https://phabricator.services.mozilla.com/D173486