Unity requires input injection API from Mir
Bug #1233378 reported by
Robert Carr
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Mir |
Invalid
|
Undecided
|
Robert Carr | ||
Bug Description
Unity uses an input region on the bottom of the screen in order to detect the HUD button edge gesture. However, the client also expects to receive input events in this region, such that the menu bar may be shown (or normal sorts of client things).
Ideally we would solve this with the input filter API, however, currently the shell receives input just as a normal surface (due to some difficulties of Qt adaptation). This way, the shell needs an API to reinject the events it has received (in the HUD gesture input area) to the client.
Related branches
lp:~robertcarr/mir/input-injecter-api
- Robert Carr (community): Disapprove
- Daniel d'Andrada (community): Needs Fixing
- Daniel van Vugt: Abstain
- Alexandros Frantzis (community): Abstain
- Alan Griffiths: Needs Information
- PS Jenkins bot (community): Approve (continuous-integration)
-
Diff: 1214 lines (+858/-5)22 files modified3rd_party/android-input/android/frameworks/base/services/input/InputDispatcher.cpp (+55/-0)
3rd_party/android-input/android/frameworks/base/services/input/InputDispatcher.h (+13/-2)
include/server/mir/default_server_configuration.h (+3/-0)
include/server/mir/input/android/dispatcher_input_configuration.h (+2/-0)
include/server/mir/input/input_configuration.h (+2/-0)
include/server/mir/input/null_input_configuration.h (+1/-0)
include/server/mir/shell/input_injecter.h (+55/-0)
include/server/mir/shell/surface.h (+4/-0)
include/shared/mir/input/android/android_input_lexicon.h (+1/-0)
include/test/mir_test_doubles/mock_input_dispatcher.h (+2/-0)
src/server/default_server_configuration.cpp (+12/-2)
src/server/input/android/CMakeLists.txt (+1/-0)
src/server/input/android/android_input_injecter.cpp (+61/-0)
src/server/input/android/android_input_injecter.h (+68/-0)
src/server/input/android/dispatcher_input_configuration.cpp (+10/-0)
src/server/input/null_input_configuration.cpp (+13/-0)
src/server/shell/surface.cpp (+13/-0)
src/shared/input/android/android_input_lexicon.cpp (+65/-0)
tests/acceptance-tests/test_client_input.cpp (+125/-0)
tests/unit-tests/input/android/CMakeLists.txt (+1/-0)
tests/unit-tests/input/android/test_android_input_injecter.cpp (+93/-0)
tests/unit-tests/input/android/test_android_input_lexicon.cpp (+258/-1)
| Changed in mir: | |
| assignee: | nobody → Robert Carr (robertcarr) |
| status: | New → In Progress |
Revision history for this message
| Daniel d'Andrada (dandrader) wrote | #1 |
Revision history for this message
| Robert Carr (robertcarr) wrote | #2 |
| Changed in mir: | |
| status: | In Progress → Invalid |
To post a comment you must log in.
"Ideally we would solve this with the input filter API[....]"
I think that it will be solved in the future with the accept/reject logic for touches, to be added to android-input. So shell would accept or reject touches and our android:
Have you seem this?
https:/
So at a first moment we would have technique 1 implemented.
On a second step we would implement technique 2 with technique 1 as a fallback for apps that are not aware of the accept-reject feature.
This was discussed and agreed with mir team when we all last met in person.