-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve Delay Time When Using USB HID Keyboard #53
Comments
So you suggesting to have a rooted background process to avoid executing dd? I'm working on a native mode, in which dd is not necessary and Authorizer directly writes to /dev/hidg. This is possible by implementing Selinux rules and change permissions of /dev/hidg device. What do you think? |
I'm sorry for my poor English...I mean, using 'dd' command needs to pass string commands to Shell ,and Shell needs to process string, then transfer the arguments to 'dd' .Then 'dd' start to open InputStream to write data into /dev/hidg and then close the InputStream. The whole process is not effective. I strongly recommend you to check an open-source Android APP named 'Shizuku'. It requires adb or root permission to active, and after that it allows any APP to execute java code or execute native JNI with the UID of 2000 or 0 (depends on whether you active Shizuku by adb or root). It has very low delay. Shizuku launches a background process by 'app_process' command ,and uses Binder to communicate with any APP. The way how APPs receive the Binder is hard for me to understand, but i'm still trying. |
I understood you already in your first post. Did you read and understood my reply? |
echo date +%s%3N; The output of the command above is "1678087807870" and "1678087809667". That means it takes 1797ms to execute 'dd' command for 100 times. The average writing speed is lower than 0.4KB/s. I think almost 95% of time was consumed by unnecessarly steps. I want to let my Android phone become a low delay USB GamePad with Gyroscope enabled. The Gyroscope Sensor in my Android phone has a report rate up to 500 times per second, so I want to find a better way to write data to /dev/hidg . Sorry for my misunderstand of your comment !! |
I deleted your duplicated comment. Okay. I mean at general 17ms for executing dd is not bad if we talking about my general use-case: auto typing of passwords by my other project Authorizer. But of course your GamePad case looks reasonable. As I wrote, I'm working on a native mode, so that we don't need any root process to write to /dev/hidg as the file permissions are set correctly so that Java can directly write to it. What GamePad you would like to implement? Do you consider a specific existing one? |
I think modifing SELinux rules is a very very good idea. It will solve my problem and maybe make your Authorizer's development easier. And may be we can use 'magiskpolicy' command to modify SELinux rules easily (Magisk needed). But I'm not sure whether modifying SELinux rules will cause the Google Play Store to stop working or something. At least I know in China, almost every bank's official APP will detect SElinux rules and if they found any modification, they will stop working and exit. So every time when I installed Magisk on my phone, It takes me a very long time to find ways to hide Magisk, hide Bootloader's state ,hide SELinux modification and so on. That's annoying. I have paid 3$ for a cheap USB GamePad and I wish I could get its specific USB report descriptor. Sence I buy it online, it may takes 2~3 days until I get it on my hand. I will test and send the descriptor, report length, and the structure of report data to you as soon as possibile. I also found the descriptor of a XBox GamePad on a website : 05 01 //0 GLOBAL_[USAGE_PAGE](Generic Desktop Controls) But I can't verify this descriptor, so I choose to wait for my own USB GamePad. |
'dd' command works, but has a bad permformance. I think we can launch a java process using 'app_process' command ,then using socket or Ibinder to communicate with your APP. That will be really fast !!!
The text was updated successfully, but these errors were encountered: