On macOS, release builds log to /tmp/Moonlight-<epoch>.log. /tmp is
shared by all users and the file name is predictable, so another local
user could plant symlinks at upcoming log names and have Moonlight
truncate and overwrite any file the victim can write to. The log was
also created world-readable.
Open the log with QIODevice::NewOnly (O_CREAT|O_EXCL) so an existing
file or symlink is never opened, and create it readable only by the
owner on Qt 6.3+. If the open fails we keep logging to stderr, as we
already did for any other open failure.
macOS defaults keyboard navigation to text fields and lists only, so Tab
(and the gamepad navigation that synthesizes it) can't move focus between
controls on the settings page. Other platforms already default to this.
Some platforms like the VisionFive 2 don't have working desktop GL,
so they must use GLES to be able to render at all. Qt doesn't try
to fall back if it fails to find a compatible EGL config, so we must
do so ourselves.
We can avoid disabling EGL entirely by forcing Qt to use GLES,
which is not impacted by the black window issue. This lets us
simplify back to EGL everywhere.
The latter will still match on a hybrid system when the iGPU's EGL
implementation is in use. This scenario works properly with EGL
rendering in Qt and SDL, so we want to allow that.
This seems to cause 10+ second hangs at the StreamSegue spinner
when using the Qt5-based Snap on Ubuntu 24.04's Wayland session.
It's unclear if this is still an issue on Qt 6, but let's be
conservative and just revert it for now.
This reverts commit f57257cbfd.
Using a mix of GLX and EGL can cause interoperability issues when
our EGLRenderer tries to bind an EGL context while Qt already has
a GLX context bound on the same thread. This was the source of a
number of confusing EGLRenderer failures over the years.
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.