Database Users

Why it is so difficult?

I do not want to upset anybody, just trying to get some understanding of the entire upgrade to a new OS version.
I'm a programmer myself, but on Windows platform and mostly do middle tier business server side apps. Do not know a thing about Linux and android. But had some java experience in the past.
I wonder why we cannot get Froyo so long? Ain't the sources open? Even if we do not have some drivers, these parts cannot change dramatically from version to version. Published API must be stable...
Is this about Dalvik JVM? But, I guess this must be in released ROMs for other phones in the line.
What's the deal? Will appreciate some explanation here.

Android is open source, but that is only the operating system and the kernel, but the drivers and RIL that make the device actually functional are the issue as far as I'm aware. From what I've read here and in IRC, Samsung gave us a hack-job RIL, which is causing many of the issues with getting an AOSP ROM fully compiled and working. I think there may be some driver issues as well to be worked out yet, but I feel those are less important than getting things like phone/data/messaging working. I'm guessing there are more technical reasons why they can't just get 2.1 or 2.2 built from source, but those are probably the big issues.

Honestly, it boils down to Samsung.
Put simply, they're crappy coders (as HTC once was many moons ago), or they're just hella lazy (I strongly believe its the former, given RFS and this RIL mess). Most companies are pretty crappy coders, but most of the time, it doesn't interfere with major things, like OS upgrades.
That, plus the lack of effort or support on Samsung's part, has me never wanting to buy another Samsung phone again, or ever recommending an Android phone from Samsung....
I'm gonna do my best to find in my next phone another quick processor with a nice super AMOLED screen and be done with Samsung, I've had enough, and I'm a very patient person....

What is RIL? Is this Radio Interface Library?
Is it linked into kernel or other module? Not extractable at all?
As I imagine it to myself, if it is some sort of dll or package, it shouldn't matter if we do not have source, because it's interface have to be already strictly defined. It doesn't matter if it is buggy. It should work with any android version.
Please correct me if I'm wrong.
P.S. I have Dell Axim v50x and people already created ROM from scratch! However it doesn't have RIL. ;-)

CNemo7539 said:
What is RIL? Is this Radio Interface Library?
Is it linked into kernel or other module? Not extractable at all?
As I imagine it to myself, if it is some sort of dll or package, it shouldn't matter if we do not have source, because it's interface have to be already strictly defined. It doesn't matter if it is buggy. It should work with any android version.
Please correct me if I'm wrong.
P.S. I have Dell Axim v50x and people already created ROM from scratch! However it doesn't have RIL. ;-)
Click to expand...
Click to collapse
if it could have been done, birdman would have done it already

Well I think it's a valid question. Some might think it tedious or obnoxious, but absolutely valid. This is a development forum after all. The reason we don't have 2.2 isn't a hardware limitation, so it must be a practical one -- or yes it would be here.
But I'll just speak from speculation in the hopes that someone will correct me. For god sakes this is a development forum! We've got releases, we have fixes, we have patches, we have complaints, we have gossip. I'd love to see all the _development_ discussion I can get.
From a wider puzzle-piece perspective, I would like to know what is missing. We have working drivers. We have working hardware. We have full source from Google for the operating system. There are several other android phones on Verizon, a few even have Froyo. Sprint currently offers a CDMA Galaxy S phone (Epic) with android 2.2, and that phone possibly shares some hardware (though the WIMAX radio is totally irrelevant to us).
I'm not up to speed on exactly what the RIL is, or how it gets plugged into the android kernel. The RIL (Radio Interface Layer) is a software layer between android itself and the drivers controlling the phone hardware. Google provides some samples for a carrier to create one to govern communication on their network. I'd expect one issue of randomly hacking something like this, is if you are taking over your radio hardware's communications, then you have the capability of putting unwanted data on the network, which might even be criminal. Am I being extreme? So, perhaps we can't touch the RIL and need to wait for it to be spoonfed to us by those that bought the radio band from the FCC. Perhaps this code is inexorably married to particular hardware, unavailable for reading, or even encrypted. Maybe the primary limitation is the royal pain in the apricots that it is to inspect, decompile, and reverse engineer binary code.
But what if we could do something?
My understanding is the RIL is only a carrier-specific interface to the underlying hardware. Shouldn't it be similar between phones, even with wildly different hardware? Shouldn't its interface also be similar between close versions of android? The Droid 2 is a verizon phone with a RIL that does indeed work with Froyo. What I'd like to know is A) can another phone's RIL be extracted within the same carrier, and B) Being the abstract entity that it is, what prevents it from being married to the Fascinate's hardware base?
To be honest, I ardently believe a frank discussion (sans opinions, complains, problems, just productive discussion w/ a smattering of facts) BELONGS in the Development forum.
I'll stop here, in case this thread dies, as so many of mine do.

Jt1134, adrynalyne, and fallingup(angel12) are all very capable as well. This is solely the fault of none other Samsung.
Edit: to answer your question, i think that.the answer about RIL is no, although i dont have a good qualified answer about why the RIL from D2 cant be ported im sure that if it could have, it would have. Sorry thats not a better answer.
Sent from my ADR6300 using XDA App

I don't know anything about how the RIL works, but I would assume that it could only be easily ported from one device to another if they were using the same chipset in the underlying hardware for the phone. I doubt you'd be able to take the Droid 2/X RIL, and take it to the Droid 2 Global or Droid Pro. Given that, I'm guessing that you can't really take a RIL from one phone and put it on another without extensive work, since most OEMs tend to use different hardware in their devices. From what I've heard, there is a semi-working AOSP build floating around, so the devs are trying, but Samsung's crappy source to work from is not making things easy for them.

