Some people over at the fairphone.com forum reported a "sensitive" screen. They try to tap on a button (or link) and instead of triggering the button the fairphone starts scrolling. My fairphone also shows this behavior and I tried to find out why. Well, after trying for some time I realized that the shorter I tap on the screen the more likely it happens in a swipe/scroll.
So I enabled the "pointer position" option within the developer tools and shot two screen shots. In the first screenshot I tap for round about 500ms whereas in the second screenshot I tried to tap as short a possible. Like you would click with mouse. It show the error pretty obvious. Any ideas how to adjust that?
Hello
I noticed exactly this behaviour on my Fairphone, too.
That's why I started a thread on the official Fairphone website 22 days ago.
I'm not allowed to post direct links here, so I can give you only the head line here:
"Hyper-sensitive-touchscreen"
And on german Fairphone Freunde forum there's also a thread about this problem
Key-Word:
"Empfindlichkeit-des-Touchscreen"
So far, there is not very much response on these threads, but it seems that not all the handsets are affected, because not all of the answers confirmed the problems. One of the guys on fairphone website sent a request to the support team, a few days ago. Maybe he can forward the answer he gets... I'll ask him in his own fairphone thread - "Sensibility-and-reboots"
Unfortunately my phone broke after just one day, so I'm waiting for a replacement now and can't really offer a solution here...
But during the few hours, my phone worked, I entered the engineering mode (by typing *#*#3646633#*#* in the standard dialler app) and there were many options to manipulate the tuochscreen.
Maybe the more experienced guys here in the forum can work out a solution to solve the problem?!
Thank you in advance!
I have the same "hypersensitive screen" issue
Before I was used to briefly and lightly tapping/touching the screen, but with my Fairphone that often gives a scroll signal.
My developer crosshair option shows short lines, the touchpanel behaves as if I first tapped a few centimers away and then a split second later it registers where I actually touched the screen.
I had to learn to firmly tap and hold, otherwise I couldn't select anything on the screen.
It seems a sofware patch for the touchpanel is needed.
-----------------------------------------------
Fairphone FP1
Caju (v.1.1)
Touchscreen settings
I am copying this from the Fairphone forum, for future reference:
My settings, as copied from engineering mode:
tpd_em_log = 0
tpd_em_log_to_fs = 0
tpd_em_sample_cnt = 16
tpd_em_auto_time_interval = 10
tpd_em_pressure_threshold = 0
tpd_em_debounce_time = 0
tpd_em_debounce_time0 = 1
tpd_em_debounce_time1 = 4
tpd_em_spl_num = 1
tpd_em_asamp = 1
NOTE: Do NOT change any of the values (in this case, under Settings). I do not know what they do, really, and how your device might react! I just report mine, for your comparison.
Just FTR, my device works fine!
Any values different from yours? Then I would suggest reporting the issue to FP while including the link to our discussion here, and on the Fairphone forum. If we can narrow down the source of the problem to be caused by some settings, and not your environment or your specific devices hardware malfunctioning, @benkxda could report this to FP in his next mail.
boondiordna said:
I am copying this from the Fairphone forum, for future reference:
My settings, as copied from engineering mode:
tpd_em_log = 0
tpd_em_log_to_fs = 0
tpd_em_sample_cnt = 16
tpd_em_auto_time_interval = 10
tpd_em_pressure_threshold = 0
tpd_em_debounce_time = 0
tpd_em_debounce_time0 = 1
tpd_em_debounce_time1 = 4
tpd_em_spl_num = 1
tpd_em_asamp = 1
NOTE: Do NOT change any of the values (in this case, under Settings). I do not know what they do, really, and how your device might react! I just report mine, for your comparison.
Just FTR, my device works fine!
Any values different from yours? Then I would suggest reporting the issue to FP while including the link to our discussion here, and on the Fairphone forum. If we can narrow down the source of the problem to be caused by some settings, and not your environment or your specific devices hardware malfunctioning, @benkxda could report this to FP in his next mail.
Click to expand...
Click to collapse
I already put a link on fairphone.com to this XDA thread. Thanks for telling! Well, my settings looks identical to yours. I also played around with them. I have no idea if touch screens nowadays need deboucing or sth like that. So I changed these settings a bit...without improvement though. I am also wondering what tpd_em_log is. It is put to 0. I put it to 1 hoping there is some log written somewhere....but i could not find where unfortunately.
Hey there,
I have the same problem and no solution. But here is my input on that issue. Maybe it helps Fairphone when they investigate that issue, maybe not.
hanzano said:
Well, after trying for some time I realized that the shorter I tap on the screen the more likely it happens in a swipe/scroll.
Click to expand...
Click to collapse
I realized the same thing. BUT in addition, I figured out that it has also something to do with how soft you touch. If I try and touch my screen very very gently, I can reconstruct that behaviour every time. If I press a bit harder, it works better.
I attached a screenshot where I did soft touches, and you see a lot of wiggeling especially in the botom row
Yesterday I was annoyed by this issue. I was a bit in a hurry and the Fairphone touchscreen did not react properly
So I just debugged in Android Studio and this is what I logged:
Code:
12:07:48.874 MotionEvent.ACTION_DOWN: 300.44363, 485.4943
12:07:48.886 MotionEvent.ACTION_MOVE: 293.13342, 499.09888
12:07:48.901 MotionEvent.ACTION_MOVE: 293.45657, 497.48178
...
12:07:49.168 MotionEvent.ACTION_MOVE: 293.45657, 497.48178
12:07:49.183 MotionEvent.ACTION_MOVE: 291.2037, 497.48178
12:07:49.198 MotionEvent.ACTION_MOVE: 290.46213, 497.48178
...
12:07:49.403 MotionEvent.ACTION_MOVE: 290.46213, 497.48178
12:07:49.406 MotionEvent.ACTION_UP: 290.46213, 497.48178
12:07:49.406 event.getDownTime: 566
I tapped for 566ms. Pretty obvious that from ACTION_DOWN to the first ACTION_MOVE there is a big delta of ~14px (is it really pixel?) in y-direction.
Hey there,
probably this does not help anyone, but just for the sake of documentation: due to my headphone-jack issue, my fairphone got replaced by a new one. Now it seems that my sensitive screen issue is gone.
I don't know about how many sources you guys have, but if you have the kernel sources, someone could try to implement a filter (and enable debugging logs in the kmsg ofc) so touches under 400ms (just a value for explanation) are only getting registered as touches, but not as movements. However, this could also have some downsides (pretty fast swipes for example), therefore a sysfs option would be a nice idea
But this would at least be a workaround.
Hyst said:
Hey there,
probably this does not help anyone, but just for the sake of documentation: due to my headphone-jack issue, my fairphone got replaced by a new one. Now it seems that my sensitive screen issue is gone.
Click to expand...
Click to collapse
Hmm, ok.Would you mind doing another sreenshot like you did already? Just in order to see the difference.
laufersteppenwolf said:
I don't know about how many sources you guys have, but if you have the kernel sources, someone could try to implement a filter (and enable debugging logs in the kmsg ofc) so touches under 400ms (just a value for explanation) are only getting registered as touches, but not as movements. However, this could also have some downsides (pretty fast swipes for example), therefore a sysfs option would be a nice idea
But this would at least be a workaround.
Click to expand...
Click to collapse
That is what I also had in mind. I already had a look at Xposed framework trying to find out how to "intercept" global touches. With a normal Android Service it is unfortunately not possible at least what I have read so far.
hanzano said:
That is what I also had in mind. I already had a look at Xposed framework trying to find out how to "intercept" global touches. With a normal Android Service it is unfortunately not possible at least what I have read so far.
Click to expand...
Click to collapse
Xposed is a genious piece of work, however, this should be done via kernel.
Maybe @benkxda could have a chat with Fairphone about that?
hanzano said:
Hmm, ok.Would you mind doing another sreenshot like you did already? Just in order to see the difference.
Click to expand...
Click to collapse
no problem. Here you go!
As far as I am concerned I did the same thing. small fast touches.
although sometimes there is a long line, overall a lot less wiggeling.
Hyst said:
no problem. Here you go!
As far as I am concerned I did the same thing. small fast touches.
although sometimes there is a long line, overall a lot less wiggeling.
Click to expand...
Click to collapse
That looks much better than beforehand. I believe the red lines are not of interest. These just seem to be estimations. I had a look into Android source code com.android.internal.widget.PointerLocationView. The VelocityTracker has an Estimator which is drawn in light red. The MediaTek development tool seems to do it similar. So I would only count the green lines.
But I still think that this is not perfect either. I checked with my old Samsung Galaxy Ace and the Android location pointer which really gives points, no line at all when tapping shortly.
laufersteppenwolf said:
Xposed is a genious piece of work, however, this should be done via kernel.
Maybe @benkxda could have a chat with Fairphone about that?
Click to expand...
Click to collapse
I absolutely agree with you that this should actually be done on kernel/driver level. But I have no idea about Android's kernel structure or any driver layer at all. I used the Android SDK though. And unfortunately MediaTek is not giving all sources for the FairPhone
Where exactly do you expect touches to be evaluated and "forwarded" to Android? Do you have some example code of other phones probably? I am just interested how this works in software.
hanzano said:
I absolutely agree with you that this should actually be done on kernel/driver level. But I have no idea about Android's kernel structure or any driver layer at all. I used the Android SDK though. And unfortunately MediaTek is not giving all sources for the FairPhone
Where exactly do you expect touches to be evaluated and "forwarded" to Android? Do you have some example code of other phones probably? I am just interested how this works in software.
Click to expand...
Click to collapse
Sorry for the late answer, haven't seen you post
Well, kernel sources are quite easily structured, you've got the drivers, in there you find the input drivers, in which you also find the touchscreen drivers. in there are several drivers, you then need to find the correct one (in my case it's THIS file). In there are all functions to make your touchscreen work. This device also has a filter for "ghost" touches, just search for it inside this file
So, if you have located the driver of your device, you can there all needed stuff, such as the filter I mentioned
laufersteppenwolf said:
Sorry for the late answer, haven't seen you post
Click to expand...
Click to collapse
No prob
laufersteppenwolf said:
Well, kernel sources are quite easily structured, you've got the drivers, in there you find the input drivers, in which you also find the touchscreen drivers.
Click to expand...
Click to collapse
Ah ok, got it. In folder alps >> kernel >> drivers >> input >> touchscreen there are 68 files.
laufersteppenwolf said:
in there are several drivers, you then need to find the correct one (in my case it's THIS file).
Click to expand...
Click to collapse
Did you forget the link on "THIS" probably?
laufersteppenwolf said:
In there are all functions to make your touchscreen work. This device also has a filter for "ghost" touches, just search for it inside this file
So, if you have located the driver of your device, you can there all needed stuff, such as the filter I mentioned
Click to expand...
Click to collapse
Vielen Dank! Helps a lot
hanzano said:
Did you forget the link on "THIS" probably?
Click to expand...
Click to collapse
Ooops yeah, I did So HERE you go
Hello @Hyst
In the last week I was discussing with the support team pretty intensively about the touchscreen issue.
Now, they asked me to send them my phone, to see what happens on the device.
But, as I'm working abroad, its not that easy for me, to send it soon.
That's why I suggested, they should ask you, to get the IMEI of your old device - as you offered in the general thread.
Unfortunately Rick de Groot (the support guy) asked me again, to ask you for this number...
A little bit strange, but this is what I want to do now
Can you please send your old IMEI number and the RMA (repair form number) to this email:
<[email protected]>
That would be really great!
PS:
My Name is Florian W. if you want to quote me in your email.
Maybe this helps them to relate your email to my support request.
Thank you in advance!
Holzwurm86
Hi @Holzwurm86
sure thing. I've just send them an email.
Holzwurm86 said:
In the last week I was discussing with the support team pretty intensively about the touchscreen issue.
Now, they asked me to send them my phone, to see what happens on the device.
Click to expand...
Click to collapse
Good to see that there is still progress. The list of phones being affected gets bigger at the fairphone.com forum. If the engineers from Kwamecorp or Changhong need help like debugging or logging touches I am willing to help of course.
Related
Hi all,
It seems that certain people (most notably multiple HD2 users) are having crashes and other issues with ArkSwitch. I have a Fuze (Touch Pro), and I'm not experiencing these issues. Therefore, it's virtually impossible for me to fix them.
I ask for your help finding and fixing these bugs, if you have any device that is not a Touch Pro. The source code is available at http://arkswitch.codeplex.com and I would really appreciate some help from any devs that have an HD2 or pretty much any device other than my own.
Let's use this thread to discuss code issues, and the "main" thread for everything else.
Thanks a lot!
Hi ark,
I'll take a look into it (I have an HD2, and sometimes it freezes for me also)
I've coding skills so no worries
See you later
PS. Nice app!
Cool, thanks!
Works fine on my HD
Only crashes when i try to include a image as a selector
hi Arktronic,
I have included ArkSwitch in my ROM v1.8, but have to remove it in next release.
Here are some problems found:
- I have to exclude it from CleanRAM otherwise CleanRAM will take the phone down.
- top taskbar (I'm using WM6.5.5) will be no longer accessible if ArkSwitch has been terminated by other apps (such as Task Manager 3.1, CleanRAM), or sometimes closed by itself.
However, I like the way ArkSwtich "take down" other apps, such as cprog.exe (Phone). It really removes cprog from the memory and free up some RAM without crashing the phone.
Is it possible to make ArkSwitch NOT to stay in RAM?
P/S: Sorry, I'm off topic. You want to discuss coding? Where can I get the code?
If you don't want ArkSwitch to stay in RAM, enable WM65 compatibility mode. Depending on what the user does then, it will either quit or minimize (but be friendly to the system if killed by CleanRAM or others).
Like I said in the first post, the source code is available here: http://arkswitch.codeplex.com/
Okay I did a debug session,
It seems to freeze here:
// Get the window text or else continue enumerating.
if (!GetWindowText(hwnd, WindowTextSb, 1024)) return 1;
in
static int EnumWindowsCallback(IntPtr hwnd, uint lParam)
In some cases the function GetWindowText doesn't return...
If I remove this call, it will load without any freeze
Interesting. Does that happen when there is another app that has frozen, or is it just random?
Maybe I forgot to lock that callback procedure in memory to prevent the GC from moving it around...
Arktronic said:
Interesting. Does that happen when there is another app that has frozen, or is it just random?
Maybe I forgot to lock that callback procedure in memory to prevent the GC from moving it around...
Click to expand...
Click to collapse
Seems that just some apps makes it freeze. I just noticed that an app written by me in c++ makes it freezing every time
If it is closed instead, arkswitch loads up normally.
I forgot:
It is not frozen. But it hosts a IE control in it if that could help.
btw I don't think is a GC problem...
I don't think an IE control would have such an effect. Is it a normal window, and does it have title text?
Arktronic said:
I don't think an IE control would have such an effect. Is it a normal window, and does it have title text?
Click to expand...
Click to collapse
I was searching a way to implement IE Control correctly due to netcf's scrolling bug with it. My exe is a modification of this one http://cid-e91b74403814953e.skydrive.live.com/self.aspx/BrowserWithGestures/BrowserWithGestures.zip which I'm using as support to my main app...
I'll look at that when I get a chance. Thanks again!
Arktronic said:
I'll look at that when I get a chance. Thanks again!
Click to expand...
Click to collapse
I'm going to look again on that piece of your code instead, maybe I will figure it out because it freezes.
I think i found the answer:
Internally, GetWindowText calls SendMessage(hWnd, WM_GETTEXT) to the window.
Since the thread calling GetWindowText (your thread) and the thread that
owns the window are different threads, the SendMessage
internally becomes a PostMessage, which sticks the message in the owning
thread's message queue and blocks until the message is processed by the
owner thread. You are now at the mercy of the owner thread to process that
message. If that thread isn't running a message pump, you're stuck.
Click to expand...
Click to collapse
you should use
SendMessageTimeout(hWnd, WM_GETTEXT, ..., 1000L,...). You'll be blocked for
1 second tops. You can of course send in a longer delay, but 1 second
should be sufficient.
Click to expand...
Click to collapse
Let's fix it
I'll post fixed source as soon as I end.
Wow, great find! I'll change it as soon as I can. This explains why other apps freezing causes ArkSwitch itself to freeze.
EDIT: Oh, if you're going to change it yourself, that works too
Fixed. It doesn't freeze anymore.
I'm doing some other checks, then I'll post corrected source code
w00t! You are awesome
Arktronic said:
w00t! You are awesome
Click to expand...
Click to collapse
I read on codeplex "Removed global memory status information retrieval as a test..."
Why you did so?
Where I need to touch to re enable it?
PS. Thanks, i just like to help
I did it as I was testing various things with Long Zheng to determine why ArkSwitch crashed on his HD2. We seemed to get somewhere with the removal of that, but then it started crashing again. I suggest you just go with change set 44738, as that has the latest stuff in it, except for the unnecessary removal of global memory info.
Arktronic said:
I did it as I was testing various things with Long Zheng to determine why ArkSwitch crashed on his HD2. We seemed to get somewhere with the removal of that, but then it started crashing again. I suggest you just go with change set 44738, as that has the latest stuff in it, except for the unnecessary removal of global memory info.
Click to expand...
Click to collapse
Ok.
Do you know how to detect sliding the finger on listview? I would add a process view which opens on sliding finger from right to left but there is not any mousedown/up event...
I am aware that this has been asked many many times, but i don't see a thread for this issue. I would like to know what attemps have been made to get some sort of support. I am by no means a developer, but i will try my best to get things running. Would it be something as simple as taking a a file out of a current android phone with the same specs and modding for use with a touch pro.
I'm simply curious if there is a thread or website around that discusses this and other issues in more detail.
I'm no kernel hacker, but I am...curious.
That's what i would like to know. facts about how far the development is. Maybe we could start a thread that has such progress stated. Where only the devs would be able to post, so we can have us a look.
The best you can do is read the IRC logs from #htc-linux. I think I recall reading in the logs that klinux had gotten OpenGL working on the Pro2, even with applications like Neocore (thought they're apparently slow).
You have to be a little bit more clear on what you mean by "open gl working".
I'm the developer who was working on the open gl for the klinux build. Bottom line is that open gl is working, but not with hardware acceleration. We used then nexus one drivers (adreno200) to enable things a live wallpapers. But it's so slow its not even worth it.
Now to get hardware 3d working 100%? a lot more work and testing. lol.
Well is hardware 3d working for any of the current android ports in any capacity?
Also, I'm so used to reading hardware specs in Desktop computer form. But with these phones, the only thing I know about them is the CPU manufacturer, model number, and speed.
Is there a separate chipset that handles audio graphics etc, or is it completely SoC.
I read about recent Android ports on the iPhone, and it seems they already have things like external audio working. Is this because the hardware on the iPhone similar to another HTC Android phone, more so than the hardware in the Rhodium?
awesome thread... actually informative and supportive.
i think what the OP is saying is how can us lowerscale highend users be more involved, perhaps in the debugging, data gathering... we could start a -sub group dedicated to each corresponding issues... bill gates didnt invent windows, him and his crew did. the more the merrier eh?
I have a long running reverse engineering thing going on. I have been looking for more info other than IRC. I would like to put my good skills to work w/out starting from scratch. Any info?
EDIT: I did find this, It has some helpful starting info: http://www.androidonhtc.com/wiki/Get_Involved
This is a great thread! I've been wanting to get in on some of this action. Hopefully this will reduce some of the clutter in Reefer's thread.
I meant to get hardware acceleration working. How far has this come along since i posted this??
Only Diamond / Raphael has hardware 3D enabled so far.
Very limited 3D for "low resolution" could be enabled in blackstone or other devices with workaround but that is somehow meaningless.
phh has tried different combinations of memory allocation but in vain.
so am I... given up at the moment.
mcdull said:
Only Diamond / Raphael has hardware 3D enabled so far.
Very limited 3D for "low resolution" could be enabled in blackstone or other devices with workaround but that is somehow meaningless.
phh has tried different combinations of memory allocation but in vain.
so am I... given up at the moment.
Click to expand...
Click to collapse
Phh recommended to trace down mem locations used by wince and that has been done but it still refuses to fire up once pmem.c is modified.
Recently i got the wince dmesg from my rhod in hopes that a cold boot would show as to how the 3d is being activated but that also showed no results. I get this crap when Manila is launched.
[ManilaToday](34156): ### Launching manila ###
23:20:09 [DISP] DrvEscape::HTC_SET_3D_LAUNCHING_FLAG.
I'm not sure what HTC_SET_3D_LAUNCHING_FLAG is.
The next step would be to make an android app and trace down what the hell the libgles_qcom driver is actually doing to see if it is working properly. If you load up ahi2dati.dll on winmo you can actually use the functions to show crap on the screen so i'm hoping the same can be done on android.
Not sure what else can be done at this stage.
[ACL] said:
Phh recommended to trace down mem locations used by wince and that has been done but it still refuses to fire up once pmem.c is modified.
Recently i got the wince dmesg from my rhod in hopes that a cold boot would show as to how the 3d is being activated but that also showed no results. I get this crap when Manila is launched.
[ManilaToday](34156): ### Launching manila ###
23:20:09 [DISP] DrvEscape::HTC_SET_3D_LAUNCHING_FLAG.
I'm not sure what HTC_SET_3D_LAUNCHING_FLAG is.
The next step would be to make an android app and trace down what the hell the libgles_qcom driver is actually doing to see if it is working properly. If you load up ahi2dati.dll on winmo you can actually use the functions to show crap on the screen so i'm hoping the same can be done on android.
Not sure what else can be done at this stage.
Click to expand...
Click to collapse
Ok, i would love to help out as i have never rly done anything like this b4. What exactly are you doing. How do you get HTC_SET_3D_LAUNCHING_FLAG?
How would i open a .dll, i dont think these can just be opened up to see what they are doing. I am on the dark side of the moon here. I know whats going on, but have no clue what to do to help.
garage_man said:
Ok, i would love to help out as i have never rly done anything like this b4. What exactly are you doing. How do you get HTC_SET_3D_LAUNCHING_FLAG?
How would i open a .dll, i dont think these can just be opened up to see what they are doing. I am on the dark side of the moon here. I know whats going on, but have no clue what to do to help.
Click to expand...
Click to collapse
I actually found HTC_SET_3D_LAUNCHING_FLAG on the wince dmesg. You can do this by doing a pwf dump.txt 0x16a00000 0xFFFF0 in haret. I did it after a cold boot to see if anything is done to the gpu once wince boots.
Loading the dll is easy. just make a simple win32 app and do a loadlibrary. This part works but it's not helping on android. I'm interested to see what mcdull thinks since i think he has ventured a lot into this as well. Right now if we can make a simple app in android to load the libgles_qcom.so directly and trace every step, i think that would be helpful to see where we are failing. I'm close to giving up..lol i already took 2 sick days from work to get to where i am now so i could use some help.
Here is what i got out of the chip in wince.
name: ATI HandHeld Interface
versions: 2.07.05110.34681
Revision: 0
ChipID: 1362104322
revisionid: 0
TotalMemory: 15990784
BusInterfacemode: 2
InternalmemSize: 262144
ExternalMemSize: 0
Surface info: 800x480
surface total bytes 768000
dwFrameBufferPhysical=0x14c00780 m_dwFrameBufferVirtual=0x57e00000 dwFrameBufSize=0xbb800
Most people here could probably not help with the hardcore kernel dev stuff, but I guess if you need memory locations or so (be it for opengl/sound etc) I think there a a LOT of people that are willing to run some apps that dump a txt file with debugging info & mem locations to their SD-card and send you that
I would love to help with developing, even if it means that I have to boot into winmo and android all night long and gather certain information, memory-adresses, try different versions of programs with all kinds of parameters etc.
Star-Lite said:
Most people here could probably not help with the hardcore kernel dev stuff, but I guess if you need memory locations or so (be it for opengl/sound etc) I think there a a LOT of people that are willing to run some apps that dump a txt file with debugging info & mem locations to their SD-card and send you that
I would love to help with developing, even if it means that I have to boot into winmo and android all night long and gather certain information, memory-adresses, try different versions of programs with all kinds of parameters etc.
Click to expand...
Click to collapse
We need more devs in general. I ran a trace on a basic app that runs 3d. So there is still a lot of crap to examine.
I'm willing to kill my touch pro 2 and remove the CPU to trace the JTAG locations but I only have the datasheet from the MSM7200/7500, not sure if it will be the same locations. I bet if I hooked up my Segger I could see exactly what is failing on the OpenGL and sound side since alot of hardware debugging is done this way...just sucks I dont know for sure if the pinouts are the same. I'm done it on quite a few different phones and boards over the years so its not a big deal. Omap3430 was simple to trace and the OMAP3530 had the exact pinouts.
BinaryDroid said:
I'm willing to kill my touch pro 2 and remove the CPU to trace the JTAG locations but I only have the datasheet from the MSM7200/7500, not sure if it will be the same locations. I bet if I hooked up my Segger I could see exactly what is failing on the OpenGL and sound side since alot of hardware debugging is done this way...just sucks I dont know for sure if the pinouts are the same. I'm done it on quite a few different phones and boards over the years so its not a big deal. Omap3430 was simple to trace and the OMAP3530 had the exact pinouts.
Click to expand...
Click to collapse
Sounds crazy.. i love it.
I was messing around today and made a small app to load the libgles_qcom.so directly to see if i can replicate my winmo success. Most of the ahi functions are included in the android driver as well except for AhiDispSurfGet which made it impossible for me to draw anything on screen.
The chip did pump out the same info as i posted before and it matches so thats a step in the right direction. Means we can recognize the chip with no problems and all 15.25 memory is reporting as well. If i had more documentation on those functions exported im sure i can get the chip to try to display something directly.
Interesting bit of info I read and perhaps someone can clarify this here. The Sprint Touch Pro 2 uses the Qualcomm MSM7600 processor. The AT&T Tilt2 (GSM phone) uses the MSM7201A processor. The "A" refers to the smaller 65nm die size (I believe).
From what I've read, some changes occurred on the MSM7200 -> MSM7201 due to patent infringements. The next question is, is the MSM7201A and MSM7600 essentially the same chip, just different hardware for CDMA/GSM?
I guess the "libgles_qcom.so" library is used in many other HTC Android phones, but for some reason it's failing on the touchpro2/tilt2, and we're not sure why (although logically it sounds like the library should work as it's used by other android phones with the same chipset)? I'm no kernel dev (I write .NET/c# apps which are much easier than kernel stuff), but am somewhat familiar w/ linux and perhaps can assist in development..
NewbTrader said:
Interesting bit of info I read and perhaps someone can clarify this here. The Sprint Touch Pro 2 uses the Qualcomm MSM7600 processor. The AT&T Tilt2 (GSM phone) uses the MSM7201A processor. The "A" refers to the smaller 65nm die size (I believe).
From what I've read, some changes occurred on the MSM7200 -> MSM7201 due to patent infringements. The next question is, is the MSM7201A and MSM7600 essentially the same chip, just different hardware for CDMA/GSM?
I guess the "libgles_qcom.so" library is used in many other HTC Android phones, but for some reason it's failing on the touchpro2/tilt2, and we're not sure why (although logically it sounds like the library should work as it's used by other android phones with the same chipset)? I'm no kernel dev (I write .NET/c# apps which are much easier than kernel stuff), but am somewhat familiar w/ linux and perhaps can assist in development..
Click to expand...
Click to collapse
learn haret/haretconsole and take a look a the kernel. good place to start. Feel free to come into the irc board if you have any questions
Tada. Here's a little stupid-simple something I made to cure my frustrations.
Whooo. New version, basically wiped up the whole post. Oops.
Anyway, here's orientation lock, an application that, well, locks your orientation. It does this by setting the accelerometer to power state D4, then back to D0 to revive it.
Using DllImport:
Code:
DllImportCaller.lib.StringIntIntCall("coredll", "SetDevicePower", "ACC1:", 1, (int)Phone.Network.WiFi.PowerState.D0);
Simple. Worked on my HD7, Lumia, and Focus. Lmk if you have any issues.
Oh, and known problem: HTC devices detect the accel sensor as active, even when it isn't. Weird. Toggling the button back and forth works, though.
Download: http://windowsphonehacker.com/articles/orientation_lock_release-02-06-12
Cheers!
DeactivateDevice() ACC1: on HTC device will make phone reboot.
ted973 said:
DeactivateDevice() ACC1: on HTC device will make phone reboot.
Click to expand...
Click to collapse
Is that from this application or when you do it using native APIs?
Jaxbot said:
Is that from this application or when you do it using native APIs?
Click to expand...
Click to collapse
oh, i try this before and your app is same result.
DeactivateDevice()
change registry "Dll"
ActivateDeviceEx()
Process above, sometimes works on HTC Device, but it is real "sometimes"!
ted973 said:
oh, i try this before and your app is same result.
DeactivateDevice()
change registry "Dll"
ActivateDeviceEx()
Process above, sometimes works on HTC Device, but it is real "sometimes"!
Click to expand...
Click to collapse
I know you can change it in the registry, but I was hoping for something a little more integrated. I wonder what the deal with HTC is.
Jaxbot said:
I know you can change it in the registry, but I was hoping for something a little more integrated. I wonder what the deal with HTC is.
Click to expand...
Click to collapse
does samsung & lg device have this in registry:
[HKLM\Drivers\BuiltIn\Accelerometer]
"ForegoundModule"="\Windows\TaskHost.exe"
ted973 said:
does samsung & lg device have this in registry:
[HKLM\Drivers\BuiltIn\Accelerometer]
"ForegoundModule"="\Windows\TaskHost.exe"
Click to expand...
Click to collapse
Samsung doesn't, nor does it have all the X Y Z values.
works on focus s, surprisingly....
ManelScout4Life said:
works on focus s, surprisingly....
Click to expand...
Click to collapse
Why wouldn't it? And I saw your comment on Wpcentral, thanks for that. I don't blame anyone, even I get confused with all these different devices and driver versions. Seems only the end consumer has a consistent experience
Jaxbot said:
Why wouldn't it? And I saw your comment on Wpcentral, thanks for that. I don't blame anyone, even I get confused with all these different devices and driver versions. Seems only the end consumer has a consistent experience
Click to expand...
Click to collapse
With all the changes in the gen2 software, I figured it wouldn't work. Just like none of the interop apps work so far I figured this would be on the same boat.
ManelScout4Life said:
With all the changes in the gen2 software, I figured it wouldn't work. Just like none of the interop apps work so far I figured this would be on the same boat.
Click to expand...
Click to collapse
Nah, they don't work because of other changes, but it's a good thought, and I was worried myself. Glad to see it does, though
More specifically, most homebrew interop apps don't work on Samsung Gen2 because they use OEM drivers that are specifically designed to allow apps to do high-privilege things their sandbox normally prevents. In gen2 firmware, Samsung crippled those drivers somehow, locking them down to their own apps only (bears more investigating, but that's the best explanation I've found so far).
This, on the other hand, is simply opening a driver that's built into the phone - all phones, apparently - and is an actual device driver, not a software driver intended forleaving the sandbox. Samsung can't cripple that, or it wouldn't be possible for any app to use the accelerometer. Interop unlock is still required, though - in simple terms, what ID_CAP_INTEROPSERVICES regulates is "Can the app open a direct handle to a driver?" and this app needs to do this.
Update for everyone:
No more interop unlock, now allows toggling. You're welcome =D
http://windowsphonehacker.com/articles/orientation_lock_release-02-06-12
Also a video with my sexy new phone (Lumia 800) in it ^^
http://www.youtube.com/watch?feature=player_embedded&v=7tNiDn-7Szw
Too bad that this can't be put in the Marketplace; it's the kind of app a lot of people have been asking for. All the more reason for Microosft to provide more Chevron Labs unlock tokens, I guess...
EDIT: I guess that having the Sensors capability gives enough permissions to call SetDevicePower on it? I would have expected ERROR_ACCESS_DENIED. In any case, well done. Works on my HD7. One minor bug is that it doesn't remember or detect when disabled, so to re-enable it I have to first toggle to Disabled, then back to Enabled, because when the app is launched it *always* says Enabled. Might be an HTC firmware oddity.
GoodDayToDie said:
Too bad that this can't be put in the Marketplace; it's the kind of app a lot of people have been asking for. All the more reason for Microosft to provide more Chevron Labs unlock tokens, I guess...
Click to expand...
Click to collapse
Exactly. It's harmless, stays at LPC level. Wish Microsoft would let in some more /dangerous/ applications.
Awesome, good job. I've been looking for this. Works well on optimus 7
SetDevicePower really nice solution!!!
One simple fix for HTC, if they always report the accelerometer as available: can you use GetDevicePower? The method signature is the same, except the third parameter is a pointer (which .NET will see as an "out" parameter, if you declare it as such). I'm not sure if DllImport supports those, but it could be done very easily using COM.
Actually, turns out the problem is more universal than I thought. I'll find a fix for it soon, should be simple enough.
Liking this update very much Looking forward to the toggle fix.
Hey everyone, I've been a lurker for quite sometime, so I'm finally posting something. This is isn't in any of the dev sections because this is my first post.
When I first got my GNex (toroplus) was very annoyed with the capabilities of the gsd4t gps chip. Static navigation makes it really hard to use the chip for telemetry projects and the 1Hz position update doesn't give me enough sample data for the things I'm working on. I decided to do some investigation to see if it was limited to the hardware itself or the driver.
I scoured the forum, and tried a bunch of apps, found datasheets and the what not and nothing really improved my situation. I decided to take matters into my own hands and poke around lib_gsd4t.so (stock).
With verbose logging turned on, I noticed an interesting looking entry.
Code:
Hello EE downloder !!!.
{sgee.samsung.csr.com, instantfix.csr.com}, port : 80
Y3Nyc2xsOmROTkw5NnN1, /diff/packedDifference.f2p3enc.ee, format 2
EE_DOWNLOAD: EE_Download_Init done.
EE_Download_Init - returned 0 !!!.
EE_DOWNLOAD: EE_Download_Start successful.
EE_DOWNLOAD:EE_Download_Scheduler started; server_address=(sgee.samsung.csr.com,instantfix.csr.com), port=80, file=/diff/packedDifference.f2p3enc.ee
...
The string Y3Nyc2xsOmROTkw5NnN1 really stuck out to me. The character set fit in the base64 space which for some reason or another, developers seem to think base64 encoded text is somehow a good way to make things more secure. I have seen this numerous times. To me, it just makes it more noticeable that someone is trying to hide something.
So I went ahead and decoded the string and got
Code:
csrsll:dNNL96su
Just to be sure it wasn't some string unique to my phone, I checked where it most likely came from, which is the lib_gsd4t.so and it is indeed there (@offset 0x1b7429).
What's so special about that string?
I'm almost 100% sure that it is the username : password combo for downloading the SGEE data. I'm guessing it is using a post request (anyone wanting to use wireshark to packet sniff this can confirm) because there are extra parameters being used to retrieve the data.
Have I tried to access the file with those credentials?
No.
Why am I posting this?
I thought it was funny that the username and password are hardcoded in the driver and written to the logs. What's the point of having it password protected if you're just going to tell everyone the account credentials?
My actual job involves application security and I used this as an example for the other programmers on my team as to why we shouldn't ever mistake encoding for encryption and if you try to hide something, chances are you are actually drawing attention to it.
Oh also, is anyone interested in knowing more about the library. I have figured out quite a bit
How odd!
If you've figured out the gps drivers maybe you know how to make an updated file to disable static navigation? I op'd this thread http://forum.xda-developers.com/showthread.php?p=38684789 based on the ics version, but would love an android 422 based mod.
I posted my modded drivers. It may also require new configs.
afrotronics said:
I posted my modded drivers. It may also require new configs.
Click to expand...
Click to collapse
Did you ever figure out the proper request? (curl or wget?)
Hi
I have a mysterious problem with one of my applications. For some reason it doesn’t work properly with Samsung Galaxy Tab 2 10' (probably other devices too, this is the only one I’m sure of). Unfortunately I don’t have access to such device and sense I make no money on my application (it’s free) I was hoping that someone here could help me test this .
My application is used for education and is mostly designed to learn foreign languages. One way to practice is to use flashcard that I have implemented in OpenGL. To get this working I render bitmaps with text that is shown on the cards.
One user has reported that this doesn’t work with Tab 2, after a while the text is no longer visible. If the application is paused and then restored it works again. The bitmaps are rendered in a thread and I think that is the problem (if no threads are used it seems to work better). All devices I’m using for testing works fine so I’m really puzzled.
To test this please download and install:
http://www.pekspro.com/vokabelbeta/Vokabel1_13d.apk
Open the application, go to the files and open a file in the examples.
When the file is open, go the the tab Quiz and select Flashcard (3d).
Every second time bitmaps are generated in a thread, other times without any thread. On the top of screen there is some debug text. Please let me know what is says if cards are stopped working. Or even better send me a log from the application.
This feels like a weird request, but please please please help me solve this problem. It literally keeps me sleepless, xda is my only hope .
I can confirm that after a couple of questions, the flashcards go blank.
The debug text doesn't seem to change though
(Alive counter:nnn Duplicate request for: xxx)
It only seems to happen in landscape and it can be cured by rotating to portrait then back again...
In portrait mode the debug in this case is always just 'single thread'.
I would have a go on the emulator set to 10" landscape.
Thank you so very much . This is really interesting information for me.
I have done some testing with the emulator and some other devices but haven’t been to replicate the problem. I have reviewed my code and changed a couple of things that might cause some problems. Do you mind do a second test?
http://www.pekspro.com/vokabelbeta/Vokabel1_13e.apk
Either way I’m really thankful for this
Now the problem is solved. Thanks for all feedback
pekspro said:
Now the problem is solved. Thanks for all feedback
Click to expand...
Click to collapse
OK good to hear.. sorry I didn't notice your second message !