Shells that inject user input events need to agree with the system compositor on the clock to use
Bug #1515515 reported by
Andreas Pokorny
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mir |
Fix Released
|
Undecided
|
Andreas Pokorny | ||
mir (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
qtmir (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
If we try to change the input platforms to also use CLOCK_MONOTONIC (or std::chrono:
Mir should provide an interface to the clock used for user input event time stamps - both server and client side.
Qtmir should ensure that it uses the same clock and that dispatch within the qtEvent loop does not cause a mix of used clocks..
Related branches
lp:~andreas-pokorny/mir/use-monotonic-clock-for-input
- PS Jenkins bot (community): Approve (continuous-integration)
- Alan Griffiths: Approve
- Chris Halse Rogers: Approve
-
Diff: 162 lines (+28/-48)5 files modified3rd_party/android-input/android/frameworks/native/libs/utils/Timers.cpp (+4/-30)
src/common/logging/input_timestamp.cpp (+6/-12)
src/platforms/evdev/libinput_ptr.cpp (+13/-1)
src/server/input/key_repeat_dispatcher.cpp (+1/-1)
tests/mir_test_framework/fake_input_device_impl.cpp (+4/-4)
Changed in canonical-devices-system-image: | |
status: | New → Invalid |
no longer affects: | canonical-devices-system-image |
summary: |
- Monotonic clocks behave weird after a wakeup + Shells that inject user input events need to agree on the clock to use |
summary: |
- Shells that inject user input events need to agree on the clock to use + Shells that inject user input events need to agree with the system + compositor on the clock to use |
description: | updated |
no longer affects: | unity8 |
description: | updated |
Changed in mir: | |
status: | New → Fix Committed |
assignee: | nobody → Andreas Pokorny (andreas-pokorny) |
milestone: | none → 0.18.0 |
Changed in mir: | |
status: | Fix Committed → Fix Released |
affects: | qtmir → qtmir (Ubuntu) |
To post a comment you must log in.
Did the above with mako and krillin. The behavior is similar. It results in unity8dash not considering further touch motion input, because the touch events from unity8 are claimed to be to old.