yashsingh1/xdaforums huggingface dataset:
[Fascinate Android Development] wessiide:
Sorry to be off topic, but this is truly a development thread in every sense of the word and its so beautiful to see considering the influx of noobism in the fascinate forums recently. I imagine that if jts ics development thread on rootz even semi resembled the knowledgeable posts in this thread we may see more progress. Again apologize for interrupting but you guys are the bread and butter of our lil community. Thanks guys.
[Fascinate Android Development] Dj-Dubster_TN:
This is off topic but with that latest Dev build from efpophis my phone is successfully running at 1.7Ghz,and I've never been able to do that it usually freaks out and reboots,and holy hell is it fast,anyways

/resume on topic discussion
[Fascinate Android Development] Tk-Glitch:
Looks like Efpo found the root of many problems ! haha

That's great news. I did search for this for months but never actually found it. Glad to see things getting better :-)

Sent from my Glitched i9k
[Fascinate Android Development] k_nivesout:
I just started to experience some of the phantom presses today, not severely, but it did crop up a couple times. Seems to be greatly reduced though, so I'd think you're definitely on the right track!

Another thing I noticed today were some data issues, but I think that could very well be a rom issue. Although people were talking about some data issues improving with the latest kernels so I don't know.

Finally, I was just wondering if spotty BLN performance was maybe a known issue? Like I said before, I used BLN control to enable BLN so I could change the softkey light timeout, and while since I've had it enabled it's only worked once. Blinky seems to work well, with more control than the BLN control app, but I feel like I had a bit of a battery drain issue with it.

Almost forgot to mention that changing the softkey light timout doesn't seem to stick after a reboot, it goes back to the default 1600.
[Fascinate Android Development] Tk-Glitch:
@ k_nivesout

At a more or less general demand I did remove BLN and add back CM7 LED Notifications on my V14 WIP. It should fix most issues encountered with BLN, and you'll be able to set the timeout through CMParts (it should stick as well). It may come back as an available feature you can enable in recovery or something.

Blinky is indeed hard on battery even if I do like it much ^^
[Fascinate Android Development] k_nivesout:
That's good to hear, I'm actually on MIUI and it doesn't have the BLN-controlling features CM7 does, but I'm assuming that if the issues are to be improved on CM7 the same would be true with MIUI?

