yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy SL i9003] dhanaindia:
GT-i9003 Flashed with .PIT and the phone won't start.please help me!

I'm from india and have a Galaxy S GT-i9003 and I decided to flash to DDLF2 (2.3.6) firmware.

I chose to follow these instructions: http://xdaforums.com/show....php?t=1004622

I downloaded Odin and all the relevant files but I stupidly failed to read ahead and flashed with the .PIT file when it was unnecessary.

I then tried to flash with the I9003DDLF2_I9003ODDLF2_INU.tar.md5 file in the PDA slot with Repartition unchecked.

My phone will not start, it just loops through the startup screens.

What is the best thing for me to do now? I still want to flash to DDLF2.

Thanks! :(
[HTC One X] icyzero:
Soo.. it started a while ago, i switch roms alot and i am very cautious when it comes to kernels and i try to flash the right one every time but with the S-ON limitations it has been some kind of confusing

to be exact, i flashed the pokemon rom with the kernel impeded through fastboot

and the proximity sensor is not working (not turning the screen off during calls)

and i flashed bricked, faux and franco's kernels and still its not working

and no its not physically damage because i had IC rom before it and it was working fine

does any one know what is going on, what i might be missing or something i could try

anything will be helpfull

Cheers
[HTC One X] icyzero:
i installed an app called AndroSensor and it said for the proximity sensor check "faliur to start" and then after a while "waiting for event"

if that might help

and the light sensor is "waiting for event" too
[HTC One X] icyzero:
well i solved it.. i dont know what actually happend but here is what i did

first i tried to flash the new franco kernel along with its modules and it didnt work (didnt boot)

so i thought to try not just the stock boot image (as it is provided in the pokemon flasher) but also the stock modules (as i dont own a widnows i cant just run the script file)

i unzipped the franco modules, replaced it with the stock modules and repacked it, flashed the stock boot.img in fastboot, flashed the repacked modules from the recovery and i got the proximity and the light sensor working again :D
[HTC One X] Faith996:
could you please help me, my proximity sensor is not working at all...and i dont know why, i changed the kernel and the modules and it havent come back..., the light sensor is working well
[HTC One X] Marc199:
I have the same Problem. Light Sensor is working. Proximity Sensor suddenly stopped working. There is no reaction when i use z-device test. The weird thing is, it passes the HTC function test and the red light turns on when i try to get a reaction of it in z-device test. It seems to work somehow but is not reacting to movement. I hope there is a fix for that. I don't want to send it in for the 6th time.
[HTC One X] Marc199:
So it seems that my proximity sensor is not broken. It just needs very high brightness values to work. So in a dark room it won't work. Is there a way to calibrate the proximity sensor?
[HTC One X] giustanca:
Even I have the problem of non-operation of the proximity sensor and light sensor lenses. After various tests and seen several videos, I realized that the problem is in contact with the sensor to the motherboard. Pressing close to sensors, close to the camera (back) everything returns to normal ...

Sorry for my English ...
[HTC One X] peedub:
I know this is an old thread, but I'm having the same problem as guistanca. Thought it was broken, but squeezing the phone made it burst back to life... dodgy?
[HTC One X] Dslike:
Same problem like giustanca and peedub, any ideas,? It is hardware issue or it can be fixed by some software modification?
[HTC One X] teejayd:
Ik have the same problem sinds a month, pressing the screen on the upside wil help to get the sensor to work again.

For me it's a hardware faillure i think.
[HTC One X] Dslike:
Exactly my situation but when I press screen on the upside it help but just for I whine, few second and sensor didnt work again. I will wait for new official Jelly update 4.2. and if problem will be still remain, probably I will send my One X to service.
[Samsung Epic 4G Touch] livexunit:
Ok, I have done a few searches but I have yet to find someone MOD this sucessfully on the Epic Touch. I know im not the only one but does anyone thin they can re map the "search key" on the Epic 4g Touch to the ICS (not Gingerbread) resents. This guy here got really close,

http://xdaforums.com/showthread.php?t=1558220

and whats best about it is that it could literarly work on ANY ROM however... it toggles the Gingerbread recents. Anyone up to tweak this please???
[Samsung Epic 4G Touch] collinsac24:
a little old but im also looking for something like this, launchkey doesn't work or at least the lite version doesn't for what I want and im unable to find the full apk anywhere.

---------- Post added at 12:05 AM ---------- Previous post was at 12:00 AM ----------

button remapper that was posted in thread provided by op allows me to almost achieve what i want but instead of having to hold the search key id like to be able to just tap it.
[Galaxy S III General] azsamsancho:
Hi all,

I am about to buy a new phone in the next month or so. I have been following the new phone release and seems like HTC One X and S III are the ones I am considering. I have had galaxy S for 2 years and it is time to upgrade.

I really like the solid design of the One X, it looks better, feels sturdier.. And my question is, if I am going to put custom ROM on my phone, why should I choose S III over the One X -- I am strictly speaking about the international versions here? My only strong point for the S III is the bigger battery.

I do not know if I can post the same thread over the HTC sub-forum, but I would like to get the opinion of both parties :)
[Galaxy S III General] g4rvd4:
Replaceable battery, extendable memory..