There are actually some semi-working builds of aosp floating arpunfld but the last time I checked one out it was missing one thing that I consider to be kind of a biggie. It couldn't quite make calls. I'm sure they have it to make calls now but there is a reason its not out to the forums yet. I agree withstand nuts up there. Thanks you Samsung.
Sent from my ADR6300 using XDA App

ksizzle9 said:
There are actually some semi-working builds of aosp floating arpunfld but the last time I checked one out it was missing one thing that I consider to be kind of a biggie. It couldn't quite make calls. I'm sure they have it to make calls now but there is a reason its not out to the forums yet. I agree withstand nuts up there. Thanks you Samsung.
Sent from my ADR6300 using XDA App
Click to expand...
Click to collapse
i believe there was still no radio at all in aosp, and the hope is that 2.2 can fill in the gaps

Wow, wow, wow!
Why do we need another phone RIL? Current one from SF at hand should do perfectly. Did Google changed something in android API related to a RIL? I don't know for sure, but never heard or read anything making me think they did it. Android should call RIL and that is set in stone. ALL calls signatures must to be known. Something new may be added, but it is not show stopper.
So, I still do not understand - is it not extractable or what?
Even if not and it is somewhere in protected memory, encoded or whatever, Froyo slapped on top must work, IMHO. And sources available. So, why we stuck waiting for Samsung?
I know, one may say - do it yourself if you are so smart... Once again, I just want to understand root of the problem. I probably can do something, because I have degree and experience. But, it will take me forever. From what I've tried and seen learning curve is very steep.
On the other hand, skilled developer might simply need fresh look at the problem... May be guys just hitting wrong wall?

CNemo7539 said:
Wow, wow, wow!
Why do we need another phone RIL? Current one from SF at hand should do perfectly. Did Google changed something in android API related to a RIL? I don't know for sure, but never heard or read anything making me think they did it. Android should call RIL and that is set in stone. ALL calls signatures must to be known. Something new may be added, but it is not show stopper.
So, I still do not understand - is it not extractable or what?
Even if not and it is somewhere in protected memory, encoded or whatever, Froyo slapped on top must work, IMHO. And sources available. So, why we stuck waiting for Samsung?
I know, one may say - do it yourself if you are so smart... Once again, I just want to understand root of the problem. I probably can do something, because I have degree and experience. But, it will take me forever. From what I've tried and seen learning curve is very steep.
On the other hand, skilled developer might simply need fresh look at the problem... May be guys just hitting wrong wall?
Click to expand...
Click to collapse
is it possible? perhaps...but the 5 or so guys who really develop for this phone havent been able to get it to work....nor is aosp working 100% on any galaxy s phone

Response from developers?
Anyone?

Yes, you know so much, we are waiting for you to fix it.
Hurry the hell up.

adrynalyne said:
Yes, you know so much, we are waiting for you to fix it.
Hurry the hell up.
Click to expand...
Click to collapse
Agree get your ass moving so we can have teh honeycombzzzz. Quit being such a lazy stingy jerk and get us our AOSP!

ksizzle9 said:
Jt1134, adrynalyne, and fallingup(angel12) are all very capable as well. This is solely the fault of none other Samsung.
Edit: to answer your question, i think that.the answer about RIL is no, although i dont have a good qualified answer about why the RIL from D2 cant be ported im sure that if it could have, it would have. Sorry thats not a better answer.
Sent from my ADR6300 using XDA App
Click to expand...
Click to collapse
yes i was just pulling one dev name out for the heck of it
but i subscribe to the "if it could have been done, it would have been done"

adrynalyne said:
Yes, you know so much, we are waiting for you to fix it.
Hurry the hell up.
Click to expand...
Click to collapse
I don't care what you did for community! But you behave like f****g jerk.
No real explanation for the rest of us? Stay on irc, we will survive without your comments here.

CNemo7539 said:
I don't care what you did for community! But you behave like f****g jerk.
No real explanation for the rest of us? Stay on irc, we will survive without your comments here.
Click to expand...
Click to collapse
that may be a problem for those who just stay here as virtually everything is irc only these days...or the majority of it anyway

CNemo7539 said:
I don't care what you did for community! But you behave like f****g jerk.
No real explanation for the rest of us? Stay on irc, we will survive without your comments here.
Click to expand...
Click to collapse
How many different ways do people need to say that "it's being worked on"? The devs are doing a lot of work on our device, but also working with other stuff, all in their free time. Follow the stuff they do on Twitter and github, or join in on IRC.
Attitudes such as your's are precisely why the devs have stopped posting stuff here. You act as though it's a simple process to do things, when it isn't, especially when Samsung gives you a crappy base to start from. The devs have to first get Samsung's source fixed and cleaned up, then start on whatever it is they want to work on, all while finding more bugs and issues that need fixed, primarily all stemming from the crappy source. If you want to be angry at someone, make it Samsung, not the few devs that are working on our device.
Sent from my StupidFast Voodoo Fascinate

As I said - I will survive. I'm OK even with not rooted stock.
Was it so difficult to answer what the real problem is? I don't know what is the problem with this generation? Do I need to be on FB, irc or whatever to get the answer? Why do not answer in place? Ain't it this forum purpose?
No, seems like I need to kiss somebody ass to get meaningful response these days... That way he can maintain his "super god" status.
I do believe I've been pretty polite stating my question, even though English is not my native language. What generated so much sarcasm?

