rsx/overlays: Unified overlay input #13398
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Megamouse
reviewed
Feb 13, 2023
Megamouse
reviewed
Feb 13, 2023
Megamouse
reviewed
Feb 13, 2023
- Migrate dialogs with input-only threads to use the unified input system
- Restructure the inputs to encourage shorter input signature.
…p exits and we're in blocking mode - Avoids a race condition caused by the "blocking" call only updating results on cleanup/close
- Tested with OSK + home menu. Requires hacks to enable this setup so it's mostly an academic achievement.
kd-11
force-pushed
the
unified-overlay-input
branch
from
a656d82
to
41428ae
Compare
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Instead of having each async dialog spawning its own thread, let's just have the manager handle this. Interfaces are pushed onto a LIFO stack which also inserts some Z-ordering. Multiple open dialogs do not fight for input, the last active dialog retains the input target until it releases it.
The current implementation here is far from complete. As there is no input pre-emption, the currently opened dialog must finish inputs before handing over to the next one. This actually works out ok for what we need, but can be improved upon.
TODOs:
Pad intercept state should be a function of the unified handler.Nothing needs this right now.Explicit Z-pinning (e.g top-most or bottom-most pin)This requires a different stack implementation. Maybe later.