And unlocked bootloader.

For starters..
[Galaxy S III General] azsamsancho:
OK, I do not really care for replacing the battery. It is annoying. I like the phone to last one full day with average use (no games and stuff). If it can last one day, I am fin with recharging overnight.

As far as memory, I will also be fine with 16 GB, so extendable slot is also not an important point for me.
[Galaxy S III General] veyka:
Comparisons should go here

Search before posting in future.

Thank you.
[Android General] dkotoric:
seriously didn't know the CM team owed you anything. They can do whatever the hell they want. Its your choice what you want to support or not.
[Android General] codf4ther:
I'm sympathetic to your situation, and I understand the frustration that must cause you as a developer. As and end-user no one wants a situation where there are multiple GUI tools that are incompatible. You shouldn't use terms like "ripped-off" though as it implies theft. This is GPL code, as long as the cyanogenmod team are releasing their code and changes back to the community they aren't doing anything wrong (annoying maybe).
[Android General] ljordan2:
Well CM team aren't doing anything illegal, but what they are doing is just wrong. Taking a dev's work and turning it into their own work without permission and cease support on the original work. That's plain wrong...
[Android General] blowtorch:
Why not adopt CM's sysfs interface as a standard? Then either the kernel apps or rom control can both control the kernel? Isn't that best for the community?

I remember when we never had to pay to control our kernel, now you are basically forced to buy the kernel apps ... Doesn't forcing users to buy separate apps actually hurt the community and foss?

I have no problem with supporting the great work of rom or kernel developers but, I would rather donate to a dev than be forced into a market app to control the kernel.

I have bought Franco, GLaDOS and Trinity apps btw. ;)
[Android General] mdfzhi:
ummm this wasnt about permission, furthermore the code is gpl, dont need permission as long as they obey the licence and release source. the case here is fragmentation caused.
[Android General] Ezekeel:
I never said they stole something nor that they did something illegal. I am just describing the consequences of their decisions which is hurting independent devs and the community for the sake of saving some work for the CM team devs. And hurting others out of laziness is wrong in my book.
[Android General] phone_user:
I remember the different Voodoo and BLN sysfs in NS CM

and Color Control for GN

The Kernels using Ezekeel's Color Control

GLaDOS / franco / Trinity / Lean / Popcorn / Air

vs

The Kernels using CM's Color Control

CM / CMPlus / faux123 / JameBond / FuguMod

