Before, the cursor kept updating for no good reason really.
It's also a bit neater and it ever-so-slightly makes `WAYLAND_DEBUG`
logs easier to read, although they're still spammed by the window's
frame logic (which is needed).
- `Main::setup` early exits (failure or `--help`/`--version`) now
consistently return `EXIT_FAILURE` or `EXIT_SUCCESS` on all platforms,
instead of 255 on some and a Godot Error code on others.
- `Main::start` now returns the exit code, simplifying the handling of early
failures.
- `Main::iteration` needs to explicit set the exit code in OS if it errors
out.
- Web and iOS now properly return `OS::get_exit_code()` instead of 0.
This code was already partially there, although heavily incomplete and
nowadays commented out.
It got broken after the `WaylandThread` refactor and I didn't bother to
bring it over, preferring to `#if 0` it into oblivion for the time
being as I don't have a tablet/pen which support an eraser and tilt
reporting.
This commit brings it back and adds proper multi-tool support (needed
for eraser detection) thanks to winston-yallow, who could test this code
with their more capable tablet.
This is a pretty popular approach that took a while for me to wrap my
head around and which only recently got "official" support through an
update (xdg_shell version 6), so I think that this is all-in-all a
better option than the overkill 2000Hz ticking we have now :P
Basically, we wait for a frame event and, if either too much time passes
or we get the new `suspended` state, we consider the window as "hidden"
and stop drawing, ticking by the low usage rate.
This should work great for KDE and Mutter, which support the new state,
but not yet for sway, which is still stuck at a very old xdg_shell
version and thus falls back to the timeout approach.
Be aware that if we rely on timing out the engine will have to stall for
the whole timeout, which _could_ be problematic but doensn't seem like
it. Further testing is needed.
Special thanks go to the guys over at #wayland on OFTC, who very
patiently explained me this approach way too many times.
Instead of hardcoding platform names that support C#, let platforms
set a flag indicating if they support it. All public platforms
except web already support it, and it's a pain to maintain a patch
for this list just to add additional names of proprietary console
platforms.
This makes adding new platforms or variants or existing platforms
much easier, as the platform can signal what it supports/doesn't
support directly, and we can avoid harcoding platform names.