[Q] Why can't we compile our own 2.2 OS?

Let me start by saying I'm fairly new to Android, and that this probably should go in a general Android forum, but since I'm a Fascinate user, this seems appropriate to me. I've searched, but haven't found a real explanation, and I'm not one to take things as fact without a reasonable explanation.
So it seems like everyone is waiting for an official 2.2 release for the Fascinate, flashing 2.1 ROMs but not capable of upgrading to 2.2+; but I'm wondering why we can't just compile our own OS for our phones? Android is a Linux-like OS, and I know Linux users would never stay on an old version if a newer (better?) version was available. I'm talking down-and-dirty tweak-every-option-by-hand Slackware here. Is the source available for download? If so, why can't we do something with it? Is something in the phone completely locked and unhackable? Is it the fear of having a $500 paperweight? Is it difficult to regain Verizon network connectivity?
Again, forgive the noob question, and thanks in advance for any help you can give me!

http://forum.xda-developers.com/showthread.php?t=792986
http://forum.xda-developers.com/showthread.php?t=883004
http://forum.xda-developers.com/showthread.php?t=882946

There is currently work being done by jt, birdman, and the other skew of developers trying to develop a working AOSP version of 2.2/2.3. The biggest struggle that they have encountered was the RIL (Radio Interface Layer) binaries. Samsung produced some bogus complex proprietary binaries with no properly working source code. Because this phone is CDMA and not GSM, we can't simply use galaxy s files.
Anyways, the point is that there is work being done to bring it to our phone. They have a working AOSP 2.1 that is currently in alpha stage. Jt basically built his own RIL for this phone to get it working.
If this RIL works, we may end up with 2.3 sooner than later.

eulipion2 said:
Let me start by saying I'm fairly new to Android, and that this probably should go in a general Android forum, but since I'm a Fascinate user, this seems appropriate to me. I've searched, but haven't found a real explanation, and I'm not one to take things as fact without a reasonable explanation.
So it seems like everyone is waiting for an official 2.2 release for the Fascinate, flashing 2.1 ROMs but not capable of upgrading to 2.2+; but I'm wondering why we can't just compile our own OS for our phones? Android is a Linux-like OS, and I know Linux users would never stay on an old version if a newer (better?) version was available. I'm talking down-and-dirty tweak-every-option-by-hand Slackware here. Is the source available for download? If so, why can't we do something with it? Is something in the phone completely locked and unhackable? Is it the fear of having a $500 paperweight? Is it difficult to regain Verizon network connectivity?
Again, forgive the noob question, and thanks in advance for any help you can give me!
Click to expand...
Click to collapse
You obviously have not searched hard enough, as this has been discussed in many places. I would suggest you start by searching this forum (edit: or seeing the links and posts above).
I will say, however, that recent achievements by (edit: the developers mentioned above) have made your suggestion quite possible. If you want to get a taste of what is to come, see the aosp alpha sticky located in the development section. The rom still has bugs, but it is a giant step forward for the Fascinate.
Sent from my Galaxy-S Fascinate

Florynce said:
http://forum.xda-developers.com/showthread.php?t=792986
http://forum.xda-developers.com/showthread.php?t=883004
http://forum.xda-developers.com/showthread.php?t=882946
Click to expand...
Click to collapse
^^^^^
10char

I must add/point out that the work these guys are doing could easily pave the way for Cyanogenmod- and other well-featured roms to be compiled/ported and used on Fascinate as well.

I've read the above links, but they didn't really quite answer my question. I guess I'm wondering why a Linux-based OS isn't acting/being treated like a Linux-based OS.
Let's say I go out and buy a new computer today. I want to put Linux on it. I get the machine home, download my distro of choice and make an install cd. As I'm installing, I configure the installation either for my specific hardware or I can use a generic profile if my hardware isn't listed.
Now say a new version of the Linux kernel comes out. I can upgrade without having to wait for a version for my hardware. Or if I install MyDistro v1 when I get my machine, and MyDistro v2 comes out the next day, I don't have to wait for someone to develop a version to work with my hardware.
So my question is more of a why can't we upgrade our distro like other Linux variants? Is it because there's no generic replacement for the Samsung RIL? If I were to download the source and do a generic build, or even a specific one, I wouldn't be able to install it because...?
Sorry to be a pain, but I genuinely have no clue. Again, thank you for the insight!

2.2 will boot on the I500 just nothing works. If you would like to help http://opensource.samsung.com/
The source code can be found there. Please feel free to help the development along.
I suggest you read through the reply's to your question and pay special note to those bringing up the RIL as that seems to be the biggest hurdle right now.

I think maybe the answer you are looking for is that it is possible to do it, it's just extremely difficult because Samsung's open source is very shoddy and isn't based on AOS, which is what is used for most other phones.
Since the developers don't have a build that works, they have to work from the ground up with AOS and get every last feature on the fascinate working without using Samsung's code (TouchWiz, widgets, etc).
The links they gave you explain most of it but you have to sift through the posts. There is a dev named jt (amongst others) who is working on a ROM that is upgradable based on AOSP and it looks very promising.
edit: It's also worth noting that when I say "not based on AOS" I mean that it is proprietary software used by Samsung-only phones and is not coded by Google. It still, of course, is based on Android OS. It would be akin to a ROM coded by Samsung for their phones rather than generic ROMs that could be downloaded by other phones.

Perfect, thanks!

