Relative Mouse Movement

[MrARM Slack]

Hello,

I've tried to use the requestPointerCapture APIs on Android-x86. https://developer.android.com/training/gestures/movement#request_pointer_capture

While the API doesn't fail, unfortunately the mouse movements aren't relative but absolute. I can reproduce the issue with the basic API demo: https://android.googlesource.com/platform/development/+/master/samples/ApiDemos/src/com/example/android/apis/graphics/TouchRotateActivity.java

This makes the usage of Android-x86 with any games using this API basically impossible. I am really confused why this issue occurs because it works on all my real Android devices with no issues.

Thank you.

[Chih-Wei Huang]

MrARM Slack <mrarm...@gmail.com> 於 2020年2月11日 週二 上午4:18寫道：

That depends on your input device.
What device did you use? Did you test on a VM?

Please provide logcat and result of 'getevent -l'.

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[MrARM Slack]

Hello,

This is an USB mouse. Android-x86 is ran directly on the desktop using an USB stick (I'm not using a Virtual Machine).

Logcat: http://mrarm.io/u/logcat_sample.txt

Getevent: https://mrarm.io/u/getevent_sample.txt

Getevent seems to properly report the mouse movements as relative (I moved my mouse around the center of the screen). The test app's package name is io.mrarm.mctoolbox.myapplication, but it's the demo's code copied over.

[Chih-Wei Huang]

MrARM Slack <mrarm...@gmail.com> 於 2020年2月11日 週二 下午11:39寫道：

>
> Hello,
> This is an USB mouse. Android-x86 is ran directly on the desktop using an USB stick (I'm not using a Virtual Machine).
>
> Logcat: http://mrarm.io/u/logcat_sample.txt
> Getevent: https://mrarm.io/u/getevent_sample.txt
> Getevent seems to properly report the mouse movements as relative (I moved my mouse around the center of the screen). The test app's package name is io.mrarm.mctoolbox.myapplication, but it's the demo's code copied over.

Looks good to me...

Please also show 'dumpsys input'. (by root)

[MrARM Slack]

Hello,

Here's the dumpsys input output from Android-x86: https://mrarm.io/u/dumpsys_input.txt

and here's one from my rooted phone on which the mouse works as expected: https://mrarm.io/u/Paste%202020-02-13%2014-33-29.txt

If needed I can also try capturing these while running an app using relative pointer events, as the Android-x86 one was captured in the Terminal app and the one from my phone via adb on the desktop screen.

Thank you.

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/CAKc24n0TLcWD2jino9Sc_viKs6dD5Ru2fMpccYjs%2BEpfZbZK4g%40mail.gmail.com.

[Chih-Wei Huang]

MrARM Slack <mrarm...@gmail.com> 於 2020年2月13日 週四 下午9:34寫道：

>
> Here's the dumpsys input output from Android-x86: https://mrarm.io/u/dumpsys_input.txt
> and here's one from my rooted phone on which the mouse works as expected: https://mrarm.io/u/Paste%202020-02-13%2014-33-29.txt

According to your previous email of 'getevent -l' output,
the input device is named "Razer Razer DeathAdder Chroma".
Right?

However, dumpsys input shows several input devices
with the same name. Actually the previous one (Android-x86 case)
has 5 devices with the similar name:

Device 7: Razer Razer DeathAdder Chroma Keyboard
Device 9: Razer Razer DeathAdder Chroma System Control
Device 10: Razer Razer DeathAdder Chroma
Device 18: Razer Razer DeathAdder Chroma Consumer Control
Device 21: Razer Razer DeathAdder Chroma

The phone case has

Device 9: Razer Razer DeathAdder Chroma
Device 10: Razer Razer DeathAdder Chroma
Device 11: Razer Razer DeathAdder Chroma

Worse, the previous 'getevent -l' shows 6 devices
with the similar name.

It's confused since I'm not sure
which one generates the input events exactly.

> If needed I can also try capturing these while running an app using relative pointer events, as the Android-x86 one was captured in the Terminal app and the one from my phone via adb on the desktop screen.

Since the input devices order may be changed.
Could you collect 'dumpsys input' and 'getevent -l' at the same time
on both devices?
I'd like to see if they have the same "Classes".

What are the Android version and kernel version of your rooted phone?

BTW, could you share your test app so I can reproduce it on my side?

[MrARM Slack]

Hello,

PC:
https://mrarm.io/u/pc_getevent.txt
https://mrarm.io/u/pc_dumpsys.txt

Phone:

https://mrarm.io/u/phone_getevent.txt

https://mrarm.io/u/phone_dumpsys_input.txt

uname -a on the phone: Linux localhost 4.4.171-KernelX-Oneplus5 #1 SMP PREEMPT Fri Jan 25 17:59:04 UTC 2019 aarch64

Android 9

But to be honest the test app works on just about every Android device I tried on (that are on Android 9 or newer).

Test app:
http://mrarm.io/u/relativemousedemo.apk
http://mrarm.io/u/relativemousedemo.tar.gz (sources)

Both logs were collected when the relative mouse movement was enabled via the test app. The test app is the GL demo from API demos I wrote about earlier.

The Android-x86 logs above are from the Pie public release of Android-x86.

My theory is that the following commit broke relative mouse movement: https://osdn.net/projects/android-x86/scm/git/frameworks-native/commits/4d8be8c1a924093e3b6097dbdde52f61e64b36b6

I compiled Android-x86 with that commit reverted and relative mouse movement events were working fine, though I did not have time yet to try my Android-x86 build with that commit not reverted. If it significantly helps, I can try the custom build without the revert.

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/CAKc24n0quxBnAQczBtYULgfkg6XYFeyH-LUbF%2BY%2BaSds7pX0tA%40mail.gmail.com.

[Chih-Wei Huang]

MrARM Slack <mrarm...@gmail.com> 於 2020年2月16日 週日 上午5:22寫道：

>
> PC:
> https://mrarm.io/u/pc_getevent.txt
> https://mrarm.io/u/pc_dumpsys.txt
>
> Phone:
> https://mrarm.io/u/phone_getevent.txt
> https://mrarm.io/u/phone_dumpsys_input.txt
> uname -a on the phone: Linux localhost 4.4.171-KernelX-Oneplus5 #1 SMP PREEMPT Fri Jan 25 17:59:04 UTC 2019 aarch64
> Android 9
> But to be honest the test app works on just about every Android device I tried on (that are on Android 9 or newer).

Fine. Now I know the correct input device which generates
the input events. (Device 24 in PC and Device 15 in phone)
However, they look all the same in both cases.

> Test app:
> http://mrarm.io/u/relativemousedemo.apk
> http://mrarm.io/u/relativemousedemo.tar.gz (sources)
>
> Both logs were collected when the relative mouse movement was enabled via the test app. The test app is the GL demo from API demos I wrote about earlier.
> The Android-x86 logs above are from the Pie public release of Android-x86.
>
> My theory is that the following commit broke relative mouse movement: https://osdn.net/projects/android-x86/scm/git/frameworks-native/commits/4d8be8c1a924093e3b6097dbdde52f61e64b36b6
> I compiled Android-x86 with that commit reverted and relative mouse movement events were working fine, though I did not have time yet to try my Android-x86 build with that commit not reverted. If it significantly helps, I can try the custom build without the revert.

Ah! I also suspect that. Thank you for confirming it.

The patch was contributed by Jon Doe.
I don't understand it enough.
What I thought is the patch should only affect input devices
with absolute coordinate pointing with wheel.
Such devices are usually used in VMs.
(that's why I asked if you tested on VM the first time)
It should not affect normal mouses.

Dig into the patch, I found a suspicious point:
From line 2871-2895

if (!mParameters.hasAbsAxis) {
...
if (mPointerController != NULL) {
...
} else {
...
}
} else {

Theoretically it replaces the original code from
line 2836-2863:

if (mSource == AINPUT_SOURCE_MOUSE) {
...
} else {
...
}

However, the logic is not the same.
((mPointerController != NULL) vs (mSource == AINPUT_SOURCE_MOUSE))
That's strange.

Since at first the patch was contributed to Android 7.x (nougat-x86)
and then forward ported to Android 8 ~ 10.
I suspect if the forward porting has some issues.
So I checked the patch in nougat-x86:

https://osdn.net/projects/android-x86/scm/git/frameworks-native/commits/6084c3ffaba854080c32edfa77aa616a9fc309b4

Bingo! In line 2639-2666 it says:

if (mPointerController != NULL) {
...
} else {
...
}

That is, it has the same logic as Jon's patch.

So it seems AOSP made some changes but the patch
doesn't consider that. Using 'git blame' shows the patch
in AOSP changed the logic:

https://osdn.net/projects/android-x86/scm/git/frameworks-native/commits/78f97b3263053c388080a738b56499139517c3b6

(see line 2672 after applied that patch)

According to the info, please help me to confirm these:

* Test Android-x86 7.1-r3. I think it should work.

* Apply the following patch to Android-x86 9.0-rc2:

diff --git a/services/inputflinger/InputReader.cpp
b/services/inputflinger/InputReader.cpp
index 810bc56..eabe77f 100644
--- a/services/inputflinger/InputReader.cpp
+++ b/services/inputflinger/InputReader.cpp
@@ -2879,7 +2879,7 @@ void CursorInputMapper::sync(nsecs_t when) {
rotateDelta(mOrientation, &deltaX, &deltaY);
}
mPointerVelocityControl.move(when, &deltaX, &deltaY);
- if (mPointerController != NULL) {
+ if (mSource == AINPUT_SOURCE_MOUSE) {
if (moved) {
mPointerController->move(deltaX, deltaY);
}

(applied to frameworks/native)

It should work, I hope. Let me know the results.

[MrARM Slack]

Hello,

Sorry for the late reply and thank you for looking into this. I tried quickly reviewing the patch earlier but failed to find this inconsistency.

Unfortunately, Android 7.1-r3 does not support the relative pointer API yet. It was introduced in 8.0/M.

I can confirm the patch fixes the issue on 9.0-rc2.

Thank you, I appreciate your help.

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-x86/CAKc24n27NYwXTdu_wwxqErwdJBmq466yqcURA2cfWyXM9cZH8g%40mail.gmail.com.

[Chih-Wei Huang]

MrARM Slack <mrarm...@gmail.com> 於 2020年2月23日 週日 下午7:03寫道：

>
> Hello,
> Sorry for the late reply and thank you for looking into this. I tried quickly reviewing the patch earlier but failed to find this inconsistency.
>
> Unfortunately, Android 7.1-r3 does not support the relative pointer API yet. It was introduced in 8.0/M.
>
> I can confirm the patch fixes the issue on 9.0-rc2.
>
> Thank you, I appreciate your help.

Thank you for the help.
I've applied the patch to our oreo-x86, pie-x86 and q-x86 branches.