EnableDrDc flag should not be used on Linux

[DADA30000]

This flag causes a lot of rendering issues in discord, on wayland specifically, discord strips it so it has no issues with it, but OpenASAR forcefully passes it, and because of that GPU process of discord just crashes and fallbacks to software render when trying to view images/videos/gifs on Linux/Wayland.
And anyway it looks like it was made for Android/ChromeOS specifically, so maybe check if platform is one of these before adding that flag?

[DarkPhilosophy]

I can reproduce the same failure reliably and ran a controlled OpenAsar/no-OpenAsar A/B test. This is severe because Discord silently falls back to software rendering after the GPU subprocess crash loop.

Environment

• Discord desktop 1.0.154
• Electron 42.7.1 / Chromium 148.0.7778.280
• OpenAsar nightly 5a44615
• Linux Wayland (GNOME)
• AMD Radeon RX 9070, Mesa/RADV
• Hardware acceleration enabled
• Vencord was present in both test arms; same Discord profile, session, content, and system

Reproduction

1. Start Discord with OpenAsar on native Wayland.
2. Open a Discord Mission/Quest HLS video (the reproducible sample was a 1920x1080 Mission video).
3. The first playback may initially look smooth.
4. Roughly 10–12 seconds after startup/playback, the GPU subprocess exits repeatedly.
5. Reopening the same video then flickers and stutters badly because Chromium has fallen back to software rendering.

Logs

ERROR:ui/ozone/platform/wayland/gpu/wayland_surface_factory.cc:252
'--ozone-platform=wayland' is not compatible with Vulkan. Consider switching to '--ozone-platform=x11' or disabling Vulkan

ERROR:content/browser/gpu/gpu_process_host.cc:998
GPU process exited unexpectedly: exit_code=133

Detected frequent crash for non-renderer process

This happens three times. After the crash loop, renderer/GPU child command lines show the software fallback, including --use-gl=disabled and --disable-gpu-compositing. The visible black flicker coincides with GPU-surface/process recreation; sustained video lag follows the software fallback.

Measurements

Using HTMLVideoElement.getVideoPlaybackQuality() on the exact Mission player:

• OpenAsar path after the failure: 99/190 frames dropped over about 8 seconds (other runs: 88/194, 81/190)
• A short pre-crash interval could misleadingly show 0/190; the lag returned as soon as the GPU subprocess crashed

Controlled A/B result

I stopped every Discord process, rebuilt/reinstalled the same Vencord runtime, restored Discord's original bootstrap, and removed only OpenAsar. I then started one clean native-Wayland Discord instance with the same profile and hardware acceleration enabled.

Without OpenAsar:

• the same Mission video was visually smooth;
• player controls/overlay animation was smooth;
• no black flicker occurred during the test;
• the GPU subprocess remained alive beyond the previous crash window;
• after 30+ seconds there were no new GPU process exited, Detected frequent crash, or wayland_surface_factory errors.

This strongly confirms the regression boundary is OpenAsar, not Discord Missions, VAAPI alone, Vencord, the media file, or a general Wayland/Vulkan hardware failure. Disabling VAAPI appeared to help only during the pre-crash interval; it did not prevent the GPU subprocess crash, so VAAPI is not established as the root cause.

Issue #254's EnableDrDc hypothesis is consistent with the behavior, but my A/B test has not isolated that one flag independently. It would be useful to stop forcing Linux GPU feature flags (especially on Wayland), or gate them by platform and add a conservative Linux preset. A crash-loop fallback to software is difficult for users to diagnose because Discord continues running while video and UI performance collapse.