Try thinking of it as buying an Ubuntu laptop from dell. Sure its " Ubuntu" but not stock. It so full of bloat and badly written drivers that aren't supplied openly for the user that it would be hell trying get the latest version of ubuntu to run on it.
Sent from my SCH-I500 using XDA App

For clarification.... so I can wrap my brain around this. Is this situation kinda like having bought a new computer that's running an os, but has no installed device drivers and nowhere to download them from, so they have to be written by hand?
Edit: that last post came thru while I was writing this one, I think it basically answers my question...

So what the devs on here are trying to do is develop a "generic" profile that can work on our phone (as well as others?), creating a solid base to allow users to upgrade and change at-will without having to wait for official releases?
See, that's the part I'm having a hard time with. No generic profile built into the OS to use in the absence of a hardware specific one?
LoverBoyV said:
Try thinking of it as buying an Ubuntu laptop from dell. Sure its " Ubuntu" but not stock. It so full of bloat and badly written drivers that aren't supplied openly for the user that it would be hell trying get the latest version of ubuntu to run on it.
Click to expand...
Click to collapse
On a sidenote, I bought a Dell netbook witih Ubuntu. Didn't waste time with Ubuntu, but I chose it because I didn't want MS to get money from a license fee. Installed Mac OS X on it the day it arrived

Ya know, I tried to do the same thing with my inspiron 1525 notebook, with snow leopard 10.6.3 since I have a spare hard drive. Spent a whole day with numerous guides, trying this n that. Got it to actually boot to the desktop once, bit as I was putting the drivers in, it went into KP and from that point on, I could never even reinstall back to the desktop again.

Well, Samsung is giving us a simple/reliable update to Froyo with unique functionality, as soon as possible.
Source: (Twitter, About 12pm 1/2/2011 from Samsungtweets via Cotweet - http://twitter.com/Samsungtweets/samsung-usa )
Samsungtweets We are working to make the Android 2.2/Froyo upgrade available to all U.S Galaxy S owners as soon as possible.
Samsungtweets We want Galaxy S owners to have simple/reliable upgrade. We r running tests due to complexity/unique functionality
EDIT: gave more specific time and source of tweets. Post is meant to be objective, without definition of ASAP for this context.
Swyped w/ XDA App. When in doubt, mumble.

soba49 said:
Well, Samsung is giving us a simple/reliable update to Froyo with unique functionality, as soon as possible.
Source (Twitter, 6 hours ago):
Samsungtweets We are working to make the Android 2.2/Froyo upgrade available to all U.S Galaxy S owners as soon as possible.
Samsungtweets We want Galaxy S owners to have simple/reliable upgrade. We r running tests due to complexity/unique functionality
Swyped w/ XDA App. When in doubt, mumble.
Click to expand...
Click to collapse
I'm not sure if this is meant to be funny or not haha. Are those recent tweets?
Sent from my SCH-I500 using XDA App

They seem to post the same things over and over, of course this is also because people constantly ask when is froyo coming, and every time they say there is no definite date. It is coming soon that that is all they will say; yelling, moaning and crying isn't gonna make it come any sooner, just sit back and it will eventually come.

[CRAZYTHEORY] Joint HC Developement?

Hello there,
I have this theory... I want to hear your opinions to see if I'm just crazy or I'm correct in thinking this.
After seeing how the unmodified Acer Iconia Galaxy ROM + modified ASUS Transformer kernel (Clemsyn's) worked on a Transformer I started to think that this could be because of all the Honeycomb tablets are running a pretty similar OS configuration ("stock-like" Honeycomb).
Am I right in thinking this (I haven't actually used any other HC tablet except the Iconia)?
If this is right, it kind of explains why an unmodified ROM developed for the Iconia works with our device, as they are using pretty similar systems. The main difference, of course, is the hardware. This explains the wifi, battery and other issues in this example. This was partly corrected from the use of an ASUS TF kernel (Clemsyns) with the same ROM since the kernel provides the needed interfaces, modules, whatever for the respective hardware.
Of course, the kernels between the devices, I'm assuming as I haven't actually compared the source, are pretty similar aside from certain hardware modules that have been left out during compilation, as they are both just modified Linux kernel. This explains why the Iconia ROM worked (mostly) even when using an Iconia kernel.
So am I right with all the above, or am I missing something obvious, or am I just crazy (2am and my PC's made my room very hot afterall)?
Okay, so if the above is correct, couldn't/shouldn't we be doing some cooperative developement with other Honeycomb device developers? Or at least the Iconia developers, as I'm not sure about other devices. I mean, if the ROMs are pretty much compatible, all that would need to be done is have a respective kernel for the respective device flashed on-top of the ROM, right?
Anyway, laugh at me, flame me, tell me to go to bed, whatever, but I'd like to know what your thoughts are.
And on a related note:
Has anyone actually tried flashing any other "other-device ROMs" onto a TF with a TF kernel and got it working?
I'd love to try, but my internet is terrible... I swear someone else on the network constantly has their BT speeds uncapped 24/7 (share-house's are ****ty).

I think that's pretty much the goal of the CyanogenMod project. Only reason they haven't begun on a Honeycomb version is because Google never released the AOSP. Hopefully this will change with ICS.

Yes, the OEMs are working together with google behind the scenes.
More than likely Google has "forced" them to contribute code in order to participate and enjoy early code.
Unified code at the OS level would be a godsend and allow for Windows - style updates.

poltak11 said:
After seeing how the unmodified Acer Iconia Galaxy ROM + modified ASUS Transformer kernel (Clemsyn's) worked on a Transformer I started to think that this could be because of all the Honeycomb tablets are running a pretty similar OS configuration ("stock-like" Honeycomb).
Click to expand...
Click to collapse
As far as I'm aware, pretty much all the current crop of Honeycomb tablets are all based on the Nvidia Ventana reference platform, so it's not too surprising that they are all very, very, similar software-wise.
Regards,
Dave

JCopernicus said:
Yes, the OEMs are working together with google behind the scenes.
More than likely Google has "forced" them to contribute code in order to participate and enjoy early code.
Unified code at the OS level would be a godsend and allow for Windows - style updates.
Click to expand...
Click to collapse
But as the OEMs are working together, why aren't independant developers here on xda? I mean, I'm just thinking that a lot more nice work would get done if there was unified developement going on between the HC devices instead of seperate forums, and seperate ROMs that seem to be very similar.
And yes, I do agree about the closed source problem. But Google said this is just a temporary thing, right?

It's hard to write too much code when you don't have the original to start with.
No one really wants to write Honeycomb from scratch.
sassafras

sassafras_ said:
It's hard to write too much code when you don't have the original to start with.
No one really wants to write Honeycomb from scratch.
sassafras
Click to expand...
Click to collapse
I understand this, of course, but excuse my ignorance when it comes to Android Developement, but what are the developers of PRIME and Clemsyn's ROM and all the other HC ROMs working with at the moment, as there is no source other than the GPL'd kernel?

poltak11 said:
I understand this, of course, but excuse my ignorance when it comes to Android Developement, but what are the developers of PRIME and Clemsyn's ROM and all the other HC ROMs working with at the moment, as there is no source other than the GPL'd kernel?
Click to expand...
Click to collapse
They are working with the OTA. It is all compiled things. They can add things on top of it, but they can't do modifications to it because its already compiled (source code not provided).

zephiK said:
They are working with the OTA. It is all compiled things. They can add things on top of it, but they can't do modifications to it because its already compiled (source code not provided).
Click to expand...
Click to collapse
Ah, fair enough. Well assuming that Google actually does release the source-code sometime, will this sort of thing be happening? As in co-developement between devices?
It just seems like the sensible thing to be happening, as opposed to a greatly splintered "fork" style of developement.

poltak11 said:
Ah, fair enough. Well assuming that Google actually does release the source-code sometime, will this sort of thing be happening? As in co-developement between devices?
It just seems like the sensible thing to be happening, as opposed to a greatly splintered "fork" style of developement.
Click to expand...
Click to collapse
Chances are there will be a CyanogenMod type project once Android tablet sources are released.
However, there will always be developers who are primarily interested in doing their own thing, which is perfectly acceptable too.
Regards,
Dave

poltak11 said:
Ah, fair enough. Well assuming that Google actually does release the source-code sometime, will this sort of thing be happening? As in co-developement between devices?
It just seems like the sensible thing to be happening, as opposed to a greatly splintered "fork" style of developement.
Click to expand...
Click to collapse
There's a reason CM hasn't officially touched any Honeycomb tablet. There's no source. Once they open up the source with ICS then everyone will be working on it through github.

Looking For Tablet ROM With More Complete S-Pen Support

Hello. I have written an app that helps to improve the accuracy of the S-Pen. It works only on Note phones because Samsung has compiled some S-Pen device driver interfaces out of the tablet ROMs. It is not clear why they did this. I have asked Samsung but gotten no replies. I have confirmed that parts of the kernel code is commented out in the open source kernel code (and you can see that some of the interface files found on phones do not exist on the tablets). It seems that the tablets suffer from the same issues related to the S-Pen as do the phones and I have many people asking me to make my app work on their tablets. I cannot do so with the stock ROMs because of the missing interface files.
So I am wondering if there any non-stock ROMs in which the S-Pen is more fully supported. The missing files are located on my phone in /sys/class/sec/sec_epen/ and the two files I need are called epen_hand and epen_rotation. If anyone knows of any ROMs for the S-Pen equipped tablets that provide these interface files, I would appreciate knowing and may be able to direct some folks to using them.
Thanks

I can confirm that neither are present in Baked build 8, it might be worth checking a dump from the note 8.0
Regards
Jack

JSale said:
I can confirm that neither are present in Baked build 8, it might be worth checking a dump from the note 8.0
Regards
Jack
Click to expand...
Click to collapse
Jack, some replies to postings in the Note 8 section indicate that the two files are present on the stock ROM there. Interesting... I am downloading a dump of the 10.1 now to see if I can see anything. Thanks

Any progress on this? It looks quite promising in the note 8.0 forums.
Regards
Jack

whitedavidp said:
I have confirmed that parts of the kernel code is commented out in the open source kernel code (and you can see that some of the interface files found on phones do not exist on the tablets). ... The missing files are located on my phone in /sys/class/sec/sec_epen/ and the two files I need are called epen_hand and epen_rotation ...
Click to expand...
Click to collapse
Well, since this is presumably a kernel issue, I'll look into it (PM me with your E-mail address) and IF there's anything that can be done about it (i.e., if the corresponding actions are available in the pen driver; it's not enough to just be able to integrate the sysfs entries) I'll add it into the kernels I release for the Note 10.1

kcrudup said:
Well, since this is presumably a kernel issue, I'll look into it (PM me with your E-mail address) and IF there's anything that can be done about it (i.e., if the corresponding actions are available in the pen driver; it's not enough to just be able to integrate the sysfs entries) I'll add it into the kernels I release for the Note 10.1
Click to expand...
Click to collapse
Hello and thanks for responding/helping out. I am certainly no kernel programmer. But I have downloaded the kernel sources for a couple official Note devices/versions. I have been reading files located in kernel/drivers/input/touchscreen/wacom paying particular attention to the file wacom_i2c.c. I cannot help but note that some of the functions which appear to reference the driver i/o files that are missing are #def'ed out of certain devices - see line 837 #if defined(CONFIG_MACH_P4NOTE).
I have no idea if the Wacom devices used in the various Note models are the same (except for size) or are similar enough to be treated as the same by programs like mine. Heck, I am not even sure if Wacom devices are being used in all the Note models. So I am afraid I am not much in the way of technical help here.
What I do know is that some custom ROMs for Note I and II phones seem to have been created with drivers that DO support and create the needed driver i/o files but which lack the device settings and other mechanisms which actually take advantage of these i/o files. Basically, they do not offer a dominant hand setting nor do they seem to communicate to the Wacom device when an orientation change is detected. I have been able, through my app, to compensate for these lapses on those devices and thereby improve the SPen's accuracy.
I have had users wanting to get the same effect on Note tablets with my app. So I presume they are experiencing the same type of problem on their tablets that I experienced on my Note I phone that led me to get into all of this. But I know that my app cannot help them unless the i/o files are there.
I was surprised to hear, over in the Note 8 forum that the files do exist on those devices. I know from a tester that my app at least runs on the Note 8. But I don't know if it helps any since that tester was not seeing the problem my app is designed to fix. But I read here that the files are not on the larger Note tablets. I don't know why and have asked Samsung and get basically no answer. My underlying assumption is that the Wacom devices are basically the same but I cannot answer why Samsung treats them as different.
I am sure all of this doesn't help much. Sorry. All I would like to do is try to find a way to offer support to the tablet users who want it.
Cheers!

Try this kernel: http://goo.gl/OBJ4O (PM also sent).

kcrudup said:
Try this kernel: http://goo.gl/OBJ4O (PM also sent).
Click to expand...
Click to collapse
Im going to quickly revert from baked to android revolution to test this
I will let you know what I think.
Regards
Jack

JSale said:
I'm going to quickly revert from baked to android revolution to test this
Click to expand...
Click to collapse
No, this is just a kernel- you won't have to change distributions to try this.

kcrudup said:
No, this is just a kernel- you won't have to change distributions to try this.
Click to expand...
Click to collapse
But baked is based on CyanogenMod, unless this kernel is compatible?

kcrudup said:
Try this kernel: http://goo.gl/OBJ4O (PM also sent).
Click to expand...
Click to collapse
Sadly, I don't own one of these tablets (yet). But I have passed this on to a user who previously asked me (and got this thread rolling as a result). So perhaps he can check it out and try my app on it. If he does, I will certainly report back here. Thanks for your efforts.

JSale said:
But baked is based on CyanogenMod
Click to expand...
Click to collapse
Oh, then yeah- as I suspect CM won't have any of the SPen goodies. My bad.
In any case, let me know. It was a very trivial fix and didn't appear to break anything. I don't use the SPen much at all, but a quick test with SNote appears that everything still seems to work OK.
(But I did notice that the stock Samsung ROM (CMD2) does set these variables, which is unusual as these sysfs entries "shouldn't exist", but it seemed to (re)set them to default values. I wonder if this is used as part of a version check of some sort?)

Well, after a little bi of testing, I can conclude that this fix has indeed improved the accuracy of the s-pen. It is hard to tell by how much, as I never had very terrible offsets myself, but at the edge of the screen, this has reduced the offsets by an observable amount.
Would it be possible to get the kernel fix implemented into the app so that I can use it on Baked rom ?
Many regards for all the hard work
Jack

JSale said:
Well, after a little bi of testing, I can conclude that this fix has indeed improved the accuracy of the s-pen. It is hard to tell by how much, as I never had very terrible offsets myself, but at the edge of the screen, this has reduced the offsets by an observable amount.
Would it be possible to get the kernel fix implemented into the app so that I can use it on Baked rom ?
Many regards for all the hard work
Jack
Click to expand...
Click to collapse
Wow! Thanks for the testing and for the feedback on your results. This is quite interesting. I am not quite sure I can integrate this sort of thing into my app although it may be possible. The kernels for the Samsung devices I have looked at seem quite monolithic rather than modular. But I do know that one app, TouchScreenTune, does something that fiddles with the kernel in some way I do not fully understand. So perhaps. I would sure need help and direction. But it would be very cool indeed.

JSale said:
Would it be possible to get the kernel fix implemented into the app so that I can use it on Baked ROM?
Click to expand...
Click to collapse
Well, the "kernel", the "ROM" and whichever app it uses are quite different things, but at least I can offer up the "commit" that makes it possible in the kernel (which has to then be pasted into a ROM). Have a/the Dev PM me.
whitedavidp said:
But I do know that one app, TouchScreenTune, does something that fiddles with the kernel in some way I do not fully understand.
Click to expand...
Click to collapse
Most likely via a "sysfs" file, which seems to be the preferred method for this driver.

kcrudup said:
Well, the "kernel", the "ROM" and whichever app it uses are quite different things, but at least I can offer up the "commit" that makes it possible in the kernel (which has to then be pasted into a ROM). Have a/the Dev PM me.
Most likely via a "sysfs" file, which seems to be the preferred method for this driver.
Click to expand...
Click to collapse
If I want to point users of my app to your kernel as a means of gaining more SPen support, where should I send them? Does the Kernel have a main web page? And if so, what version should I point them towards? Thanks

whitedavidp said:
If I want to point users of my app to your kernel as a means of gaining more SPen support, where should I send them?
Click to expand...
Click to collapse
Well, right now the only kernel that's got this particular support is the one I've posted here- but every now and then I post up a kernel boot.img file for the latest Android Revolution ROM and for Darkman's latest Stock ROM and this patch will be included in those going forward. Most boot.img files among the various Note 10.1 devices are close enough that they'll almost always work for any ROM, Stock or Custom.
I don't keep any seperate thread or site for my kernel, as I'm really just sharing my own personal (yet improved and faster) kernel for Note 10.1 devices (and frankly don't feel like dealing with the inevitable newbie questions that a standalone offering would generate).
But I have a number of commits I'm about to push to my GitHub page; once I do that (give me a day or two, I've made some major changes to the kernel source and I'll need to verify all's well before I make them Public) I'll come back here with the GitHub commit web-page URL, then you can pass that to any ROM/Kernel dev and they can easily incorporate it in their particular builds (it's a really trvial patch, too- I just removed the 3 "#else" directives embedded in the "#ifdef CONFIG_MACH_P4NOTE" conditionals).

kcrudup said:
Well, right now the only kernel that's got this particular support is the one I've posted here- but every now and then I post up a kernel boot.img file for the latest Android Revolution ROM and for Darkman's latest Stock ROM and this patch will be included in those going forward. Most boot.img files among the various Note 10.1 devices are close enough that they'll almost always work for any ROM, Stock or Custom.
I don't keep any seperate thread or site for my kernel, as I'm really just sharing my own personal (yet improved and faster) kernel for Note 10.1 devices (and frankly don't feel like dealing with the inevitable newbie questions that a standalone offering would generate).
But I have a number of commits I'm about to push to my GitHub page; once I do that (give me a day or two, I've made some major changes to the kernel source and I'll need to verify all's well before I make them Public) I'll come back here with the GitHub commit web-page URL, then you can pass that to any ROM/Kernel dev and they can easily incorporate it in their particular builds (it's a really trvial patch, too- I just removed the 3 "#else" directives embedded in the "#ifdef CONFIG_MACH_P4NOTE" conditionals).
Click to expand...
Click to collapse
Thanks very much once again!

whitedavidp said:
Thanks very much once again!
Click to expand...
Click to collapse
The app seems to work with this kernel :good:
kcrudup said:
Well, right now the only kernel that's got this particular support is the one I've posted here- but every now and then I post up a kernel boot.img file for the latest Android Revolution ROM and for Darkman's latest Stock ROM and this patch will be included in those going forward. Most boot.img files among the various Note 10.1 devices are close enough that they'll almost always work for any ROM, Stock or Custom.
I don't keep any seperate thread or site for my kernel, as I'm really just sharing my own personal (yet improved and faster) kernel for Note 10.1 devices (and frankly don't feel like dealing with the inevitable newbie questions that a standalone offering would generate).
But I have a number of commits I'm about to push to my GitHub page; once I do that (give me a day or two, I've made some major changes to the kernel source and I'll need to verify all's well before I make them Public) I'll come back here with the GitHub commit web-page URL, then you can pass that to any ROM/Kernel dev and they can easily incorporate it in their particular builds (it's a really trvial patch, too- I just removed the 3 "#else" directives embedded in the "#ifdef CONFIG_MACH_P4NOTE" conditionals).
Click to expand...
Click to collapse
I really want to know what are the features of this kernel ... would i keep it or there are other ones that have this functionality right now?? OR could just this changes be added to the Stock kernel to only have Spen support .. as i dont want any OC or custom governers :good: :good:

whitedavidp said:
If I want to point users of my app to your kernel as a means of gaining more SPen support, where should I send them? Does the Kernel have a main web page? And if so, what version should I point them towards? Thanks
Click to expand...
Click to collapse
May I ask you what application you are talking about?
@kcrudup Have you already decided to release your kernel in a separate thread or not?

[Q] Is it as simple as compiling cyanogenmod?

Would it be as simple as compiling cyanogenmod for a new phone? We have official builds for my phone (lg Optimus g), and various other AOSP based projects. The main reason I am asking is I have compiled cyanogenmod night lies before, and this looks very interesting so I want to try to get it working on my phone.

evodev said:
Would it be as simple as compiling cyanogenmod for a new phone? We have official builds for my phone (lg Optimus g), and various other AOSP based projects. The main reason I am asking is I have compiled cyanogenmod night lies before, and this looks very interesting so I want to try to get it working on my phone.
Click to expand...
Click to collapse
It is

XpLoDWilD said:
It is
Click to expand...
Click to collapse
Just a quick question,will it support mediatek devices?

s.sawrav said:
Just a quick question,will it support mediatek devices?
Click to expand...
Click to collapse
Yes.
We have early support for the r819.

I hope OmniROM is also meant for devices with low specs like for my Xperia U. I am interested to try it as a user.

Mayank7795 said:
I hope OmniROM is also meant for devices with low specs like for my Xperia U. I am interested to try it as a user.
Click to expand...
Click to collapse
If you have a working AOSP, it should be available without problems.

@XpLoDWilD
Would it be worth me attempting to build this for the tf700, or do you guys have plans for it?
Cheers

What about devices that have CM10 only?

lozohcum said:
What about devices that have CM10 only?
Click to expand...
Click to collapse
You need at least an unofficial CM 10.2 / AOSP 4.3.

JoinTheRealms said:
@XpLoDWilD
Would it be worth me attempting to build this for the tf700, or do you guys have plans for it?
Cheers
Click to expand...
Click to collapse
Building is always worth an attempt...
I used to build my own CM, i'm gonna try to build my own omni too but i'm struggling. I must be doing something wrong with the repo init but I can't seem to find what... I'm gonna update my buildbot first because it's been awhile, and maybe try again tomorrow.

As always everyone forget about non-highended devices and lower android versions. Everytime new android version appers, all devs greedily jump on in and start making roms only for it. Nexus 7, Xperia Z/Z1... I vomit. And of course experienced devs are not willing to share their's knowledge about device maintenance

lozohcum said:
As always everyone forget about non-highended devices and lower android versions. Everytime new android version appers, all devs greedily jump on in and start making roms only for it. Nexus 7, Xperia Z/Z1... I vomit. And of course experienced devs are not willing to share their's knowledge about device maintenance
Click to expand...
Click to collapse
That's why its worth scrawling through XDA, going through guides and learning to dev. Nothing wrong with a dev who decides to leave an older version for a newer version. They're doing it for fun and free.

lozohcum said:
As always everyone forget about non-highended devices and lower android versions. Everytime new android version appers, all devs greedily jump on in and start making roms only for it. Nexus 7, Xperia Z/Z1... I vomit. And of course experienced devs are not willing to share their's knowledge about device maintenance
Click to expand...
Click to collapse
I actually have a plan about getting legacy devices involved in the form of a "legacy branch" complete with legacy maintainers. It's tricky to get started off, but might prove useful for anyone wanting to get longer community support for their devices.

pulser_g2 said:
I actually have a plan about getting legacy devices involved in the form of a "legacy branch" complete with legacy maintainers. It's tricky to get started off, but might prove useful for anyone wanting to get longer community support for their devices.
Click to expand...
Click to collapse
As long as there is no hard reason to stop supporting a device and we have someone who is taking care of that device we will try
On the other side - there is constant evolution which sometimes will make it necessary to leave a device "behind" if the effort will become too large
Sent from my Find 5 using xda app-developers app

XpLoDWilD said:
It is
Click to expand...
Click to collapse
Not quite yet... Not until we have roomservice up and running.
(For those that didn't understand what I said - roomservice is the part of CM's repo management system that will automatically sync a device tree and all dependencies. roomservice is HEAVILY dependent on github's APIs, so we couldn't even start work on that particular piece of infrastructure until the project went public.)

lozohcum said:
As always everyone forget about non-highended devices and lower android versions. Everytime new android version appers, all devs greedily jump on in and start making roms only for it. Nexus 7, Xperia Z/Z1... I vomit. And of course experienced devs are not willing to share their's knowledge about device maintenance
Click to expand...
Click to collapse
The reason for the Nexus/Xperia Z support is because the vendors have AOSP source for pretty much the entire device readily available. The Xperia Z series (Z, Z Tab, Z1) have source widely available for (IIRC) pretty much everything bar the radio. Heck - sony had uploaded AOSP 4.3 sources before CM had 10.2 nightlies running, from memory.
Anything beyond that boils down to porting existing patches, or people bringing up other devices. This will generally happen for more widely used devices first simply because there's more likely to be someone available with the skills to do it. By the sounds of Omni is working, you could have pretty much any obscure old phone but if you're happy to do the bringup then it'll get added
M.

mattman83 said:
The reason for the Nexus/Xperia Z support is because the vendors have AOSP source for pretty much the entire device readily available. The Xperia Z series (Z, Z Tab, Z1) have source widely available for (IIRC) pretty much everything bar the radio. Heck - sony had uploaded AOSP 4.3 sources before CM had 10.2 nightlies running, from memory.
Anything beyond that boils down to porting existing patches, or people bringing up other devices. This will generally happen for more widely used devices first simply because there's more likely to be someone available with the skills to do it. By the sounds of Omni is working, you could have pretty much any obscure old phone but if you're happy to do the bringup then it'll get added
M.
Click to expand...
Click to collapse
Someone should write a definitive guide about converting CM10 device tree to AOSP JB device tree, so more people can work on devices maintenance

pulser_g2 said:
I actually have a plan about getting legacy devices involved in the form of a "legacy branch" complete with legacy maintainers. It's tricky to get started off, but might prove useful for anyone wanting to get longer community support for their devices.
Click to expand...
Click to collapse
I hope the Acer IconiaTAB A5000 will get supported.

Please, support for RAZR i (x86)

lozohcum said:
Someone should write a definitive guide about converting CM10 device tree to AOSP JB device tree, so more people can work on devices maintenance
Click to expand...
Click to collapse
Problem is, every device has its own pitfalls. Some are harder to overcome than others.
For example, the lack of NEON in tegra2 combined with the dependency of newer gapps on NEON really screws tegra2 devices, and there isn't much that can be done about it.
Also, in some cases, the things needed to get a device working aren't in the tree, but are in the frameworks to handle OEM-specific oddities (RIL hacking in opt/telephony, which I admit I'm not too familiar with...) or platform support. Sometimes, old devices get left behind simply because their platform overall is a ***** to support beyond a certain point. (See how MSM8660 devices have been lagging lately, due to Qualcomm pretty much sunsetting that chipset.)