Related
TouchLockPro is not exactly new (currently at version 1.9), but it was posted in the Diamond thread, because there things started. But because other phones are also supported, maybe the TouchLockPro thread could move to here. If this cross posting is not wanted, I hope the moderators let me know how to continue. At the Diamond thread or in this one?
But Windows Mobile has an OEM screen locker!
Yes, Windows Mobile locks the screen, but unlocks the Answer and Ignore buttons as soon as a call rings, so it is useless. The same happens when any notification pops up, the Snooze and Dismiss buttons are enabled even when screen is locked, leaving them vulnerable to any accidental touch.
Supported phones (known)
Touch Diamond
Touch Pro
Sprint CDMA Diamond
Touch HD (only triple touch capacitive sensor for unlock does not work)
Summary
There are already a lot of applications to disable touchpanel and/or hardware keys for the Touch Diamond and Pro. I added yet another one:
* lock using the Power button, BattClock and/or Stylus Sensor
* auto-unlock by the Light Sensor
* unlock using triple touch of the Capacitive Sensor
* unlock using Stylus Sensor
* unlock when on AC/USB power
Why is TouchLockPro better than other locking solutions
TouchLockPro is designed not to interfere with running applications and is a multipurpose locking application. Other locking solutions are often specific for locking only incoming calls/SMS. A lot of locking solutions also place a (transparant looking) Window on top of the running application (e.g. slide 2 unlock), so the information of the background application is no longer visible. This is not the case for TouchLockPro, so it can be kept lean and mean. Also the used resources is very very low.
Does TouchLockPro use much battery, RAM, CPU
Not at all, TouchLockPro is designed to be lean and mean!
TouchLockPro does not have noticeable effect on battery life. It only uses 33 Kb RAM in memory, whereas other solutions often use much more. For example S2U2 uses 4 Mb (125 times more) and PocketShield 1.7Mb (50 times more) memory. TouchLockPro uses 0% CPU (check it with a task manager!) and is totally event driven. Polling is kept to a minimum (currently only for polling once per second the light sensor when LOCKED and the screen is on). Requested features which would violate the "lean and mean" principle are rejected. Note that larger UI related stuff is done in a separate TouchLockAction.exe (e.g. editing settings), so the memory is only used when that program is active for a small moment.
Which other solutions exist
This is a list of other solutions, which may suit you better:
* Built in locking of Windows Mobile
* Stylus(BattC)lock
* Get A Reward! Create A "answer Only With Hw Buttons" Option!
* S2U2
* PDAVIET's dialer
* CSDEVCTRL
* SensorLock
* Answerkeys Disabler
* PocketShield
* ThrottleLock
Interested in *FREE* TouchLockPro?
I just posted TouchLockPro version 1.8.
I also posted the source code belonging to version 1.8. Hope you will learn something from it and you are inspired to make great programs too. At the end programming Windows Mobile is not so difficult if you have programming experience. Prerequisites for programming:
* Visual Studio, Express editions are free!
* Windows Mobile 6 Professional SDK (also free)
Note that others pointed out, that Express editions are not suitable for Windows Mobile development. See Smart Development for what is supported by which version. I used myself Visual Studio 2008 Professional SP1.
Note that TouchLockPro is written in C++ and TouchLockAction in C# (and deployed using .NET Framework 2.0).
Enjoy the software and source code
you can lock specific programs? waaahhh? this is what I've been waiting for for a very long time. downloading right now.
lennie said:
you can lock specific programs? waaahhh? this is what I've been waiting for for a very long time. downloading right now.
Click to expand...
Click to collapse
I do not know if HTC x7501 has the same sensor like capabilities. Does it work for you? Or do you have another phone too?
anybody tried with tytan II ?
shuren said:
anybody tried with tytan II ?
Click to expand...
Click to collapse
TouchLockPro uses the unique sensors since Touch Diamond was brought out:
* auto-unlock by the Light Sensor
* unlock using triple touch of the Capacitive Sensor
So probably those functions will not work on your phone. BUT I continue without those functions when the loading of the needed HTC libraries fails.
There is also a stylus sensor, but TouchLockPro just observes a registry key for detecting if the stylus is in or out. So you can check if that registry key also exists on your phone, before you try to install:
HKCU\ControlPanel\Keybd\StylusOutStatus
1 = out
0 = in
If this registry key does not exists, probably TouchLockPro will not work for your phone.
For the rest it is standard Windows Mobile programming, although the locking of the hardware keys may also not work. But the locking of only the TouchPanel should work (setting "LockTouchPanelOnly = 1". TouchLockAction is written in C# and needs .NET Compact Framework 2.0.
Note that controlling the locking only with the stylus is also doable, actually my first version only supported this:
StylusLock
So you could use TouchLockPro with only the Stylus (if that registry key is written) and/or LockTouchPanelOnly, you miss only some of the unlocking features. Actually if you only lock the touchpanel, you can assign the command "\Windows\TouchLockAction.exe unlock" to a hardware key for unlocking.
Hope this helps......
So you say it won't lock some hardware buttons...this won't get around the problem with Samsung i730 and the power off key?
No program I have found yet can lock that hardware key to prevent it from powering off while in my pocket
EDIT: Nevermind...it isn't supported on the i730 anyway
First of all:
Congratulations for your post. Didn't see a long time an informative post like this - your own program is introduced, the reason for doing it AND other existing solutions!!! Hat off to you.
ZuinigeRijder said:
I also posted the source code belonging to version 1.8. Hope you will learn something from it and you are inspired to make great programs too. At the end programming Windows Mobile is not so difficult if you have programming experience.
Click to expand...
Click to collapse
Thank you very much for sharing the source code. It is for sure helpful in both ways - to learn and to get inspired. I already took my hat off otherwise I would do it again.
StrykerC3 said:
So you say it won't lock some hardware buttons...this won't get around the problem with Samsung i730 and the power off key?
No program I have found yet can lock that hardware key to prevent it from powering off while in my pocket
EDIT: Nevermind...it isn't supported on the i730 anyway
Click to expand...
Click to collapse
Actually it does lock ALL hardware keys, even "Power Off" key.
But maybe you meant the "Power On" key (actually, the same key).
That is why TouchLockPro does also lock immediately at Power On or Screen On (due to an external event, incoming call, or via pressing the power on key).
Code:
// --------------------------------------------------------------------------
// HTC Touch Panel
//
// Reverse engineered from HTC's TPEnable.exe and TPDisable.exe
// --------------------------------------------------------------------------
#define IOCTL_HTC_HAL_ENABLE_TOUCHPANEL CTL_CODE(FILE_DEVICE_HAL, 2698, METHOD_BUFFERED, FILE_ANY_ACCESS)
struct STouchPanel {
BYTE n1;
BOOL bEnable;
};
DWORD nBytesReturned;
STouchPanel s = { 0, !disable };
KernelIoControl(IOCTL_HTC_HAL_ENABLE_TOUCHPANEL, &s, sizeof(s), NULL, 0, &nBytesReturned);
But indeed, it will not work on your phone
ZuinigeRijder said:
Actually it does lock ALL hardware keys, even "Power Off" key.
But maybe you meant the "Power On" key (actually, the same key).
That is why TouchLockPro does also lock immediately at Power On or Screen On (due to an external event, incoming call, or via pressing the power on key).
Code:
// --------------------------------------------------------------------------
// HTC Touch Panel
//
// Reverse engineered from HTC's TPEnable.exe and TPDisable.exe
// --------------------------------------------------------------------------
#define IOCTL_HTC_HAL_ENABLE_TOUCHPANEL CTL_CODE(FILE_DEVICE_HAL, 2698, METHOD_BUFFERED, FILE_ANY_ACCESS)
struct STouchPanel {
BYTE n1;
BOOL bEnable;
};
DWORD nBytesReturned;
STouchPanel s = { 0, !disable };
KernelIoControl(IOCTL_HTC_HAL_ENABLE_TOUCHPANEL, &s, sizeof(s), NULL, 0, &nBytesReturned);
But indeed, it will not work on your phone
Click to expand...
Click to collapse
Well right, power off/power on, but when the phone is powered off, I am not worried about it being power on by accident, only the other way around
Why can't any one make a program for WM5 that can disable the Power On/Off key?!?! Ugh!
Finally!
So far, this seems to be the best solution to accidentally pressing hardware buttons or screen buttons while the phone is in my pocket. When using bluetooth I was constantly hanging up on people. Also, I would accidentally call people with the phone in my pocket when an SMS or e-mail would "wake up" the phone and then 2 unknown presses of the hardware "answer" button would first bring up call history and then call the first person on the list. I'll wait a few more days and, if all is well, I'll make a donation. Thank you so much for your effort. (tried Sensorlock, S2U2 and Answerkeydisabler but none did the trick)
mspingeld said:
So far, this seems to be the best solution to accidentally pressing hardware buttons or screen buttons while the phone is in my pocket. When using bluetooth I was constantly hanging up on people. Also, I would accidentally call people with the phone in my pocket when an SMS or e-mail would "wake up" the phone and then 2 unknown presses of the hardware "answer" button would first bring up call history and then call the first person on the list. I'll wait a few more days and, if all is well, I'll make a donation. Thank you so much for your effort. (tried Sensorlock, S2U2 and Answerkeydisabler but none did the trick)
Click to expand...
Click to collapse
I am a bit surprised the other locking solutions do not work well together with bluetooth. Others reported indeed that TouchLockPro does not interfere with bluetooth and you can pick up the phone with bluetooth, although the keys are locked.
Enjoy the software
The other solutions worked with bluetooth but the bluetooth call connection would wake up the phone and activate either the screen, the hardware buttons, or both causing the accidental hang ups or calls. TouchLockPro locks both the screen and the hardware buttons. btw I have the touches set to 2 and the light sensor set to 500. Very convenient!
mspingeld said:
The other solutions worked with bluetooth but the bluetooth call connection would wake up the phone and activate either the screen, the hardware buttons, or both causing the accidental hang ups or calls. TouchLockPro locks both the screen and the hardware buttons. btw I have the touches set to 2 and the light sensor set to 500. Very convenient!
Click to expand...
Click to collapse
Good to know.
In the upcoming version TouchLockPro 1.9 I will introduce the ScreenOffWhenCallConnected option, so you cannot accidently press stuff with your ears. Also I will introduce the option UnlockWhenCallConnected, so you can still use the hardware keys, when the screen is off (e.g. for ending the call) and it is not locked when the call is ended from the other side.
Dependent of the bluetooth usage, if you have the phone in your pocket, you may want to disable these settings.
TouchLockPro version 1.9
I just uploaded version 1.9.2 on my new website.
See TouchLockPro thread for more details.
Many thanks to Dennis van de Sande, alias Mr_Q from XDA-Developers, for sponsoring/donating the website and domain.
I wish you a merry christmas and a happy new year!
Version 2.0
I uploaded version 2.0, which fixes some (small) issues and added some features, like unlocking when sliding the keyboard out (if available). See Version 2.0
[APP][Updated 11-01-2009] TouchLockPro version 2.1
I just uploaded TouchLockPro version 2.1. Hope this version is again more perfect.
TouchLockPro 2.2.1 with GSENSOR support for unlocking
I just uploaded TouchLockPro 2.2.1 with GSENSOR support for unlocking.
TouchLockPro version 2.3
TouchLockPro version 2.3 is available.
How to unlock using touchprolock?
Im using xperia (no gsensor, no light, etc) ??
royalbloodvi said:
How to unlock using touchprolock?
Im using xperia (no gsensor, no light, etc) ??
Click to expand...
Click to collapse
Then you must unlock with a key sequence, using TouchLockPro 2.8.2.
See http://www.zuinigerijder.com
hi
i have a x10 mini, and i have to tell you, i was happy with it, but over and over i get frustrated. first i had the issue with my sim card (cant turn on with sim card on, after i updated the firmware)... and now i've noticed another problem =\
the issue is the following: the accelerometer seems to be way off! when i run games like Speedx, i notice that even with the phone on a 100% leveled support, the controls are off to the right.. this is very annoying
does anyone know of a way to calibrate it ? system wide i mean. some apps allow you to calibrate but it is only relative to the application itself. is there any hack or secret menu??
there is a supposed calibrate for the compass in the service menu, but i do not think it has anything to with it. help please?
no one here had problems with the accelerometer? seriously?
shameless self bump
come on, no one has this issue?
I don't know if we could calibrate the sensor, but you can check the calibration in service menu or install the app "gps status".
This app shows a little yellow circle, this should be nearly in the middle of the circular line). on my mini the y-axis is a little bit off the norm. the apps allows a calibration, but this should only work for the app itself (I think).
i've tried that calibration but i dont think it affects the accelerometer? i think its not the same thing as the compass
I think it should be the possibility to calibrate the sensor, at my aino the accelerometer-x-axis was totaly out of range.
perhaps you can reach more at the sony-ericsson forums.
I have the same question... how hell is it possible to reset or calibrate de accelerometer sensor...
Everything is ok, but i noticed when i use the Google Sky Map app, the horizon isn't flat, it has about 30ยบ of error...
Please, any help?
shameless self bump. last one i promess =p
no one knows of a calibration solution? maybe some messing around with root stuff?
same here, some devices got a global tilt calibration tool, some samsung devices got a command tool called "sensorcalibutil_yamaha"... but i cant find a general tool for the X10 or others devices.
I have the same problem (X10 Mini Pro, 2.1).
How to test: install "My Sensors", select the first AK8973 Compass sensor. Put the phone on a flat surface. Here, Y-Axis is around -5.5 instead of 0.
I found /data/misc/akmd_set.txt but I don't know if changing values in that file (which ones?) will work.
Ok, some more infos I found after testing:
FORM0 fields are when the slider is closed.
FORM1 fields are when the slider is open.
The file can be deleted. It is recreated as soon as an application uses the sensors.
When moving the sensors, new values are written to the file.
there's also a akmd2 file in /system/bin
and a VERY interesting file, named sensors.conf in /system/etc
Code:
# Setup BMA150 axes
bma150_axis_x = 0
bma150_axis_y = 1
bma150_axis_z = 2
bma150_neg_x = 1
bma150_neg_y = 1
bma150_neg_z = 0
# Setup AKM897x axes
ak897xorientation_axis_map = 0,1,2
ak897xorientation_axis_sign = 1,1,-1
ak897xmagnetic_axis_map = 0,1,2
ak897xmagnetic_axis_sign = 1,-1,-1
VooDoo` said:
there's also a akmd2 file in /system/bin
and a VERY interesting file, named sensors.conf in /system/etc
Click to expand...
Click to collapse
Yeah, akmd2 is the daemon that is spawned to poll the sensors. Unfortunately the file doesn't seem to have any correction related settings.
I'm trying to find the source of it but it seems it's proprietary.
Ok, after messing around I found this.
akmd2 has some calibration mode, you can try by running (as root):
Code:
/system/bin/akmd2 -s
There is:
Start Factory Shipment Test
Start HDOE calibration
Start measurement
Start acceleration sensor calibration
I tested all of them but didn't manage to fix anything
whats with these variables in /system/etc/sensors.conf
Code:
# Setup AKM897x axes
ak897xorientation_axis_map = 0,1,2
ak897xorientation_axis_sign = 1,1,-1
ak897xmagnetic_axis_map = 0,1,2
ak897xmagnetic_axis_sign = 1,-1,-1
Axis configures which axis (X, Y, Z) does what (yaw, pitch, roll). The other is if those axis should be inverted (-1) or not.
Sent from my U20i using XDA App
My compass is dead...
Hey, after reading the post, I wanna raise a question about my case: my compass is completely dead: whenever I try to use the "compass.apk" or google map, the compass won' spin, and the head of in the google map turns into a circle, instead of a pointer where you identify your facing direction usually....
after rerooting, unistalling the apps, nothing seems to fix it.
I'm so desperate now, would someone give me some hints? Big thanks!
I had the same problem some months back...the only solution worked for me was to downgrade to 1.6 and reflash the 2.1 firmware using flashtool.....to back up ur data use some app like MyBackup PRO OR titanium backup...and sync contacts with google or take a SE backupandrestore backup.....hope it helps.
Sent from my U20i using XDA Premium App
where's the calibration tool?
i have the same problem here... brand new g2x... one of the very first apps i put on any of my android devices is Screebl.. awesome app that knows how you're holding your phone and then decides whether the screen should be allowed to go to sleep or not.. check it out in the market... there's a free version too.. but i love the app so i paid up...
anyway the settings are way off on the sensor now... and i pretty sure back on 1.6 on my cliq i could do a calibration... but on my G2, and my G2X, i cant find a setting in the phone menu.... and i cant find an app that helps..
I don't have sufficient posts to add a reply to the LMT Launcher thread since it's in the development section, so I'm posting here.
I'd really like to get ISAS working on the EVO 4g LTE, as it's a great feature. Here are my details:
Details
- State: rooted, s-off, TWRP 2.5 installed
- ROM: CM 10.2 nightly (2013-09-01)
- LMT v. 1.912 installed
LMT Settings
- Activate TouchService = on
- Autostart TouchService checked
- Set TouchService mode = Gestures, ISAS, and pie
- Set gesture input = 2 (see below)
- Relevant output of
Code:
getevent -p
Code:
add device 8: /dev/input/event2 # hence setting 2 in gesture input above
name "synaptics-rmi-touchscreen"
[...]
0035 : value 0, min 0, max 1100, fuzz 0, flat 0, resolution 0
0036 : value 0, min 0, max 1750, fuzz 0, flat 0, resolution 0
- Min bbox = 1
- Activation area thickness = 80
- According to the LMT thread, I should divide the max outputs above by my screen resolution (1280 x 720) to get the right x/y % settings for ISAS, which I've done:
--- Touchscreen to screen factor X = 1100 / 720 = 153%
--- Touchscreen to screen factor Y = 1750 / 1280 = 137%.
Lastly, I've set ISA 1 and ISA 2 (bottom left and bottom center) to open Apollo music player just to test things out. I can get it to work, but I have to hold the phone face up with one hand and violently flick the screen up from the bottom left with my index finger to get it to open. It is not a usable gesture in the least. Trying in vain with the speed I can produce with just my thumb while holding the phone produces no result.
Can someone chime in on any settings that might affect this?
Pie works properly, as do gestures (though if I have a gesture like two finger swipe to the left/right, it cycles my homescreen page at the same time as catching that I passed a gesture to LMT), so it would seem that the general configuration is sound. I just can't figure out why I need to swipe the ISA so darn fast. There's no way I could swipe that fast with my thumb; only holding in one hand and doing it at about 70% of my top possible speed gets the ISA to work.
Thanks for any input/suggestions! Feel free to ask for any other output.
jwhendy said:
I don't have sufficient posts to add a reply to the LMT Launcher thread since it's in the development section, so I'm posting here.
I'd really like to get ISAS working on the EVO 4g LTE, as it's a great feature. Here are my details:
Details
- State: rooted, s-off, TWRP 2.5 installed
- ROM: CM 10.2 nightly (2013-09-01)
- LMT v. 1.912 installed
LMT Settings
- Activate TouchService = on
- Autostart TouchService checked
- Set TouchService mode = Gestures, ISAS, and pie
- Set gesture input = 2 (see below)
- Relevant output of
Code:
getevent -p
Code:
add device 8: /dev/input/event2 # hence setting 2 in gesture input above
name "synaptics-rmi-touchscreen"
[...]
0035 : value 0, min 0, max 1100, fuzz 0, flat 0, resolution 0
0036 : value 0, min 0, max 1750, fuzz 0, flat 0, resolution 0
- Min bbox = 1
- Activation area thickness = 80
- According to the LMT thread, I should divide the max outputs above by my screen resolution (1280 x 720) to get the right x/y % settings for ISAS, which I've done:
--- Touchscreen to screen factor X = 1100 / 720 = 153%
--- Touchscreen to screen factor Y = 1750 / 1280 = 137%.
Lastly, I've set ISA 1 and ISA 2 (bottom left and bottom center) to open Apollo music player just to test things out. I can get it to work, but I have to hold the phone face up with one hand and violently flick the screen up from the bottom left with my index finger to get it to open. It is not a usable gesture in the least. Trying in vain with the speed I can produce with just my thumb while holding the phone produces no result.
Can someone chime in on any settings that might affect this?
Pie works properly, as do gestures (though if I have a gesture like two finger swipe to the left/right, it cycles my homescreen page at the same time as catching that I passed a gesture to LMT), so it would seem that the general configuration is sound. I just can't figure out why I need to swipe the ISA so darn fast. There's no way I could swipe that fast with my thumb; only holding in one hand and doing it at about 70% of my top possible speed gets the ISA to work.
Thanks for any input/suggestions! Feel free to ask for any other output.
Click to expand...
Click to collapse
Can you go into debug mode with 777 as described in the op? Then create a logcat containing starting the touchservice, doing some isas and stopping it again? Then just send me the log via pm and I can check what's wrong.
Btw: Min gesture score and min path length are also affecting isas. What did you configure for these?
Sent from my Nexus 4
@noname81: sorry, should have done the logcat from the beginning. I actually did look through it myself and couldn't figure out how to discern what LMT picked up from the unsuccessful ISA attempts. It seemed like it either worked (a line about a trigger event) or didn't.
In any case, yes, I should have just made one, and I'll send it along shortly.
With respect to any other settings, if they aren't mentioned, I left them alone. So min score was at 70% and min path was at 7. I changed the response to a debug overlay and anytime it activates, I've never seen a score of less than 95%. I did fiddle with making it something like 20% and setting the path at 2 to try and make it really easy to trigger; no luck.
I've now restored defaults, so my post is accurate for the logcat coming your way.
@noname81: links to logs sent (appears I can't attach files yet). Thanks for the assistance.
UPDATE 12/21: Fixed, see thread: https://forum.xda-developers.com/ro...ide-asus-kunai-fixes-analog-drift-m1-t4023115
--------------------------------
Kunais definitely have an issue when moving both analogs simultaneously so I've tested EXTENSIVELY and have beaten my sticks to a pulp. If you move one at a time, no matter how hard you go at it, it won't get stuck, but as soon as you move both simultaneously (as anyone would do), that's when it starts going bonkers.
The sticks have no issues when used seperately.
So here is an interesting fact, when disconnecting the left Kunai, the right controller stops altogether. If removing the right side, the left Kunai still works. Also, the left has 3 rows of contact pins, the right has 2.
This tells me the left one should be the "master" of the two and yet, the USB-C is on the right.
Another fact, since these controllers clearly have no communication components (BT and/or Wi-Fi) the input data must travel through most likely a very thin copper wire that is embedded somewhere in the flexible back panel of the case... I'd assume there is one that goes from right to left and then another one from left to right, without looping.
Which brings me to what is definitely the scary part... The problem seems physical... If the data cable is too thin/too long and causing this issue, it will be a nearly impossible fix without damaging the case... Or, it is a software issue which seemingly bottlenecks input data and halts for a second but somehow, I doubt that because if that was the case, right side buttons as well as the right stick could get "stuck".
As it turns out, if you rotate the left stick and push buttons on the right side, a button can indeed get stuck.
Tl;dr - Does anybody have the center part to do some testing?
I feel like that piece is the key to understanding if it's a software conflict or hardware issue.
WhyKlwd said:
Kunais definitely have an issue when moving both analogs simultaneously so I've tested EXTENSIVELY and have beaten my sticks to a pulp. If you move one at a time, no matter how hard you go at it, it won't get stuck, but as soon as you move both simultaneously (as anyone would do), that's when it starts going bonkers.
The sticks have no issues when used seperately.
So here is an interesting fact, when disconnecting the left Kunai, the right controller stops altogether. If removing the right side, the left Kunai still works. Also, the left has 3 rows of contact pins, the right has 2.
This tells me the left one should be the "master" of the two and yet, the USB-C is on the right.
Another fact, since these controllers clearly have no communication components (BT and/or Wi-Fi) the input data must travel through most likely a very thin copper wire that is embedded somewhere in the flexible back panel of the case... I'd assume there is one that goes from right to left and then another one from left to right, without looping.
Which brings me to what is definitely the scary part... The problem seems physical... If the data cable is too thin/too long and causing this issue, it will be a nearly impossible fix without damaging the case... Or, it is a software issue which seemingly bottlenecks input data and halts for a second but somehow, I doubt that because if that was the case, right side buttons as well as the right stick could get "stuck".
As it turns out, if you rotate the left stick and push buttons on the right side, a button can indeed get stuck.
Tl;dr - Does anybody have the center part to do some testing?
I feel like that piece is the key to understanding if it's a software conflict or hardware issue.
Click to expand...
Click to collapse
You are correct, it only happens when using the two jousticks together connected to the phonr case. I have the controller dock and when using it via bluetooth, I am not getting the same issues, i can use both sticks at the same time no problem.
Can we raise this issue to asus? And hopefully it is a software issue which can be fixed via an update.
And just a tip, when you have it on bluetooth mode connected or even the left controller mounted to the phone case, you can also use other gamepads and with the touch control maping. I'm using it together with my xbox one controller this way.
Thanks for your reply @navydragon ! That confirms a thing at least. I would assume that the controller behaves the same while in handheld/controller mode. Not guaranteed mind you.
I am about 90% sure that the case to attach the Kunais run a thin cable, most likely a non-shielded copper one that is protected by the thin sheet of flexible rubber where the phone sits. It can be unglued from the case, which I have not done entirely everywhere but if we feel it slowly with our fingers, we can sort of feel there is a little, otherwise not noticeable, little bump running under that sheet.
That could also be what's causing the issue and quite frankly, I think it is really what is at play here. There is no situations where I couldn't reproduce the glitch BUT by bending the case while trying, it does seem to increase/decrease the frequency or time it takes to create it.
Thanks again for your inputs @navydragon!
Kunai Lag
Youtube video demonstration
[yt]/watch?v=dJfz0UetpuM
My kunai seems to be messed up
Regardless of the game I play, the right kunai controller seems to be broken or something
It's like it gets stuck with buttons being held down
Example, playing Free Fire, I shot my gun, let go of the trigger, yet it keeps firing the gun
I try to turn the camera, the camera keeps turning after I let go??
Call of duty, same issue, it's like the right analog stick is stuck down or something when it isn't
It also seems like half the time I try to aim and the right analog stick doesn't work?
What the hell is going on?
The "lag" seems fixed in the latest CN firmware, I haven't installed the WW firmware yet but I'd assume it fixed it as well. Essentially, the 1.3.9 firmware version for the gamepad will flash on the controller and it fixes the issue.
WhyKlwd said:
The "lag" seems fixed in the latest CN firmware, I haven't installed the WW firmware yet but I'd assume it fixed it as well. Essentially, the 1.3.9 firmware version for the gamepad will flash on the controller and it fixes the issue.
Click to expand...
Click to collapse
Hand/Foot cam of it in action
youtube/watch?v=Up9Qm9qUbgc
Edit: Just got the new firmware, testing now
WhyKlwd said:
Thanks for your reply @navydragon ! That confirms a thing at least. I would assume that the controller behaves the same while in handheld/controller mode. Not guaranteed mind you.
I am about 90% sure that the case to attach the Kunais run a thin cable, most likely a non-shielded copper one that is protected by the thin sheet of flexible rubber where the phone sits. It can be unglued from the case, which I have not done entirely everywhere but if we feel it slowly with our fingers, we can sort of feel there is a little, otherwise not noticeable, little bump running under that sheet.
That could also be what's causing the issue and quite frankly, I think it is really what is at play here. There is no situations where I couldn't reproduce the glitch BUT by bending the case while trying, it does seem to increase/decrease the frequency or time it takes to create it.
Thanks again for your inputs @navydragon!
Click to expand...
Click to collapse
having the same issue, check out my thread https://forum.xda-developers.com/showpost.php?p=81263745&postcount=3
It's honestly ruining my gaming experience
Asentrix said:
Hand/Foot cam of it in action
youtube/watch?v=Up9Qm9qUbgc
Edit: Just got the new firmware, testing now
Click to expand...
Click to collapse
Let us know if it is fixed in the new firmware and let me know what firmware so I can fix this issue too please.
Guide ASUS Kunai Fixes (Analog Drift + M1 as Start / M2 as Select) **ROOT only**
Hello everyone,
I made this thread to address two common issues that some may encounter with the Kunais. Unless there is ever an external updater released by ASUS, the known way to fix the "Right Kunai getting stuck" when in Handheld mode is to either update to CN .63 or WW .64 (it is to be assumed that later revisions should also fix that). When you first boot any of these 2, you'll be greeted with a firmware update for your accessory once connected.
The update should be 1.3.9, that will fix the right side having "stuck buttons" or the "analog drift" that occurs while using the Left side analog. From my personal testing, I was able to rollback to an older firmware with the problem no longer occuring, as long as the accessory was updated to 1.3.9 firmware.
As for the M1 and M2 buttons located behind the Kunais, when using the central unit, they can be used as extra buttons. When used in handheld mode, the hardware values leave you with two buttons that, yes can be mapped, but do not natively act as Select nor Start. That can be a problem in games/programs such as Stadia, Moonlight, or anything that do not let you remap in the software itself.
This can be fixed but will require root access. Assuming that you do:
-open up Root Explorer (quick Google search for "Root Explorer apk" if you don't have it and install that)
-once in Root Explorer, go to the root folder and click on "Mount R/W" it should change to "Mount R/O"
-Go to folder /system/usr/keylayout/
-Hold click on file "Vendor_0b05_Product_4500.kl" and make a Copy in the same folder
-It should create a copy, rename it to "Vendor_0b05_Product_7900.kl"
-Click on file you just renamed and pick "Text Editor"
-Add another blank line under "key 318..."
-Type "key 264 BUTTON_START"
-Enter another blank line
-Type "key 265 BUTTON_SELECT''
-Click on 3 dots top right and choose "Save and Exit"
From there, you can disconnect AND reconnect your Gamepad and your M1 and M2 buttons should now behave as START and SELECT respectively as would any BT gamepad.
If for any reason, that does not work, it is possible the your Kunais revision bears a different Vendor and Product ID. In such case, I would recommend getting any free Gamepad Tester program from Play Store and when testing, most if not all, should give you the name, vendor ID and product ID of your hardware being tested. If these numbers are different than the values in this guide, simply swap the values of the .kl file and that should work.
Cheers!
iBluesurge said:
Let us know if it is fixed in the new firmware and let me know what firmware so I can fix this issue too please.
Click to expand...
Click to collapse
Made a thread there, I can confirm that it is fixed, plus I covered how to fix M1 and M2 not behaving as Start/Select respectively. Cheers!
Your method works to reassign m1 and m2 into start and select, but unfortunately it makes left and right triggers into some key representing (|) for both. If there is a way to fix this then your method would be great. I tested it in a gamepad tester.
Left and right trigger register as key 313 in the gamepad tester.
iBluesurge said:
Your method works to reassign m1 and m2 into start and select, but unfortunately it makes left and right triggers into some key representing (|) for both. If there is a way to fix this then your method would be great. I tested it in a gamepad tester.
Left and right trigger register as key 313 in the gamepad tester.
Click to expand...
Click to collapse
That 313 trigger seems to come from "Keyboard" if anything, I'd assume whichever game you ran tests with probably has AirTrigger or a Gamepad Mapping still functional because that Keyboard trigger for 313 would most likely be something mimicking the touchscreen OR some BT device. But for reference, that is what my .kl looks like.
# Asus Gamepad
key 304 BUTTON_A
key 305 BUTTON_B
key 307 BUTTON_X
key 308 BUTTON_Y
key 310 BUTTON_L1
key 311 BUTTON_R1
key 316 BUTTON_MODE
key 317 BUTTON_THUMBL
key 318 BUTTON_THUMBR
key 265 BUTTON_SELECT
key 264 BUTTON_START
key 158 BACK
key 172 HOME
axis 0x00 X
axis 0x01 Y
axis 0x02 Z
axis 0x05 RZ
axis 0x09 RTRIGGER
axis 0x0a LTRIGGER
axis 0x10 HAT_X
axis 0x11 HAT_Y
WhyKlwd said:
That 313 trigger seems to come from "Keyboard" if anything, I'd assume whichever game you ran tests with probably has AirTrigger or a Gamepad Mapping still functional because that Keyboard trigger for 313 would most likely be something mimicking the touchscreen OR some BT device. But for reference, that is what my .kl looks like.
# Asus Gamepad
key 304 BUTTON_A
key 305 BUTTON_B
key 307 BUTTON_X
key 308 BUTTON_Y
key 310 BUTTON_L1
key 311 BUTTON_R1
key 316 BUTTON_MODE
key 317 BUTTON_THUMBL
key 318 BUTTON_THUMBR
key 265 BUTTON_SELECT
key 264 BUTTON_START
key 158 BACK
key 172 HOME
axis 0x00 X
axis 0x01 Y
axis 0x02 Z
axis 0x05 RZ
axis 0x09 RTRIGGER
axis 0x0a LTRIGGER
axis 0x10 HAT_X
axis 0x11 HAT_Y
Click to expand...
Click to collapse
Would you be willing to show me that left and right trigger still function for you on a gamepad tester? Also I copy and pasted what you have shown and it still shows a keyboard key for left and right trigger in the gamepad tester.
Is it possible to change the right analog sensitivity using this method?
iBluesurge said:
Would you be willing to show me that left and right trigger still function for you on a gamepad tester? Also I copy and pasted what you have shown and it still shows a keyboard key for left and right trigger in the gamepad tester.
Click to expand...
Click to collapse
Uh....That's interesting, it wasn't registering as button 312 and yet, now it does... Both L2 and R2 does it. I'll have to dig deeper and see what causes that but yeah, it seems you are right, there must be a trigger of some kind.
UPDATE: You are absolutely right, it breaks the mapping. I'm working on fixing it, if not in the next hour, it'll be updated in the next 12hours.
Hello, I've tested the WW .64 firmware, and I can confirm that it really fix the issue with the right controller. But im also encountering right now an issue with the right analog. When i gently press the right analog to the left and let it go, it seems like the input doesn't properly go back to the center. I've already tested with the holder directly connected to the phone and it doesn't occur. Can you please also test if it is also happening to your controller? Thanks
@xenken: I might be too tired to read this properly but at least when trying to recreate your conflict, I haven't had any issues as you seem to encounter, but I'll try again tomorrow.
Alright, I will make edits for the guide tomorrow cause right now, I'm exhausted and my bed is calling me. That being said, here is an edited .kl which is, so far, the best compromise I found. All keys work and have values that they should, L2 and R2 can now be mapped independently in ASUS's software but SELECT (M2) does not map any longer.
I get the feeling that some HEX path overlap between keys and is what causes the conflict, I tried many alternatives to no avail.
EDIT: This should be my last edit, I cleaned up what's in the quote. If you copy that precisely, all buttons will behave as expected AND all but "Select" will be mappable in Key Mapping software of ASUS. I've tested in native apps like Retroarch, Minecraft, Moonlight, Stadia App, Stadia through Chrome, PStreamer, etc... Enjoy!
# Copyright (C) 2014 The Android Open Source Project
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# Asus Gamepad
key 264 BUTTON_START
key 265 BUTTON_SELECT
key 304 BUTTON_A
key 305 BUTTON_B
key 307 BUTTON_X
key 308 BUTTON_Y
key 310 BUTTON_L1
key 311 BUTTON_R1
key 312 BUTTON_L2
key 313 BUTTON_R2
key 317 BUTTON_THUMBL
key 318 BUTTON_THUMBR
axis 0x00 X
axis 0x01 Y
axis 0x02 Z
axis 0x05 RZ
axis 0x09 RTRIGGER
axis 0x0a LTRIGGER
axis 0x10 HAT_X
axis 0x11 HAT_Y
Click to expand...
Click to collapse
WhyKlwd said:
@xenken: I might be too tired to read this properly but at least when trying to recreate your conflict, I haven't had any issues as you seem to encounter, but I'll try again tomorrow.
Alright, I will make edits for the guide tomorrow cause right now, I'm exhausted and my bed is calling me. That being said, here is an edited .kl which is, so far, the best compromise I found. All keys work and have values that they should, L2 and R2 can now be mapped independently in ASUS's software but SELECT (M2) does not map any longer.
I get the feeling that some HEX path overlap between keys and is what causes the conflict, I tried many alternatives to no avail.
Click to expand...
Click to collapse
Is this working for xcloud? if so i may have to root my phone or wait for ASUS to fix m1 m2 as start and select which idk if they would ever fix haha
Kunai and mobile desktop dock
Hello everyone! I've got both accessories and they're driving me crazy. I tried to make them work with cod mobile and and the perspective function seems dead. In the main menu when I use the kunai right analog the character moves but in game it's completely dead. When I use the mouse with the dock it goes completely crazy, it stops working every 2-3 seconds. I tried both accessories with pubg and had no issues it works perfectly. Tried to check the Asus forum but no success. If anyone knows the problem and can help me it'll be very nice. Thanks ?
Cod mobile doesn't support Asus Rog 2 kunai gamepad.. Actually COD mobile doesn't support any type of gamepad. That's y you r having this issue. Its not a problem with Asus rog 2.
Sent from my ASUS_I001DE using Tapatalk
have a Firefly AIO-3399j board that I am attempting to run a BOE NV140XTM-N52 display directly from it's eDP interface. I'm a novice when it comes to compiling kernels so I'm having some issues getting this to work properly. I have verified that the physical pinout between the board and the display is correct, and I do get an image on the screen some.
First information about the display from the data sheet. The timing that I see from the display says a 269.5 MHz Clock and the EDID table gives the following information. The clock max is 275.6MHz and minimum is 220.5MHz. Hor Active = 3840, Hor Blanking =160, Ver Active = 1100, Ver Blanking = 48, Hor Sync offset = 48, H sync pulse width = 32, v sync offset = 3, and v sync pulse width = 5. That's where I would assume the following timing would be correct.
hactive = 3840
vactive = 1080
hsync-len = 32
hback-porch = 80
hfront-porch = 48
vsync-len = 5
vback-porch = 40
vfront-porch = 3
Now if I do a cvt modeline calculation I get Modeline "3840x1100_60.00" 353.18 3840 4088 4504 5168 1100 1101 1104 1139 -HSync +Vsync which is completely different on the porches and sync lengths.
Now, onto the board. According to the SDK, the display timing isn't set in the device tree files, it's set in the drivers at /kernel/drivers/gpu/drm/panel/panel-simple.c which I've tried the timing above that I assumed is correct from the datasheet and I've tried the timing from the modeline calculation. I've also put the display timing in the device tree file to see if that would work.
So far, I have gotten to where I get an image on the display and it will flicker from time to time sitting at the home screen of android, but then if I open the app menu, it will flicker even more until I exit it. I've tried adjusting the clock up and down with no resolution, and eventually I will either get a brief image on the screen and then it fades out, or the display will start looking like the porches are completely wrong. The display appears to have EDID information, but doesn't appear to get passed onto the kernel properly.
I've spent several hours recompiling and flashing firmwares to where I'm at a point I have no clue what to do anymore. Can someone help?