Currently the PointerController would be associated with the top most
freeform or external display if enable desktop mode.
But for presenting spots when enable showTouches from develop options,
they should be shown on the corresponding display where user touched.
Also changed Vector to std::vector.
Test: atest inputflinger_tests
Test: Use device support multi-display and touch screen (like mojave).
Enable showTaps from develop options and check if show tap spots.
Bug: 120815589
Change-Id: I0854fa97813aabf005dccb8ec6fbda10106126e9
When mouse pointer changes displays, it should also reload the
icon from new resources. Otherwise, if the densities of the
previous and new displays are different, the size of the pointer
sprite will look too small or too large.
- Add getDisplayContext to get the corresponding Context by displayId.
- Cache system pointer icons per display, clear if display removed.
- Fix icon moved to default when not resetting out of task bound.
Bug: 113559891
Test: Enable mouse pointer on default display, move to other screen
Change-Id: Ic42d0ec32d9c979281e13c83b9e8b57134fd4f0d
Limit mouse boundary to one display viewport.
Currently if desktop mode is enable, selects the topmost freeform display,
or find first external display if there is no freeform display.
Return the default display if desktop mode is not enable.
- Add getPointerDisplayId to find the preferred display.
- Limit update viewports from InputReader.
- obtainPointerController would also find the associated display id.
- Reload cursor resources if resolution or display changed.
Bug: 113559891
Test: atest inputfliger_tests
Test: ActivityView test app
Change-Id: Iffd01e27f5010ccfb0481a028658b7290ca6316d
Limit mouse boundary to one display viewport.
Currently if desktop mode is enable, selects the topmost freeform display,
or find first external display if there is no freeform display.
Return the default display if desktop mode is not enable.
- Add getPointerDisplayId to find the preferred display.
- Limit update viewports from InputReader. Also implements updatePointerDisplay
to find and associate with the specified display viewport.
- Reload cursor resources if resolution or display changed.
Bug: 113559891
Test: atest inputfliger_tests
Test: ActivityView test app
Change-Id: Ief3410a517be457dfe6f1180342bb1dc88833635
This changes native InputManagerService to use the new backend library
for inputflinger: libinputreader.
Bug: 119264687
Test: manual: Build, run, and test input (touch, mouse)
Change-Id: I619492d5492cd8444d7c2cc7af9717c19c938256
DisplayViewport::uniqueId is now std::string, so change the calls
appropriately. Do some additional cleanups and conversions.
This almost completely removes the dependency on String8.
Test: build only
Bug: 111108021
Change-Id: Ibbb6ca59e9061954d4a5fb930ef03d42cb0230db
Currently PointerController starts listening to display events
immediately (in its constructor) and never explicitly removes
the callback. The reference dangling from the looper
prevents the PointerController instance from being deleted
when all the clients have released their references.
As a result, when USB or BT mouse is disconnected,
the mouse stays frozen on screen and only goes away
after a 15 sec inactivity timeout.
This change introduces an intermediary LooperCallback
which holds only a weak reference to PointerController.
The pointer now disappears immediately upon mouse
disconnect.
Bug: 30824220
Change-Id: I5f7208dbfa381b3e21f248cc0da402f307faa184
The underlying implementation needs to be completely rethought. If a
process crashed while you were in pointer capture mode, you were
pretty much stuck in it. If the mouse happened to move outside of
your bounds right before you called the API, you'd never actually get
an event (whatever it was hovering over would). There's no easy way
for the system to tell you when you enter or exit this mode because
it doesn't actually track who the current request is from.
These are all solvable, but not in the N time frame. Maybe next time.
Bug: 26830970
Change-Id: I03efd63c499b86dc278491ca3284566c1965581f
This patch does the following things:
- add new graphic assets of large icons for accessibility needs
(imported from ChromeOS data)
- add the logic to choose the set of normal icons or accessibility icons
- make InputManagerService to observe the settings change, so that
it can reload the new resources
This patch misses non-1x graphic though, because ChromeOS doesn't
have such data.
Bug: 25778857
Change-Id: Ia5f95d47f50b3f6eea555c3af8069bc6bae0b400
Right now, it only supports I-beam on EditText, but further
rules will come in the future.
The png files for the icons are from chromium.
Bug: 24180385
Change-Id: I8de4ec8a5412b4830c08aa232c5083841c5c751c
Remove all of the pieces except the PointerController and SpriteController over
to frameworks/native in preparation for inputflinger. Those two need to stay in
frameworks/base for now because they depend on Skia currently. In the long run
they should be merged into either the InputManager or the WindowManager rather
than as a part of the inputservice / inputflinger.
Try 2.
Change-Id: I84259356d3eb8efc5aefb9d6b311b5fc590ea3ed
Remove all of the pieces except the PointerController and SpriteController over
to frameworks/native in preparation for inputflinger. Those two need to stay in
frameworks/base for now because they depend on Skia currently. In the long run
they should be merged into either the InputManager or the WindowManager rather
than as a part of the inputservice / inputflinger.
Change-Id: Iebef71f3030fb3d26a5f338eb66d75bb37c17734
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85