Open levone1 opened 7 months ago
After testing a few different options, I found that with version "MATVT.1.0.7-rs_adbserver_testbranch-main_lab-test25", I can get clicks to work on items that are focused, but nothing else, (as reported by several others).
I noticed that @virresh mentioned in one thread that there may be an issue with gesture api being left out of some devices, and said, "without root level permissions, we may not be able to...". Is there a possibility to publish a root version, or post what possible mods/commands might be able to make it work? My phone is rooted.
Thanks
Hey @levone1
Yes there are a few things that MATVT works with.
When working with adb option, we use adb input to send input events. This is ignored by the system if it reports it doesn't have a faketouch capability (you can check it with the instructions in this thread). If your device doesn't have faketouch, there's no chance of adb inputs working in it's current state.
With root, you have a couple of options. You could flash a rom that supports faketouch (sorry I don't have any suggestions on this since there are a plethora of roms and I usually don't work on rooted devices these days). You could also port back accessibility API and use the main release version. If you're comfortable with coding, you could give special SE-Linux permissions that allow matvt to use accessibility apis even though it's from a different package.
Basically the possibilities are infinite with root access. If you do decide to go down any of these paths, I would be very interested to know the result!
Hey @levone1
Yes there are a few things that MATVT works with.
When working with adb option, we use adb input to send input events. This is ignored by the system if it reports it doesn't have a faketouch capability (you can check it with the instructions in this thread). If your device doesn't have faketouch, there's no chance of adb inputs working in it's current state.
With root, you have a couple of options. You could flash a rom that supports faketouch (sorry I don't have any suggestions on this since there are a plethora of roms and I usually don't work on rooted devices these days). You could also port back accessibility API and use the main release version. If you're comfortable with coding, you could give special SE-Linux permissions that allow matvt to use accessibility apis even though it's from a different package.
Basically the possibilities are infinite with root access. If you do decide to go down any of these paths, I would be very interested to know the result!
Thanks. pm list features
command returns:
feature:android.hardware.faketouch
feature:android.hardware.touchscreen
feature:android.hardware.touchscreen.multitouch
feature:android.hardware.touchscreen.multitouch.distinct
feature:android.hardware.touchscreen.multitouch.jazzhand
I compared output with my BLU phone, which works perfectly with MATVT, and the only thing I see that it has that the TCL doesn't, is "feature:android.hardware.vulkan...(2 variants)".
If it's not the faketouch/touchscreen feature issue, what do you think might be the blockage? DeskDock, and DroidMote both work fine, and function fully, but MATVT and KDEConnect both show the cursor, and successfully accomplish "back" action, but no affect on the screen. Could there be some protocol used or feature enabled in the one, that could be changed in the code of the others? I tried building KDEConnect older versions to test, but the same result.
Hey @levone1
Yes there are a few things that MATVT works with.
When working with adb option, we use adb input to send input events. This is ignored by the system if it reports it doesn't have a faketouch capability (you can check it with the instructions in this thread). If your device doesn't have faketouch, there's no chance of adb inputs working in it's current state.
With root, you have a couple of options. You could flash a rom that supports faketouch (sorry I don't have any suggestions on this since there are a plethora of roms and I usually don't work on rooted devices these days). You could also port back accessibility API and use the main release version. If you're comfortable with coding, you could give special SE-Linux permissions that allow matvt to use accessibility apis even though it's from a different package.
Basically the possibilities are infinite with root access. If you do decide to go down any of these paths, I would be very interested to know the result!
Here's something possibly meaningful - I logcatted while using DeskDock, MATVT, and KDEConnect, to see if any obvious differences/signs, and I don't know enough to know how to interpret thousands of lined of log, but one thing I saw is that the log for MATVT seems to show that as it is being used, it is basically just continually sending whatever keycode is the one set as the boss key. So, I tried setting key to '2', and got a long string of
And setting to 67 gets,
All I was doing during this time was clicking the "OK" button around the screen
Ack I haven't gone through the logs yet, but can you try disabling the untrusted touches on your device - https://github.com/virresh/matvt/issues/55#issuecomment-1356076190
This was a security feature introduced in Android last year and I think it may have been rolled out to more devices.
Tried that already. Tried setting to '0' '1' and '2' - all the same
Thanks
Checked the logs here and doesn't look like the issue is captured in them.
Do you mind looking through the system logs and checking if you see something there?
Ideally should be something with level error or above, but if we don't find anything there, we should check warning level and above.
Checked the logs here and doesn't look like the issue is captured in them. Do you mind looking through the system logs and checking if you see something there?
Ideally should be something with level error or above, but if we don't find anything there, we should check warning level and above.
Thanks.
Sorry, probably wasn't clear - I knew there wasn't an error in the logs, I was just posting them to ask if that seemed normal. What the log shows is the events being sent when I was clicking items on the screen, and it's always just whatever keycode I assigned as boss - that's the only thing the app ever seems to send.
The main problem is that there are no errors that I can see, but you would know better. I will catch a full log, and upload.
Thanks again
Checked the logs here and doesn't look like the issue is captured in them. Do you mind looking through the system logs and checking if you see something there?
Ideally should be something with level error or above, but if we don't find anything there, we should check warning level and above.
So here's logcat "beginning of system" - https://pastebin.com/NKtJUPsR
And here's from when I started using MATVT - https://pastebin.com/4crt8HCT
I don't see anything in the error dept...
Thanks
Short story:
Not working on TCL Flip2. Installs and sets up fine, with all permissions and services checked. Shows up on screen, and scrolls around, but no clicks or scrolls registering anywhere.
Long story: I've used this successfully on at least a couple of phones, (BLU Tank Flip currently), and unsuccessfully on a couple. I have also noticed the same inconsistency of function on other apps of similar function, (KDE Connect remote input, Google Voice Access, et al). I think what I realized is that there is some kind of function and/or property, both in the app/program, and in the phone firmware, the wrong combination of which will cause these things to not register.
For example, on my BLU, which is Android 8.1, I can use the latest Google Voice Access, and KDE Connect remote input, and works perfectly. However, on the TCL, which I think runs Android 12, only the older versions of Voice Access function. The newer versions install, and seem to work/respond fine, but when a command is given, nothing happens. A 'touch' gesture shows on the screen, as if it's trying to swipe/scroll, but the contents of the screen are unaffected. Same with KDE Connect. However, DeskDock works fine on both phones.
I don't know enough to know what it's called, but there seems to be some kind of embedded or specified function or protocol, potentially on either/both the device and the software that makes it able to respond or not. I assume it has something to do with newer, touch screen code, but not sure.
So I'm happy to just report here about my device and your app, but maybe you have some insight about the bigger picture. Is it possible to modify some device property, or maybe code in the app source that makes this work?
Phone is rooted, according to @neutronscott's guide - https://github.com/neutronscott/flip2/wiki
The phone does have a built-in mouse function which can be made to work well, bound to keycode, (my method here - https://github.com/neutronscott/flip2/issues/8), but it has the annoying limitation of being restricted within the boundaries of the status/nav bars. Anyway, I'm fine using it, but, like I said, I'm more curious about the bigger issue/question.
Thanks