I really liked blinky too and it works quite well, just hard on the battery :( And it unfortunately looks like it hasn't been updated in almost a year.

Honestly, the whole BLN thing isn't really a huge deal, especially when you consider all the excellent features and functionality the kernel has! I'd like to show my support, maybe through at least buying the RC updater app, do RCs for the fascinate get put out through that app or is most the support for other devices?
[Fascinate Android Development] Tk-Glitch:
Yeah, blinky is old and seems dead development wise, but well, it does work :p

LED Notifications, even if it's hacky, seems far more stable and I would even say "polished" somewhat. It's now something I'd consider solid, on CM7 and on MIUI. You'll only have to tweak the timeout manually (if needed), using Efpo's "guide".

Yeah I'm proud of the added features in Glitch, and I'm glad my little project found supporters and became what it is today. The small lonely Tk-Glitch dev newbie is now a recognized developer of XDA, part of the Glitch Team !^^ Add to that the team is really made of awesome people.

The source is unified for all the supported devices, so unless device specific changes are needed (CDMA Fascinate is the black sheep here, needing more specific patches than other devices), the support should be more or less equal for all of them. I'm working mostly on what I'll call the "base", used by all devices, and Efpophis, while helping to debug the base and adding new features (and many other things ^^), is doing most of the CDMA Fascinate related stuff. He's the one to speak to if you own a Fascinate (ssewk2x on XDA). Sixtringsg is sometime a bit slow to get the kernels online (from a Glitch fanatic point of view), but nothing too bad :p

I'd say you can expect the same support for all devices in the RC app as of now. We did have issues in the past with Fascinate building, but it shouldn't happen again on CM7 base (we'll see on CM9 one when I'll push it :p) Though, keep in mind RC/Beta access is an added feature, a "thank you" for your support. You aren't paying for a service, it's a donation for the team (you know that probably, but I prefer to say it again).

Sorry for the long message, I think I was in need for speaking ! :D
[Fascinate Android Development] ssewk2x:
Good to see you back, man. I hope you're doing well.

I did get one phantom key-pop on my latest kernel yesterday while driving under a bunch of trees, talking on bluetooth, and trying to get GPS to do its thing, LOL. I guess I was asking too much of my little Fassy. So, the problem isn't solved, just maybe masked somewhat.

I think the data issues are ROM related, and I think it has something to do with the wonky way Verizon handles sms/mms and the phone's routing table. I plan on looking into that after I finish up this whole dpram / keypop BS. It's really funny how one mis-configured pin can cause all kinds of craziness. I'm still not entirely convinced that the fix I've made is "right" even if it does seem to "work." I want to study the code more and figure out what's really going on in there. Once I figure that out, I hope to be able to make the fix more general, especially since Six tells me he gets phantom keypops on his vibrant, too.

On a side note, I think the same block of code I'm fiddling with is what provides a virtual serial port for the ROM to interface with the infamous CarrierIQ stuff. At some point I might see if I can figure out how that stuff works and how we can deal with it, too. Things could get interesting ;)
[Fascinate Android Development] Tk-Glitch:
@ ssewk2x

Thank you I'm not that bad these days !

All of this is really interesting. I do have keypop issue as well on my i9000 but it's VERY VERY rare, even in low reception conditions or under heavy load. I'd say I got it maybe 2 or 3 times since V13 release. I don't have data issue on the other hand, so you're probably right. I'll do some research on this as well and PM you if I ever find something interesting. Really funny stuff BTW :D
[Fascinate Android Development] sbenson1226:
Thank you, thank you, thank you! The 1636 kernel is great and fixed my one gripe about this kernel - the split second soft key timeout. Awesome, thanks again!
[Fascinate Android Development] neh4pres:
Verizon made a statement that they have never used carrier iq.
[Fascinate Android Development] PhoenixPath:
...and none of the "detection apps" have ever shown a positive on my device, regardless of ROM in use.
[Fascinate Android Development] ssewk2x:
Fair enough .. hopefully that's true, and the /dev/ttyCIQ0 device is a bridge to nowhere. It just makes me wonder wtf that's doing there to begin with..
[Fascinate Android Development] xsc0rchx:
I thought Carrier IQ was software, so if you used any ROM other than TouchWIZ then you should no have the application. Cyanogen is straight Android with the exception of some Verizon lib files.
[Fascinate Android Development] PhoenixPath:
You thought correctly, and I've used every rom released for the fascinate barring Enyo's BS.

...but it never hurts to check. :-D. (trust, but verify)
[Fascinate Android Development] sageDieu:
So I just moved from MIUI to ICS and it is pretty awesome. Add myself to that waiting list... I will definitely keep tabs here as usual but I won't be using anything unless I decide I don't like this.
[Fascinate Android Development] ssewk2x:
Well, it's the end of the day again, and I have some more stuff for you guys to try out. I found out today that, because of the way the build system works, none of my dpram changes got compiled in the last few kernels! Oops! This is probably a good thing, because I had screwed up the PDA_ACTIVE pin.

So, I've put the pin back the way it was, added a line of code to make sure it's initialized on startup, and a few other things. For one thing, I removed the /dev/ttyCIQ0 virtual device, so now if there are any shreds of CIQ in our phone, they presumably won't be able to talk to the radio - at least not via that method.

I haven't seen the crazy "out of range" key presses on this kernel yet, whereas by now I think I would have on the other ones .. so maybe that initialization thing did something useful.

I also looked at the whole mms/wifi thing and I think I know what's going on, but I don't have any idea how to fix it. It's a bit trickier than I initially thought, and part of the blame rests squarely upon verizon's shoulders. They have a web servelet page that is needed to send mms messages from these phones - unfortunately, you can only get to it over their 3g network and using their DNS. Other DNSs don't resolve the name correctly. And .. when wifi starts, it clobbers your DNS settings. The reason it works if you send one via 3g first is that the dns and route info become cached. Ugh. This one is a ***** to figure out, if it's even fixable at all.

Anyway .. try this out and let me know about phantom keypresses. Let me know if data stuff gets worse, too .. it shouldn't.

http://dl.dropbox.com/u/28682151/Glitch-kernels/Glitch_Efpophis_TEST_14_dec_2011_1615.zip

Have fun!

Also, please do remember that this isn't an official release and it might break your phone. All I can tell you for sure is that it's been running on mine for about 10 minutes with no problems I'm aware of. If you're not ok with that risk, don't flash it.

Thanks!
[Fascinate Android Development] k_nivesout:
Thanks for chiming in guys, tk-glitch and ssewk2x, it's interesting to hear how things happen behind the scenes with support for multiple devices. It's great to see development continue on this phone, the glitch kernel has really become integral in the enjoyment of my device, and for that reason I had no qualms about buying the app regardless of any fascinate-related development it might give me access to. :)

