Database Users

[Q] Adding Eris to CyanogenMod Supported Devices?

Here's what Cyanogen said on the Official CyanogenMod Forums.
http://www.cyanogenmod.com/home/a-note-on-unofficial-ports-and-how-to-get-it-right
With this said, why don't we jump on the bandwagon and just join the CM team? Why don't we make this thing official (if we haven't tried already)? Just a thought, so don't kill me with your opinions. The Devs here are freakin' legit here and I'd like to see 'em do some of the work on the CM Team.

I trust the devs I download from because I follow their work. I don't need it to be "official". Besides, I like the personal touch and one-on-one support I get right here on the xda eris forum. And there's variety.
We could debate the politics of branding and what is CM and what is not CM. But the devs here disclose their sources, changes, known issues and brand their roms as uniquely their own while providing the support and updates. I don't think there's any confusion as to what is 'official' and what is not as the Android Police article referenced in CM's statement implies.

+1. The devs here are excellent, and the devs that base there ROMs on CM list them as "based" on CM not the official CM ROM. I'm not aware of any confusion that this has caused. I'm also not sure what creative constraints would be put on our devs if they went CM. I like the way they individualize the roms for thier personalities and their audiences. I also am not sure what benefit would come with being an "official" CM rom. Just my 2 cents.

Don't get me wrong, I'm not discrediting the Developers that cook these ROM by ANY MEANS whatsoever. They do incredible work with what they push, but here's what I'm saying. The CM ROMS are based off of Official CM Source Code, yes, but I think we'd be making it way easier on ourselves and the developers if we were an actual part of CyanogenMod. If we were a part of CM, then we'd get the CM ROMS as perfect as they can get and THEN the developers can add their own customization to a ROM based off of the Eris Release of CyanogenMod. They all are already doing the work that it would take to actually /BE/ a part of the CyanogenMod team, so why not get on with CyanogenMod so we can be official, and THEN the devs can customize and tweak ROMS they way they see fit?
Once again, absolutely NO discredit to the developers here, and I understand what it takes to keep these ROMS current and I am very appreciative of their work.

The CM ROMs that we have are either built from CM source or ported from the Hero builds already. I'm not really sure what this would give us other than maybe a "go team go" feeling and maybe a little more help than we already get. But the Eris and CDMA Hero are so similar, that doesn't matter much in my opinion as long as any Hero issues get worked out.
The CM buildbots are just building from source and posting the results, much like you would get if you ran EasyDev or did it manually. Now, there's a lot of work going on before that with the code, of course. But... That's what we use too.
I'm not against this at all. It just means that someone will have to 1) want to do it 2) have the time 3) convince Team Douche to let them in. I seem to remember that someone asked early on and the response was that we had to send them an Eris. This might have changed.
This comes up every so often. I guess one of us can find out what we would need to do at least...

Nothing would really change for the end user if we became official cm at this point. Basically one of the devs here that builds from source would submit their vendor tree to the cm source and they would be responsible for maintaining it just like we do now. The only real difference would be that it would get built by the cm build bot and nightly's would be released. I tweeted to cyanogen about getting my 2.2 tree in there along time ago when 2.2 was new but either I did it wrong(not a twitter person lol) or it just got lost in the many many tweets that go through cyanogens account. I never really pushed the issue more because of the extra time it would take me personally and it was just easier to work on my own schedule.
The only added benefit would be that maybe if there was an issue we could not fix then the cm team would take an extra look at our specific phone to help out but really since our phone is so close to the hero and it has official support they sort of fix most of our bugs anyway. I've personally always tried to give the cm team all the credit they deserve(which is alot) and I think the other dev's do the same.

Here's what Cyanogen posted up to www.cyanogenmod.com a week or so again. It looks like we'd need an interested dev here to stop by #cyanogenmod-dev on Freenode to start the process.
I think (and I use xtrSENSE, so I could be wrong) that a lot of people would like and "official" CM port for the Eris, just so they'd have "peace of mind" knowing they've got something "official."
And again, as we've seen mentioned in this post, it couldn't hurt to ask. Provided Team Douche doesn't actually want an Eris, we only stand to gain extra help on our ports.
Cyanogen said:
There’s been some recent talk about unofficial versions of CyanogenMod being created and released on sites like XDA, with large amounts of missing features and broken functionality, and I just wanted to talk about our position on this.
An “official” CyanogenMod version is one that uses our code review system, our source repository, and our mirror network. It should look, act, and feel like CM on any other device, and more importantly, it should follow our release schedules (which is a “when it’s ready” kind of thing, but we do plan our final/RC releases when we feel it’s ready). Most importantly, no major hardware functionality should be broken.
We want to see CM available for every device out there, and our infrastructure (and our developer community) is there for anyone to use. We spend a lot of time making new releases of Android backward-compatible with devices that are not ready for them, and we also spend much time making all of these (sometimes not so pretty) changes co-exist together without breaking other devices. The more eyes on your code, the better it will be.
That said, as much as we’d like it to be, the CMSGS project is not yet an official part of CyanogenMod. There are also a number of other unofficial ports out there which haven’t been submitted to us that we’d love to include. If you’re interested, stop by #cyanogenmod-dev on Freenode. If you didn’t get it from our mirror network or the CM forums, don’t expect it to be up to our standards.
The biggest thing to keep in mind when porting to a new device is to think about how your change is going to affect other devices. This is the biggest reason why we aren’t supporting Samsung devices other than the Nexus S yet. Don’t change hardcoded default values just to suit your device. Use the configuration options available, or add new ones with the original values as defaults. Do a build for another unrelated device after you make your changes (it helps to have another device to test with, of course) and verify it as well. Android was made for this, so do it right.
Like I’ve said so many times before, CyanogenMod is all about the community. And our community can help you too. I’d love to see more of these ports contributed to the project- it’s only going to make things better. We’ve grown from just a mod to what I’d call an “Android distribution” and we need to keep our standards high.
Click to expand...
Click to collapse

Oh no, does this mean we're all running unofficial CM ROMs ?
Wait, everything is working fine though... Official, unofficial, pffft

hallstevenson said:
Oh no, does this mean we're all running unofficial CM ROMs ?
Wait, everything is working fine though... Official, unofficial, pffft
Click to expand...
Click to collapse
+1 10 char......

A dev would have to maintain the device and be committed to building it up, like Darchstar was (is?) for the Hero CDMA. It really all depends on the Dev/Devs for the device, for example I've seen Cyanogen say in his twitter that he would also like to see the Dream/Saphhire continue to be developed for but no one has stepped up to maintain it. I can also only imagine that there are some qualifications for someone to maintain a device. Here is a list of the current maintainers for the devices
https://github.com/cvpcs/android_vendor_cyanogen/blob/gingerbread/CHANGELOG.mkdn

Yeah, I can understand that. That's all I was saying, though. If they were doing all of the same work anyway I just thought it would be nice to have. I also didn't know if anyone had pursued this in the past, but seeing as how Conap had already tried I think I'm good with that. I also have no problems running the unofficial ROMs, just so you know. Thanks, guys!

It's not like we just want it to be official... but porting a ROM has its downsides. There's nothing to say devs couldn't take a ROM that is NATIVELY supported for the eris (and not for the hero) and do exactly what they already do... we would just be cutting out work for them and it would definitely effect the end user.

Hungry Man said:
It's not like we just want it to be official... but porting a ROM has its downsides. There's nothing to say devs couldn't take a ROM that is NATIVELY supported for the eris (and not for the hero) and do exactly what they already do... we would just be cutting out work for them and it would definitely effect the end user.
Click to expand...
Click to collapse
the way i do it is best for me,,and seems to be going fine,,, the cm7 ports have been alot better then the froyo ,, and alot faster ,, look how long it took the froyo camera to work,, gb the camera works outta the box,,

Hungry Man said:
It's not like we just want it to be official... but porting a ROM has its downsides. There's nothing to say devs couldn't take a ROM that is NATIVELY supported for the eris (and not for the hero) and do exactly what they already do... we would just be cutting out work for them and it would definitely effect the end user.
Click to expand...
Click to collapse
There is more than one definition of porting that people are using around here.
1) Porting to an unsupported device = compiling source, building a vendor tree, and getting it to work on said device (This is basically what the CyanogenMod team would do to make it an official build, although they would integrate the changes into the main source. The changes would mostly still be in a separate vendor tree in the repo. And it would be 'official'. From a practical/technical view, what workshed is doing is the same thing that the CM team would do.)
2) Porting an existing build to an unsupported device = taking an existing, already compiled ROM and making it work on said device (This is what tazz is doing with the Heroc build. This works out well when going from the Heroc.)
Anyone, feel free to correct me if I'm wrong, but I'm pretty sure that I have that right.
The only downside that I see from either of these is MAYBE not getting quite the support that we would get if the Eris had an 'official' build. I really don't think it's affecting much of anything, IMHO. It might in the future as the Heroc and Eris become more and more dated devices. But then, many of you won't really care because you're kids will be using them as mp3 players anyway while you use your fancy, new quad core HTC Destroyer 6G. (What's a Beiber?)

gnarlyc said:
There is more than one definition of porting that people are using around here.
1) Porting to an unsupported device = compiling source, building a vendor tree, and getting it to work on said device (This is basically what the CyanogenMod team would do to make it an official build, although they would integrate the changes into the main source. The changes would mostly still be in a separate vendor tree in the repo. And it would be 'official'. From a practical/technical view, what workshed is doing is the same thing that the CM team would do.)
2) Porting an existing build to an unsupported device = taking an existing, already compiled ROM and making it work on said device (This is what tazz is doing with the Heroc build. This works out well when going from the Heroc.)
Anyone, feel free to correct me if I'm wrong, but I'm pretty sure that I have that right.
The only downside that I see from either of these is MAYBE not getting quite the support that we would get if the Eris had an 'official' build. I really don't think it's affecting much of anything, IMHO. It might in the future as the Heroc and Eris become more and more dated devices. But then, many of you won't really care because you're kids will be using them as mp3 players anyway while you use your fancy, new quad core HTC Destroyer 6G. (What's a Beiber?)
Click to expand...
Click to collapse
I thought it was a girl

tazzpatriot said:
I thought it was a girl
Click to expand...
Click to collapse
Its a dude.
http://www.youtube.com/watch?v=3zb64y6Nvs0

refthemc said:
Its a dude.
http://www.youtube.com/watch?v=3zb64y6Nvs0
Click to expand...
Click to collapse
nope still a girl
http://www.youtube.com/watch?v=vwIa2S0YQs4

FYI: http://twitter.com/cyanogen/status/45246447385452544
@cyanogen said:
@Algamer we don't officially support the eris, it would be nice if someone doing the porting joined up with us though
about 8 hours ago via web in reply to Algamerhttp://twitter.com/Algamer/status/45235578886815744http://twitter.com/Algamer/status/45235578886815744
Click to expand...
Click to collapse

I think OUR devs are doing just fine. Why change now?
wildstang83

wildstang83 said:
I think OUR devs are doing just fine. Why change now?
wildstang83
Click to expand...
Click to collapse
Our devs are doing more than just fine, especially considering the amount of development we STILL have going on even though the Eris was a short-lived device that was EOL'd after like 8 months, was mid-range compared to the original Droid, and is a pretty niche device being MDPI on Verizon...
Why change now? That's a good question and I don't have a great answer. Like some have said on this post, maybe we'll get more support with bugs, etc. Additionally, a lot of the users here on XDA are looking for consistency. Since many who read and post here lack the skill set to do any meaningful ROM development themselves, they rely on the kindness of willing devs. However, devs will often add their own "personal touches" to their ROMs, which is great and well within their right to do. Having said that, many users are just looking to for something where they know, "Oh OK, so this is the base CM ROM that's officially distributed."
Personally, I don't care whether we have an "official" CM build or not for the Eris. I'm pretty reserved when it comes to ROMs for everyday use and am still using xtrSENSE as my default. The only reason I posted up cyanogen's recent tweet was to show that cyanogen himself is well-aware of the Eris development, is personally following the Eris ports, and is open to a partnership. My hope is that, by bridging communication, I am doing my part in helping to expose any possible mutual benefit (Eris XDA devs, ROM end-users, and Team Douche at CM) that could be gained by considering an "official" build. Ultimately, I understand that this is a decision that can only be made by the devs and also, not fulling understanding ROM development or having the skill set myself, I believe they are in the best position to make that decision. Like I said, I'm merely acting as a messenger, bringing this communication to light on our forum.

[Q] Honeycomb on KF? Vs ICS

Ahoy mateys. I've been a longtime Android user (October 2009) and have never been much for running the stock OS on my devices.
Currently I've been running CM7 and loving it on the KF. Been keeping tabs on the ICS port over, just waiting for the sound issues to be hammered out as I use the device mostly for watching videos via RockPlayer.
Lately I've been thinking about trying to port over Honeycomb to the KF, as it might be simpler given that it's been around longer. I know that it's somewhat futile given the state of the 3.0 kernel being needed for HW acceleration. But it seems like it could be worthwhile just to test it and see what might happen. Give it more tablety goodness if anything!
I'm a programmer by trade and am majoring in CS. Not much dev experience on Android aside from writing games. But I've built Gentoo for my machines, so I've got some kernel knowledge. What do you guys think?
Regards,
-Free
P.S. I don't have 10 posts so this is in General.

freeqaz said:
Ahoy mateys. I've been a longtime Android user (October 2009) and have never been much for running the stock OS on my devices.
Currently I've been running CM7 and loving it on the KF. Been keeping tabs on the ICS port over, just waiting for the sound issues to be hammered out as I use the device mostly for watching videos via RockPlayer.
Lately I've been thinking about trying to port over Honeycomb to the KF, as it might be simpler given that it's been around longer. I know that it's somewhat futile given the state of the 3.0 kernel being needed for HW acceleration. But it seems like it could be worthwhile just to test it and see what might happen. Give it more tablety goodness if anything!
I'm a programmer by trade and am majoring in CS. Not much dev experience on Android aside from writing games. But I've built Gentoo for my machines, so I've got some kernel knowledge. What do you guys think?
Regards,
-Free
P.S. I don't have 10 posts so this is in General.
Click to expand...
Click to collapse
Personally, I think it's a good idea, and that you should do it. You'll probably get a lot of people saying there's no point cause ICS is what honeycomb should've been. I've never used honeycomb before, so I don't know how different it is from ICS but I'm sure there are some.
I think you should do it to give this device and its users another ROM choice, with a different android version. Or even just for the fact that you might want to use it, do it for yourself and post it here just to see if people want it. I'd try it out, even if ICS is out and stable haha
Sent from my HTC Glacier using Tapatalk

Personally, I think it's a good idea, .... I've never used honeycomb before...
Click to expand...
Click to collapse
Huh?
Why would you encourage someone to work on something when you yourself don't know what the differences are between them??
ICS is Honeycomb just taking to what was its planned completion. With many Honeycomb devices moving to ICS I don't see the point.
That would be doing a lot of work, just to end up with an in between OS with all the new support going to ICS which is what everyone that can get it wants.
Also, for someone with no Android programming experience, you most likely would be a lot better of working with apps before tackling a whole OS.

krelvinaz said:
Huh?
Why would you encourage someone to work on something when you yourself don't know what the differences are between them??
ICS is Honeycomb just taking to what was its planned completion. With many Honeycomb devices moving to ICS I don't see the point.
That would be doing a lot of work, just to end up with an in between OS with all the new support going to ICS which is what everyone that can get it wants.
Also, for someone with no Android programming experience, you most likely would be a lot better of working with apps before tackling a whole OS.
Click to expand...
Click to collapse
I'd like to check it out. It's not like I'm telling him that he needs to do this, he asked what people thought of the idea because he was interested in doing it, and I voiced my opinion.
Though I do agree that it might be easier to work with apps and then maybe work on a ROM, but hey, if he's willing to attempt it and learn how everything works, why stop him? The more devs, the merrier lol

Isn't the problem with porting honeycomb is that it was never truly open source?

My understanding is there was never a source release for honeycomb
Sent from my SPH-D700 using xda premium

[email protected] said:
Isn't the problem with porting honeycomb is that it was never truly open source?
Click to expand...
Click to collapse
Yea, that is, AFAIK, why there was never a CM8. I don't think it would be worth OP's time to try to reverse-engineer a Honeycomb tablet and shoehorning it into the KF.
However, the OP might want to donate some of their time to the ICS port
It is open source after all...

[email protected] said:
Isn't the problem with porting honeycomb is that it was never truly open source?
Click to expand...
Click to collapse
I believe Google released the source for Honeycomb when they released the source for ICS
Sent from my Kindle Fire using Tapatalk

Hit up this Google announcement, they did indeed release the source.
This release includes the full history of the Android source code
tree, which naturally includes all the source code for the Honeycomb
releases. However, since Honeycomb was a little incomplete, we want
everyone to focus on Ice Cream Sandwich. So, we haven't created any
tags that correspond to the Honeycomb releases (even though the
changes are present in the history.)
Click to expand...
Click to collapse
groups.google dot com/forum/#!topic/android-building/T4XZJCZnqF8
The only thing that I really want to know is if there is a significant driver difference between ICS and Honeycomb. If there is, then there is a reason to try to port 3.0 over because it would have more driver support. There are 3.0 devices out in the wild. If there isn't a driver difference between 3.0 and 4.0, then it's futile and all efforts should be spent on 4.0.

theholyfork said:
I believe Google released the source for Honeycomb when they released the source for ICS
Sent from my Kindle Fire using Tapatalk
Click to expand...
Click to collapse
Indeed.
And when they released the source for ICS, they elaborated on why they included Honeycomb in the Source tree: To essentially display the hacks they were forced to use to push Honeycomb to market. Honeycomb was never AOSP'd because it wasn't reliable for wider use.
Based upon the fact that Google was basically too ashamed to release Honeycomb to AOSP, I don't think it would make much sense to target a broken platform (Honeycomb).
IMO, if you're going to spend time trying to work on getting a more tablet-oriented version of Android running, it's probably going to be *easier* to work with ICS than Honeycomb. Moreover your contributions could assist the greater KF community in getting a stable base of ICS for all.

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.)

Fx0/Madai Kernel: Version WTF?

The kernel source that LG posted on their opensource distribution site is not the code for the latest shipping version. Is that cool? Do they have any responsibility to provide the source for the newest version the shipped?
I wonder if the code they released matches earlier versions even. If only I could track down a rip of the system & boot images from the original version that shipped in Dec. 2014. Or even for the version after that. If anyone has one of those laying about, thanks, yo.

I have no idea, but that doesn't sound right.
Are you looking to unlock the bootloader so people can flash updated FFXOS ROMs to the device?

Saijin_Naib said:
I have no idea, but that doesn't sound right.
Are you looking to unlock the bootloader so people can flash updated FFXOS ROMs to the device?
Click to expand...
Click to collapse
Actually, I think I was wrong. Gah! I didn't realize that the prima_wlan stuff could be included included from outside the kernel tree. A qcom opensource repo is maybe where they built it from maybe?
> unlock the bootloader
No problems there, the Fx0 is wide-open. Like other LG devices, once you clear the CAF you gain Fastboot, and from there this device is splayed all day. You lose Download Mode, but since neither Mozilla or LG have seen fit to provide any of the usual KDZ images for that, I can't see any downsides. Maybe if they decide to update the Fx0 it would get used? I think it'd update in recovery instead though, yes?
Still want rips of Japanese system partition though. I wonder if the hiddenmenu is also stripped from those versions with v2.1 also? I want that hiddenmenu.

I have no idea. I'm not familiar at all with setting up a repo or anything. I've only ever build the ZTE Open repos provided by Mozilla, haha.
Oh, that is promising. What is the CAF?
Are you looking to get your Fx0 up and running with nightlies? If things actually work, I might grab one from eBay as a development/testing device as well.

Saijin_Naib said:
I have no idea. I'm not familiar at all with setting up a repo or anything. I've only ever build the ZTE Open repos provided by Mozilla, haha.
Oh, that is promising. What is the CAF?
Are you looking to get your Fx0 up and running with nightlies? If things actually work, I might grab one from eBay as a development/testing device as well.
Click to expand...
Click to collapse
Err, I meant LAF, its the partition on some LG devices where the Download Mode boot image lives. I've been spending a lot of time with my head buried in Codeaurora(CAF) repos, it's on the tip of my tongue.
Are you looking to get your Fx0 up and running with nightlies?
Click to expand...
Click to collapse
I already have to some extent. I should have a fully-functional test build any day now. Been codeblocked by some frustrating commits from Mozilla lately, broke my crap like 3 damn times in the last week. Refining the whole build setup now, trying to minimize reliance on prebuilt stuff, building as much as can, hence the interest in the pronto_wlan module, which I assumed was something that was exclusively build in the kernel tree (as seen on other LG devices), but apparently there's a CAF repo for that. Anyway, yeah.

culot said:
Err, I meant LAF, its the partition on some LG devices where the Download Mode boot image lives. I've been spending a lot of time with my head buried in Codeaurora(CAF) repos, it's on the tip of my tongue.
Click to expand...
Click to collapse
Ah, good to know. I'm a bit saddened to see that the prices on the Fx0 have gone up since just this past weekend. These must be getting more and more popular...
As an aside, you wouldn't happen to be knowledgeable about how to root the LGE LGL15G (LG Sunrise, 4.4.2, TracFone). I bought one as a beta testing device and as an Android Tablet/Wi-Fi toy, but there is no space on it due to the included bloatware O_O
culot said:
I already have to some extent. I should have a fully-functional test build any day now. Been codeblocked by some frustrating commits from Mozilla lately, broke my crap like 3 damn times in the last week. Refining the whole build setup now, trying to minimize reliance on prebuilt stuff, building as much as can, hence the interest in the pronto_wlan module, which I assumed was something that was exclusively build in the kernel tree (as seen on other LG devices), but apparently there's a CAF repo for that. Anyway, yeah.
Click to expand...
Click to collapse
I was reading on the Mozilla wiki that they've been doing some code cleanup to transition FFXOS to B2G, and to make it so the community can maintain it. Apparently, they've been a bunch of busy bees debranding everything and settling dependencies. Is this why your builds have been busted?
Do you think the Fx0 could replace the Flame as the defacto B2G development/testing device?
I'm torn between getting one for grabbing yet another ZTE Open and smashing my face against the wall trying to get it to fully work with nightly builds.
What's in that hiddenmenu? That isn't the normal developer tools menu I'm used to, right?
Is it the Blaze Initiative stuff (themeing, hacking, add-ons, mods, etc)?

Saijin_Naib said:
Ah, good to know. I'm a bit saddened to see that the prices on the Fx0 have gone up since just this past weekend. These must be getting more and more popular...
As an aside, you wouldn't happen to be knowledgeable about how to root the LGE LGL15G (LG Sunrise, 4.4.2, TracFone). I bought one as a beta testing device and as an Android Tablet/Wi-Fi toy, but there is no space on it due to the included bloatware O_O
I was reading on the Mozilla wiki that they've been doing some code cleanup to transition FFXOS to B2G, and to make it so the community can maintain it. Apparently, they've been a bunch of busy bees debranding everything and settling dependencies. Is this why your builds have been busted?
Do you think the Fx0 could replace the Flame as the defacto B2G development/testing device?
I'm torn between getting one for grabbing yet another ZTE Open and smashing my face against the wall trying to get it to fully work with nightly builds.
What's in that hiddenmenu? That isn't the normal developer tools menu I'm used to, right?
Is it the Blaze Initiative stuff (themeing, hacking, add-ons, mods, etc)?
Click to expand...
Click to collapse
Do you think the Fx0 could replace the Flame as the defacto B2G development/testing device?
Click to expand...
Click to collapse
Considering how much proprietary LG stuff is on the Fx0, I doubt it. Dunno. Since FxoS is transitioning to B2G is there even a need for a official dev device? I have no idea really.
What's in that hiddenmenu? That isn't the normal developer tools menu I'm used to, right?
Click to expand...
Click to collapse
Just the usual LG-specific hiddenmenu stuff. It seems like it was included in the initial release version for the Fx0... but from there, I don't know. Too bad I can't find any of the previous versions anywhere. Somebody must have them, somewhere.
Is it the Blaze Initiative stuff (themeing, hacking, add-ons, mods, etc)?
Click to expand...
Click to collapse
I have no idea what that is. Tell me more!
root the LGE LGL15G
Click to expand...
Click to collapse
No, I don't know anything about that. I did try one once, seemed like a decent value for the $15 or so it was selling for.

culot said:
Considering how much proprietary LG stuff is on the Fx0, I doubt it. Dunno. Since FxoS is transitioning to B2G is there even a need for a official dev device? I have no idea really.
Click to expand...
Click to collapse
Drat. I was hoping they (LG) had opened up some of the binary blobs in their source release. I guess you're right in that there is no need for an official dev device, but much like with LuneOS, I think there is a need for a "supported" target/reference device that sets the baseline for functionality. I was hoping the Fx0 could be this device, but with your evaluation of it being still a highly closed, it sounds like a poor choice.
culot said:
Just the usual LG-specific hiddenmenu stuff. It seems like it was included in the initial release version for the Fx0... but from there, I don't know. Too bad I can't find any of the previous versions anywhere. Somebody must have them, somewhere.
Click to expand...
Click to collapse
I've never seen this menu. Do the new Fx0 devices sold on eBay have this OS image installed, or is it something that was only shipped on the KDDI carrier sold devices?
culot said:
I have no idea what that is. Tell me more!
Click to expand...
Click to collapse
The Blaze initiative was a path Mozilla were looking to take FireFoxOS on by allowing the OS to be customized and tweaked much like the desktop browser. The device would have the ability to call up the DevTools to edit the code of any running webapp to modify the appearance and functionality of the program. From what I had read, this would extend to even privileged/system apps. In this manner, the user could add something to say the Messages app (like a timestamp for how late a message arrived), change the background color of the messages thread, etc. These add-ons could be submitted to the Marketplace for certification and download. Also, it was likely that users could directly share these modifications by Sharing activities including Email, SMS, etc.
There was also talk of migrating over various XUL add-ons from the desktop browser that would be compatible with FFXOS. That alone would have made the platform borderline unstoppable, as the possibilities for expansion of utility, safety, and aesthetics would be nearly endless.
All of this being said, I can't currently find the articles about this initiative anymore. I'll keep looking.
culot said:
No, I don't know anything about that. I did try one once, seemed like a decent value for the $15 or so it was selling for.
Click to expand...
Click to collapse
I got mine for $9.99, and it benches out to being fairly comparable to the Moto E, which is not a bad performance point to be at for around $10. Shame it is SIM-locked and very difficult to root and take the garbageware out of.

Saijin_Naib said:
I've never seen this menu. Do the new Fx0 devices sold on eBay have this OS image installed, or is it something that was only shipped on the KDDI carrier sold devices?.
Click to expand...
Click to collapse
It looks like maybe the hiddenmenu was removed with a FxOS v2 update that added the ability to edit APNs, something that had to be done in the hiddenmenu previsouly. Maybe...

Ah, crap, I was wrong: the hiddenmenu, along with a ton of other LG & KDDI stuff, was stripped out of the international/unlocked version, leaving it a slow, featureless shell. It's disgusting actually. I feel acutely slighted. It's amazing the difference between both the speed and the features of the Japanese and unlocked versions. Apparently in Japan this is actually a decent phone. Too bad the international/unlocked peeps got the shaft.
And here I thought FxOS in general was just slow and terrible: turns out that was just result of the hatchet job pulled on the unlocked variants of the Fx0.
I wonder if it would be possible to overcome the mozfree issue that prevents the old libs from working on newer B2G?
Gah! I feel angry.

Hey. Do you still want the original jap 2.0 images?

aflaton said:
Hey. Do you still want the original jap 2.0 images?
Click to expand...
Click to collapse
If you have a retail firmware, it would be much appreciated.