serious disruption! :(
[Android General] JS0724:
+1 Sounds like a format war to me. If there's no disadvantages to their implementation than I don't see what the big deal is.
[Android General] blowtorch:
All users across all devices would benefit from using CM's kernel standard
[Android General] nexus.prime:
Come on, guys :(

If CM team set their sysfs, the original dev should modify his own?
[Android General] franciscofranco:
Read the post again please.
[Android General] peterperfect:
They doesnt have to modify. Only if they want to merge things into CM. You cannot suppose that CM has to change their standards to adapt to other devs.

Its like Samsung asking AOSP to change their code standards to adapt to Touchwiz.
[Android General] hengsheng120:
I'm not sure what to say about this but it's reminiscent of the Ultimate Droid drama. It does sound like that they do not want anyone 'in their way'.
[Android General] zelendel:
CM roms have always been about do things their way. It is not a surprise if they decided to do it their way. They only support their coding. If you don't like something in their kernel then its simple. Don't use it as a base and build your kernel and rom from the AOSP source code.
[Android General] ingenious247:
According to what the OP stated, if this is true, then CM is no better than Microsoft, Apple or any other "evil" empire (Samsung?) that tries to lock down code for their own purposes while "borrowing" the work of others.

This is the opposite of Open Source mentality, they are creating a new "proprietary" standard. Similar in ways to what Samsung is doing with Tizen. Google it.
[Android General] nexus.prime:
We does not live in a world where the strong prey upon the weak.

Android is people's OS!
[Android General] espenfjo:
Do note that these changes were opensource. Interfaces were open, and this was done to work for hundreds of devices for millions of users (Yeah.. CM is that big.).

Also, if these re-implementations were not limitations of the original work, why not adapt? Code that works for hundreds of devices are surly better than code working for just one? No?
[Android General] chadouming:
That's not how it work. To explain simply : Dev make some work in their kernel. CM team see it's usefull and worth to use it and take your work, adapt it to their "Standard" and add it to their kernel. Now you have two implementation for the same thing. Now, either the Dev has to make is whole code again to fit CM or leave it like this.

Now this tell us that it's not because the dev work against CM "standard", it's because CM changed is work and community "ask" them to use the CM way saying it's how it should have been done first. There is definitively something wrong here.
[Android General] blowtorch:
that's what i'm sayin
[Android General] espenfjo:
Why not just take the code that CM already adapted?

CM took the code and adapted it something that will work for more devices, and more users? Bad, how?
[Android General] chadouming:
That's still asking to devs who made a working code to change it.
[Android General] peterperfect:
They are not asking nothing. From where did you take that? Devs are free to adapt or not if they want.

Chad, if you do your opensource work and I want to collabo with my patch is it fair to me to ask you to change the way you do it so i can fit in?! cmon...
[Android General] espenfjo:
If it is for a greater good, why not?

Their only loss will be 5 minutes of merging code.

Their gain would be that their code is usable by thousands of more people.
[Android General] jeagoss:
It would seem that CM is now in an impossible place. If we want to implement a tweak, we will have to do it in a device specific way that creates more maintenance. This is due to the fact that we cannot re-implement a tweak without harming the community.

Since we cannot re-implement a tweak, and we don't want the added overhead of per-device maintenance of a tweak, we are going to have to take the position of never taking in a tweak.

We thought that users had choice with CM. They can install other kernels as they wish. We even went to the extent of making it so CM gets out of the way when other kernels are installed and allows other software to control that kernel.

But, this does not seem to be good enough. We put in what we thought was our best effort. Apparently, we were very wrong. Our best effort would have to be to maintain a very large overhead in order to not harm our community. We elect to not take this route.

From this point forward, CM will not be taking _ANY_ patches from the community. If a feature is liked by a user, it is now on the user to contact the author to submit the feature to CM's gerrit instance. This should prevent any 3rd party harm.
[Android General] hengsheng120:
The problem is that they may not want independent devs to use their work freely and yet they want to implement others' work into cm without regard. This makes it very difficult to completely optimize roms for specific devices. Fragmentation is almost necessary and perhaps unavoidable when you have so many different different devices to tweak for.
[Android General] StringBlade:
As I read it, the problem is greatly about the scope of CM's adoption. If there wasn't such a large installed base (possibly one that dwarfs the original dev's installed kernel base) then changing the dev's work wouldn't be such a big problem (though it certainly still would exist).

Here's the problem stated in slightly different terms (as I've read it):

Independent kernel dev makes a tweak (new functionality) and it is written to uses sysfs interface A

CM dev team likes the tweak, but their internal kernel standard is to use sysfs interface B

CM devs take the original tweak and re-implement it to use sysfs interface B instead of A (completely legit in terms of GPL)

CM kernel now has the original dev's tweak with an incompatible interface from the original dev's kernel which means dropping the original dev's kernel into CM will result in the GUI controls not working unless the original dev does one of two things:

change his original kernel tweak to use sysfs interface B (because then all CM users can use his kernel and the CM controls), or

create his own competing GUI controls that must be installed to control the dev's original kernel on sysfs interface A

Hopefully you can see how this puts a burden on the original dev especially if the tweak is a popular one that simply doesn't work on CM using the original dev's kernel (because the CM controls use interface B).

Is it possible for CM to write their controls such that upon detection of a 3rd party kernel it uses an adapter layer to talk to the kernel for the tweaks they modified?

Put another way: If CM takes a tweak and changes the interface for their kernel, they should also create an adapter for the original kernel on the original interface so when that kernel is substituted for the CM kernel, the tweak can still be controlled in CM's GUI. It seems to me to be the least they could respectfully do to maintain CM compatibility for the original dev's kernel while still modifying their kernel to use a consistent sysfs interface.

Yes this adds some bloat to CM because you have adapters hanging around for kernels you don't actually have simply because tweaks were re-implemented from them. But in the grand scheme of things this seems fairly minimal and would allow the original kernels to continue to work in CM without forcing the original devs to change their interfaces or to field support questions from CM users. :confused:
[Android General] chadouming:
As i said if you would have read correctly, community is asking them to change their work. I follow a lot of kernel thread and i saw it often.
[Android General] zelendel:
While this maybe the best option for the CM team it is a shame that it has come to this. All over 3rd party app control. Personally The CM team did everything they could to make the OP happy. They made it so if another kernel was installed then the CM settings would take a back seat to whatever pointless GUI app was made for the kernels settings, but this didnt seem good enough. Sad really
[Android General] ellesshoo:
Unless I'm not understanding you correctly, it has been repeated many times in this thread and with links from this thread that CM already disables it's controls when a 3rd party kernel is installed, thus allowing the third party control app to control the kernel tweaks. I for one can't understand why this isn't acceptable to the outside kernel devs, but I'm nobody.
[Android General] cyanogen:
^^^ This. CM is a massive project. We have to support an obscene number of devices and therefore we have some different considerations. Basically what's happened here is that CM took some GPL code, made it better so that it scales, and pissed off the author because he didn't want to accept our changes for no good technical reason that I can find. Had this been a feature that went thru our normal code review process, it would have been correct from the beginning.

I suspect that this feature was never meant by the author for mass adoption, but rather to be used with a proprietary tool that costs money for a specific device in a specific way. Perhaps the GPL is getting in the way there.

I can personally attest to the CM team going above and beyond to try to rectify the situation, and I stand by my team on the decision.
[Android General] ogdobber:
this is sad
[Android General] BorrowADolla:
Its about to go down roight neow. He said the 'P' word, that just happened.
[Android General] blowtorch:
yep well said ...
[Android General] franciscofranco:
No no and no. Don't go all pretty just because this is a bad situation for CM credibility. We don't care about credits or whatever most of the people here think we are babbling about. We just want you, CyanogenMod team, to fix what you broke. We had an interface created in the first place (in this case Ezekeel did it), you decided to come, take it (which is perfectly legal and awesome because it's just a great interface), but then decided to change how it work, breaking compatibility with all the kernels that were already sporting the initial implementation. It was just as easy as creating symlinks like it was explained by us in private. Or better, how hard it would just to stay with the initial implementation to avoid fragmentation?

I thought CM's goal was to unify Android and get rid of the fragmentation that is created by the manufacturers, not create even more fragmentation. I thought we were here for the community sake... I guess I was wrong.
[Android General] cyanogen:
It's not, really. We've largely stopped the process of just pulling in code that we thought was cool without going thru the normal code review processes. Unfortunately, it still happens with kernels because the workflow is a bit different (mostly because of frequent large upstream merges). All Jef is saying is that instead of us just pulling your code into some device-specific repository, we'd like it to go thru our code review process and be submitted by the developer. This will subject it to a higher level of scrutiny and have a better chance of not only building a better relationship between CM and the developer but producing better code. It's just how we do things already.

The good side of this is that it's been beneficial for us as a team internally. We've closely examined how we interact with external teams and created policies around it that will help us grow. Unfortunately we ran into a dead end on this issue :(
[Android General] zipredictive:
Ok Im a noob and I cant understand many things u guys wrote but...

I know its not the way android community works but....

what happens if independ.devs close their work so cm cant mod it for their "interface"? Can they do it?

I mean....

Kernel or other independent Dev: "can you please revert the changes?"

CM: "No we won't do it we take your tweaks that are very good ;) and we re- implement them under incompatible interfaces"

Dev:"Ok from now on you cant take my tweaks cause they are closed you forced me to do it".

Maybe its the only way to make people think.... and being grateful and from what I can understand these devs doesnt want credits but just make things work better...

and am I wrong if I say that if the cm settings can handle their kernel ppl dont need anymore their apps....? So they loose money too right?

Maybe Im just saying stupid things... I dont know Im not a dev
[Android General] blowtorch:
I'm not saying it right or wrong but, that if everyone follows the same "standard" the community as a whole benefits as these tweaks can end up on other devices and more users profit!
[Android General] StringBlade:
I think you are slightly misunderstanding. I'm not saying CM didn't make some accommodations for the independent devs by "stepping out of the way", but what they did do is force a choice on the independent devs (due to their choice to re-implement the tweak with a different interface) -

Roll your own GUI control for your kernel tweak (i.e. you, the original dev, cannot use CMs GUI controls because we changed the implementation of your tweak to use a different sysfs interface), or

Change your original kernel code to use our (CM's) sysfs interface standards so your tweak can be controlled by CM's GUI controls

This makes the assumption of course that CM's sysfs interface standards are open an accessible for all independent devs to access and follow. But more to the point perhaps is that CM's decision to re-implement the tweak using a different interface necessarily impacts the original dev because now he/she must change his/her original tweak to use CM's interface standards (see above assumption) or live with CM (and other CM-interface-standard-conforming ROM) users to complain about how their kernel is broken in CM.

It could be viewed as an honor that your tweak is deemed useful enough to be adopted by such a large and popular project as CM, but at the same time in the current approach it does a disservice to the original kernel dev and CM users who want to use the original dev's kernel but CM's controls.

All I'm suggesting is this: CM wants to have certain standards in their kernel code base. The original dev also has a standard that does not necessarily conform to CM's. It would be polite for CM to implement a small adapter when they re-implement the adopted tweak so that the original dev's kernel still works in CM with the CM controls.

CM knows what it's changing because they have to read the original code and so it's a small stretch to create some extra code that says "if X kernel, make GUI call to interface B go instead to interface A (the original interface before re-implementation)". And do that for all adopted tweaks.

What this wouldn't do is fix the "broken control" problem for derivative kernels. So let's say FooDev took Ezeekel's kernel (with the tweak) and added his own stuff. Then that kernel plopped into CM would still have broken controls because the kernel would not self-identify as the same as the one CM adopted the tweak from. I think it's unreasonable for CM to support all derivative works from the kernels they adopt tweaks of, but to support the one kernel they take the tweak from is only polite.
[Android General] cyanogen:
Our goal is simply to crack open these devices by making a unified ROM that anyone can compile and modify so that people can build awesome stuff on top. Nothing more, nothing less.
[Android General] franciscofranco:
You just agreed with me, unification, thats all there is. So if your goal is unification why fragmenting it?