Performing this each time DrmRenderer is initialized leads to long
delays when choosing a decoder on embedded platforms, particularly
those like TH1520/JH7110 which lack accelerated GL drivers.
Replace the generic starfive hack with proper logic to examine the
supported enum values to select a colorspace. This fixes incorrect
colors with vs-drm on the TH1520.
Planes seem to be listed in descending order of capabilities
with later planes sometimes lacking scaling capabilities, which
is the case with vs-drm on the TH1520.
This kills performance on some Intel iGPUs (particularly Atom chips like N100),
so let's remove the copy and solve this issue a different way instead.
This reverts commit a6fccf93d149a8b67eeac0b0fe109a142f0937d8.
These are only really useful for Wayland scenarios, but:
- Wayland is explicitly disabled for AppImage due to EGL issues
- VDPAU now works under XWayland with 545 and later drivers
- Moonlight now has a Vulkan Video backend which works with 535 and later drivers
Fixes#1314
libva 2.20 is good enough at detecting driver names (even under XWayland)
that we don't need to use the fallback name list anymore. This saves time
probing drivers, avoids excessive log output from failed probes, and avoids
tickling bugs in VAAPI drivers that are installed but unused.
Users want to control when the notch is and is not included for display scaling.
Fixes#1301
This reverts commit e25d9b0da200154276fd0b8f44a0f7419420275f.
In addition to resolving issues with mixing HDR and SDR displays and moving
between them while streaming, it also allows streaming HDR content to an SDR
display with tone mapping handled transparently by libplacebo.
This case exists to handle the initial bringup of the renderer when
the window appears on screen. We can ignore these if we already
created a renderer, to avoid renderer re-creation if a spurious
SDL_WINDOWEVENT_SHOWN event arrives later.
Logging these isn't a major issue because they change each session and
the privilege level to access the logs is the same as those to access the
private key of Moonlight client itself, but there's also no good reason to
log them either.
Native packages and Flatpak/Snap packages both have properly set
driver path values embedded in libva.so/libvdpau.so. Let's not go
splunking for drivers in random folders on those systems.