Quick question for the other glitch users, has anyone been able to get the softkey light timeout settings to stick after a reboot? They always revert back to 1600 for me after a reboot. Also, related to the "green screen of despair", does anyone else sometimes get a quick green flash when turning on the display? It's a really minor concern, I was just curious if others experienced the same thing. Strange cause it seems to just happen randomly.

Edit: Just saw the new test kernel posted, downloading and flashing now, will report back after I get a chance to use it for a bit. Honestly, MMS over wifi isn't a huge issue for me, I haven't even gotten a chance to test it. Really the only time I ever send MMS is when I'm out and about and not on wifi anyway. I can't speak for the other users, but if that particular issue is gonna be a ***** to fix, then ehh... I wouldn't stress it too much :)

The data issues that I get are: 3g slowing down to a crawl, "spotty" performance where it just seems to drop out sometimes (happened on wifi last night for some reason too), and getting stuck on 1x when sending/recieving SMS. I have a feeling these issues are mostly network/ROM related though (I'm on MIUI FWIW).
[Fascinate Android Development] sixstringsg:
I'm betting that you will have to make an init.d script for now.
[Fascinate Android Development] k_nivesout:
I gotcha, I do have somewhat of an understanding about what init.d scripts do, but wouldn't really know where to start on creating a working script. :o

I can patiently wait until there's something implemented that will allow the changes to the bl_timeout file to stick after reboot. No biggie, hell a few days ago, we didn't even have the ability to change the timeout!
[Fascinate Android Development] GizmoDroid:
Or use script manager.

Of course, if you are on cm7, just use settings.

EDIT: just had a phantom key press on the back key on the new test kernel in a low coverage area. Still seems better than before though.
[Fascinate Android Development] k_nivesout:
That's a good idea! Unfortunately tried it out, and always get a "unable to create script" error in script manager when trying to create a script in /etc/init.d

Also - on the new kernel posted today I seem to be getting more phantom presses than with the last few test kernels. It seems to be happening only with the menu button though FWIW, haven't had any back presses or long-presses yet.
[Fascinate Android Development] ssewk2x:
I'm posting this from my basement. Never been able to do that before.. :)

Sorry to hear about the key pops continuing. Ugh! I haven't had a single one so far, even in my basement surrounded by signal blocking metal things. I'll figure it out.

Just out of curiosity, what rom are you on?
[Fascinate Android Development] k_nivesout:
I'm on MIUI 12.9 by RickS. I can't really seem to tell if signal strength is impacting the phantom presses for me, I get pretty decent signal at my house (where I've had the phantom presses so far), I'm rarely in low signal areas to test what difference it would make.

If the data issues that I've experienced are rom related, maybe they're impacting the phantom presses as well? Cause it does seem to crop up more when there is data going in/out.
[Fascinate Android Development] ssewk2x:
That could be...I'll keep working on eliminating the semaphore timeout. That's probably the best best right now..

I'll tell you what, tho .. Having debug output (logcat and dmesg) enabled sure is helping a lot! Thanks for turning that back on, Tk :)
[Fascinate Android Development] neh4pres:
If your 3g icon disappears when in good signal and does it repeatedly throughout the day, then you may have a bad DNS (i believe that's the correct acronym). If so, you will need to call verizon and talk to a level 2 tech. It is caused by a corruption verizon database. They will simply reset it for you.
[Fascinate Android Development] k_nivesout:
I don't so much have an issue with the 3g icon disappearing, one issue is the connection getting stuck on 1x after sending/receiving SMS. The bigger problem is a 3g connection that is unusably slow (like 10kbps).

The phantom presses with the kernel posted today were prevalent enough that I had to revert back to the 12/12 test kernel. It was happening quite frequently and effected both the back and menu keys. I'm not sure why its worse for me on the new kernel, reading ssewk2x's posts, it seems like it should be improved? Strangely enough my 3g speeds have also increased since reverting to the 12/12 kernel, from about 10kbps on 12/14 to a more respectable 550kpbs on 12/12. I think there's a good amount of fluctuation with the 3g network where I live, but for whatever reason, the 12/12 kernel is a dramatic improvement.

Thanks again for the continued work on this guys, and if there's any sort of debugging info that I could get that would help out, let me know.
[Fascinate Android Development] rmtobler:
I'm sure you've already done it but whenever I am getting super sleep well speeds a *228 with both options helps. Seems to need to be done after a kernel or rom flash. Is that others experience or just a placebo effect on my part?
[Fascinate Android Development] k_nivesout:
Not a bad idea, I usually have been hard pressed to notice a difference between PRLs, but I did update just to be sure that on old one wasn't an issue.
[Fascinate Android Development] shag_on_e:
People like you are what it's all about. I'm late to test this yet, but a fresh cm flash, new kernel, and an esn swap is going down right now. Thank you man.

~~~~There is no spoon~~~~
[Fascinate Android Development] ssewk2x:
Ok, my glitchy friends, I have added some code that I hope will cut back on the phantom keypops and get rid of some data droppage, too. Here's what I did:

1. if the keypad driver detects a wonky key press, it will enter "recovery" mode, which basically power cycles the device quickly to jar it back into behaving properly. It's the same behavior that is designed to handle ESD (static electricity) interference with the touchkeys.

2. Also, I found an uninitialized variable in the keypad driver itself, and it was the byte that's used to handle the incoming keycode. I didn't quite see how it could sneak into the input buffer and still contain garbage, but I initialized it to a value that would get caught by the ESD filtering code just in case. That way, there's no chance that a failed read from a spurious interrupt will be interpreted as a keypress. CAVEAT: I did still see some wonky inputs, but they were handled. In this situation, it's still entirely possible that there's garbage coming in that the code simply can't discern from real key-presses.

3. I also added a few more retries to the dpram semaphore stuff. It should be a lot more robust now with a lot less chance of failing to acquire the semaphore. Preliminary observations have not shown any failures.

4. Also made a very minor change to screenstate scaling. It should have absolutely zero impact. Apparently, the sysfs interface I was using to adjust the settings on the individual governors was deprecated. So, I switched to the new interface to squash that warning in dmesg.

Also, I noticed that we fail to apply the gamma table adjustments from the voodoo color app. I think the problem there is an incompatibility between the kernel and the app, and I don't know of a good way to fix it without seriously screwing up the kernel's settings. I did try, though .. the result was a very bright orange / blue mess on my screen, lol!

Also, from now on, I'm going to name the zip files the same in my drop box. That way I save some space, and all the links after and including this one will be the same. I did break the older links just now, tho.

Anyway .. here is this morning's test kernel: http://dl.dropbox.com/u/28682151/Glitch-kernels/CM7Fascinate-Glitch-Efpophis-test.zip

Let me know what happens, plz.

Oh, btw, the source and complete history for all these test kernels is on my github: https://github.com/Efpophis/Glitch/tree/touchkey-exp
[Fascinate Android Development] neh4pres:
I think you numbered wrong ;p
[Fascinate Android Development] k_nivesout:
Nice ssewk2x, thanks for the update!

Seems to be working quite well so far, I haven't got any phantom presses yet, flashed a few hours ago. I'm not sure what you mean by "fail to apply the gamma table adjustments from the voodoo color app" though, it seems to work for me? That is if you're referring to being able to change the gamma settings in the display section of the voodoo control app? I'd be sad if it didn't work though, being able to tweak the gamma settings can make the display look SO much better.
[Fascinate Android Development] ssewk2x:
I'm referring to the section of the voodoo control app that's called "color profiles." The settings there don't apply correctly to the kernel's gamma table.
[Fascinate Android Development] GizmoDroid:
Honestly, I can't remember any kernel that has that implemented, not just glitch.
[Fascinate Android Development] k_nivesout:
Ah yeah, that's right. I remember trying to switch profiles a couple weeks back when I got the phone and noticed that it didn't seem to do anything. Would be cool if it worked I suppose, but I don't really know what I'm "missing" (if anything at all) since I haven't seen what the other profile looks like. Thanks though, at least I know why that setting didn't work!

And it seems like whatever you changed in this last test kernel is working as far as the phantom presses go. Flashed earlier in the afternoon and have been using the phone fairly heavily, haven't experienced any yet. Nice work!
[Fascinate Android Development] neh4pres:
i still have my fingers crossed. Before i flashed this new test i hadn't had any today. After flashing i hadn't had any. Its so hard to tell if something random is fixed by looking only for its absence. But it is raining like a bastard out and absence is what i have. So far... Either way, you are a hero to the fascinate community.

Thanks for all you have done and continue to do.
[Fascinate Android Development] CHANGiism:
I had phantom presses couple times with the newest test kernel but it happens more rarely and whenever I get it, it's not as erratic as before. Before, I would get presses after presses multiple times but now, when it happens I would only get a single phantom press. Data connection is way more solid, thank you.
[Fascinate Android Development] ssewk2x:
Yeah, the problem is that the gamma table that the app stores only has 15 entries. The kernel is expecting 90. They have to line up perfectly, or BadThings(tm) happen. So a fix would be to either have the app expand its table out to 90 entries, or trim the kernel's table down to 15 entries. Unfortunately, I have no idea what any of those entries actually mean, and I do know that screwing with them has the potential to cause some seriously messed up results. Another fix would be to have the app also send which "point" is being updated, and then do a look-up on that point in the kernel table. But, without the code for the app, and with that being Supercurio's domain, I think the best thing to do is leave it the heck alone.

One thing I tried was allowing the 15 entries to be applied over the first 15 entries in the kernel's gamma table. That produced some comical results on my display, to say the least!

Regarding the phantom keypress - I'm going to spend a little more time on this and see if I can find something else that can be fixed. There is something that is a) triggering the interrupt for the touchkey device and b) putting data on the i2c bus that the driver thinks is valid, but actually isn't. The filters I've put in will help, but for those odd situations where the garbage looks valid, it's still going to come through - if I block it, I will also be blocking legit keypresses, and no one wants that.
[Fascinate Android Development] Rick S:
Just in case it helps, I experience these phantom key presses more from undervolting than from low signal areas...maybe voltage is involved too. I used to get them here and there in low signal areas, not very often though. Now that the newer Glitch kernels actually apply the lower voltage settings, I get them more frequently than before when lowering my voltage settings. As long as I don't go any lower than say -75 at lower steps, I haven't gotten any lately...this goes for the last couple test kernels too. Hope this helps.
[Fascinate Android Development] droidstyle:
^i agree with the above post. Seems like if I keep my uv around -50-75 i have absolutely no issues at all.
[Fascinate Android Development] GizmoDroid:
I've been UV -50mV across the board for a few months.

24 hours and zero phantom key presses on the newest test kernel.

Woot!
[Fascinate Android Development] ssewk2x:
Oooooh, that's actually very good information! Thanks given to all 3 of you.

It gives me another place to look. Do me a favor, will you? Experiment with the different leakage levels, too. You can adjust them on-the-fly by doing one of the following in a terminal (or adb root shell):

low leakage: echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/kern_leakage

medium leakage: echo "1" > /sys/devices/system/cpu/cpu0/cpufreq/kern_leakage

high leakage: echo "2" > /sys/devices/system/cpu/cpu0/cpufreq/kern_leakage

That setting will take effect immediately, and it will revert back to whatever you have already configured on the next boot.

If you notice more keypops at a particular leakage, then I'm interested in knowing that. Meanwhile, I'm going to see if I can figure out whytf undervolting would muck things up.
[Fascinate Android Development] neh4pres:
0 pop up on newest test -125 at 100mhz, -100 from 200 mhz- 1000mhz and -75 from there up