Mir

Merge lp://qastaging/~mir-team/mir/relative-pointer-events into lp://qastaging/mir

  1. relative-pointer-events
  2. Merge into development-branch
Proposed by Robert Carr
Status: Superseded
Proposed branch: lp://qastaging/~mir-team/mir/relative-pointer-events
Merge into: lp://qastaging/mir
Diff against target: 369 lines (+127/-16)
17 files modified
3rd_party/android-input/android/frameworks/base/services/input/InputReader.cpp (+3/-0)
3rd_party/android-input/android/frameworks/base/services/input/InputTransport.cpp (+12/-1)
include/client/mir/events/event_builders.h (+8/-0)
include/client/mir_toolkit/events/input/pointer_event.h (+6/-1)
include/test/mir/test/event_matchers.h (+14/-0)
src/client/event_printer.cpp (+2/-0)
src/client/events/event_builders.cpp (+14/-1)
src/client/input/android/android_input_lexicon.cpp (+3/-1)
src/client/input/input_event.cpp (+4/-0)
src/include/common/mir/events/event_private.h (+2/-0)
src/server/input/android/input_sender.cpp (+2/-0)
src/server/input/android/input_translator.cpp (+11/-7)
src/server/input/surface_input_dispatcher.cpp (+3/-2)
tests/acceptance-tests/test_client_input.cpp (+32/-0)
tests/mir_test_framework/fake_input_device_impl.cpp (+3/-1)
tests/unit-tests/input/android/test_android_input_sender.cpp (+1/-1)
tests/unit-tests/input/android/test_input_translator.cpp (+7/-1)
To merge this branch: bzr merge lp://qastaging/~mir-team/mir/relative-pointer-events
Reviewer Review Type Date Requested Status
Andreas Pokorny (community) Approve
PS Jenkins bot (community) continuous-integration Approve
Review via email: mp+264929@code.qastaging.launchpad.net

This proposal has been superseded by a proposal from 2015-07-16.

Commit message

Provide relative cursor axes as a way to allow Unity8 to draw the pointer.
(LP: #1276322)

Description of the change

Provide relative cursor axes as a way to allow Unity8 to draw the cursor.

This is provided in lieu of the full raw events API we have discussed. The raw events API may still come at a later time other use cases. I wanted to avoid hacking up the android input layer too much when we are intending to replace it soon though.

I have a concern with this branch in that it leaks the location of clients in some cases. If a client receives a stream of input events where dx/dy is changing but x/y is constant then they now know they are on the edge of the screen. I wonder if this is a real problem? If so we could only allow fullscreen surfaces to receive relative coordinates...or brainstorm for more solutions!

To post a comment you must log in.
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

PASSED: Continuous integration, rev:2747
http://jenkins.qa.ubuntu.com/job/mir-ci/4326/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-vivid-i386-build/3174
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/mir-clang-ts-wily-amd64-build/27
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-wily-amd64-build/699
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-vivid-touch/3122
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-wily-amd64-ci/475
        deb: http://jenkins.qa.ubuntu.com/job/mir-wily-amd64-ci/475/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/3122
        deb: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/3122/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/5927
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/21891

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/mir-ci/4326/rebuild

review: Approve (continuous-integration)
Revision history for this message
Andreas Pokorny (andreas-pokorny) wrote :

It would be nice to also have a test case that moves the mouse beyond the border of the screen, and verify that even when - from the pov of the pointer controller - the mouse did not move due to the screen boundaries we still send out relative position changes.

From a short dive through our pointer controller - we seem to override that position related filtering.

review: Approve
Revision history for this message
Robert Carr (robertcarr) wrote :

Good idea Andreas I manually tested this but something came up in doing the automated testing! Notably it turns out we are batching pointer events which made verifying large streams of events difficult (e.g. sometimes I would get (0,0) -> (1, 1) -> (2, 2) and sometimes (0, 0) -> (2, 2)).

I've updated the test to feature your suggestion and proposed a dependency branch which ensures only touch events are batched.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches