40? odd... It should default to 70 unless you had another init.d script change it.
And it can be changed on the fly.
That is something interesting - Over here in I9100-land there's all sorts of touchscreen fixes and tweaks. In I777 land, the only time people have ever complained about their touchscreen is when running kernels based on I9100 source.
40? odd... It should default to 70 unless you had another init.d script change it.
And it can be changed on the fly.
That is something interesting - Over here in I9100-land there's all sorts of touchscreen fixes and tweaks. In I777 land, the only time people have ever complained about their touchscreen is when running kernels based on I9100 source.
Hah, figures. I'll need to poke around my other tweaks--something is definitely setting it to 40, since my changes aren't sticking. I did hit the bug again, by the way, but I went back and looked at the tsp_threshold, and it was 40, despite the fact that I had manually changed it to 50 before turning the screen off.
Edit: It's not TouchScreenTune, and tsp_threshold doesn't even appear in any of my init.d scripts aside from the one I just created. Nevertheless, every time I turn my screen on, the value is set to 40. I have no idea what could be causing this--what is executed when you turn the screen on?
I'm less sure that it's the threshold then, since something is overriding it anyway, it doesn't matter.
I'm wondering if one of the tweak apps you're using is somehow interfering...
Well, that's why I mentioned TouchScreenTune, as it's the only tweak that I use that (afaik) is doing anything when you turn the screen on. I've turned it off for now, and I will let you know if that removes the issue. My init.d stuff is pretty minimal, no superscripts or anything like that--just the stuff that came with CheckROM (loading cifs, sd readahead, changing nice of kswapd0), plus a tweak for my conservative thresholds.
I poked around a bit more, and it seems tsp_thresholds are set automatically, 40 or 70 when charging, which is consistent with the behavior I'm seeing.
Well, that's why I mentioned TouchScreenTune, as it's the only tweak that I use that (afaik) is doing anything when you turn the screen on. I've turned it off for now, and I will let you know if that removes the issue. My init.d stuff is pretty minimal, no superscripts or anything like that--just the stuff that came with CheckROM (loading cifs, sd readahead, changing nice of kswapd0), plus a tweak for my conservative thresholds.
I poked around a bit more, and it seems tsp_thresholds are set automatically, 40 or 70 when charging, which is consistent with the behavior I'm seeing.
Hmm, good catch there.
I guess the question is whether khartras is also using touchscreentune - if he is too, then it may cause problems when combined with the I777 touch driver - but then why doesn't Siyah also have the same issues (as it seems to have the same code as far as I can tell, with the exception of possibly changing some defaults. I need to take a second look.)
I guess the question is whether khartras is also using touchscreentune - if he is too, then it may cause problems when combined with the I777 touch driver - but then why doesn't Siyah also have the same issues (as it seems to have the same code as far as I can tell, with the exception of possibly changing some defaults. I need to take a second look.)
On I777, the suspend handler gets called later and the resume handler gets called earlier.
Thanks for your patience on this. Hopefully khartras will weigh in whether he is using TouchScreenTune--I haven't hit the bug since turning it off (including turning the screen on a few times for no reason but to check).
I don't totally understand what the data->early_suspend.level means--it seems like you're saying that setting it to the higher value (of DISABLE_FB+1 instead of BLANK_SCREEN+1) changes when the suspend and resume handlers are called? And that timing may be crossing wires with whatever TouchScreenTune is doing and causing the short hang when waking up/turning the screen on?
Edit: yeah, I'm not sure at all. Missed your edit while I was blindly wading through the various touchscreen edits. I guess it's not surprising that it could be a lot of things.
Yeah. During suspend, the handlers are called in ascending order. During resume - descending order. So on I777, the earlysuspend handler is called later and the lateresume handler is called earlier.
Early suspend and late resume are screen off/on - deep sleep is regular suspend/resume.
As to CWM Manager compatibility - After poking at cfroot's initramfs, my head hurts. Do any other custom kernels support it?
Yeah. During suspend, the handlers are called in ascending order. During resume - descending order. So on I777, the earlysuspend handler is called later and the lateresume handler is called earlier.
Early suspend and late resume are screen off/on - deep sleep is regular suspend/resume.
As to CWM Manager compatibility - After poking at cfroot's initramfs, my head hurts. Do any other custom kernels support it?
I see, thanks for the explanation.
I thought Siyah supports CWM Manager, and I'm pretty sure RedPill does too. I haven't used the app except to remove yellow triangles, though, so I can't say I've tested it at all.
Also FWIW (not very much), another hour and a half without hitting the wakeup hang with TouchScreenTune off, but I haven't used my phone much.
Yeah. During suspend, the handlers are called in ascending order. During resume - descending order. So on I777, the earlysuspend handler is called later and the lateresume handler is called earlier.
Early suspend and late resume are screen off/on - deep sleep is regular suspend/resume.
As to CWM Manager compatibility - After poking at cfroot's initramfs, my head hurts. Do any other custom kernels support it?
Redpill and siyah support chainfire's CWM manager app
XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality. Are you a developer?