[Transformer TF300T Android Development] linuxsociety:
I've been doing a bit of researching on the device before jumping into the coding, so every little bit of insight helps, I know the tf700 and tf300 share the same kernel sources for the most part, but are the devices backward compatible kernels completely? Just from what I have read on a few threads, there are some issues with some hardware and the tf700 kernels with the tf300.. I'm not familiar with the row scheduler yet, is it an I/O scheduler or is it a kernel task scheduler such as BFS/CFS/Autogroup? I had intended to include the Autogroup scheduler for this device, as it has been well tested on my other devices, and improves overall stability, speed, responsiveness (and yes those benchmark scores will raise a very noticeable amount haha). Autogroup was originally for linux, and use the TTY task grouping, which isn't compatible with android, in my Acer kernels I patched it so that it used UID task grouping, and like I mentioned, everyone was very pleased with it (although most people don't completely understand the concepts)

About setting clock speeds in init scripts, thats completely common, and usually its the strategy that most apps take too, they just automate script writing/editing process. I actually want to go in the kernel's sources and edit the cpu freq tables for the highest stable overclock combination possible, yet keep a default clock for the kernel that is known to work and not cause problems. Then of course users can use the init.d scripts as you mentioned to set cpu frequencies at boot, or per event cpu freq as they please.

Governors are an important thing seems to be left out in the tf300t community from what I have seen. I personally want to try to get the preferrered governors I am experienced with working with this device such as, Smartass(v2), Savagedzen, Intellidemand, Wheatley, Lulzactive, Lionheart, and all the stock standard GPL governors.

For I/O Schedulers I'd like to add: BFQ, CFQ, SIO, DEADLINE, and V(R) (based on stability and performance on other devices I have developed with, I'd expect the default I/O scheduler to be V(R), however its hard ot say at this point as no testing has been done yet).

For underclocking, you mean undervolting? If so then: We'll most likely have to just see what the device likes with trial and error on a few test runs, although this shouldn't be hard to achieve. If you mean underclocking, I'm not sure I exactly understand what you'd be trying to accomplish as this feature is already achievable with stock kernels???

I really appreciate all the hard work that you have put into this community, as well as the other devs, and appreciate all the great welcomes!! Thanks!! Keep up the good work and I look forward to working with you guys!

My plan is to take the stock kernel sources and implement the features that I speak of. Also I will probably be referencing other kernel devs sources throughout this process, but my current intention is to base my kernel from stock, and put most of the work I put in myself and if there is anything that the other devs add that I haven't added I will patch those in as well. Generally it is much easier to work with a stock kernel and manually implement features, than to take someone elses work and try to guess at things they have done. If sources are all on git servers, then it will make referencing a whole lot easier, but if sources to most kernels are just zipped/tarred up then it makes comparing things a PITA.

As for the Pegasusq governor, that shouldn't be a problem, as long as it plays well with our processor/board. I am all about as many governors as possible :D Just sometimes so many options makes debugging harder when people are experiencing stability issues. I will keep anything mentioned here open for implementation, and we'll justs have to see what works and what doesn't.

I appreciate all the great pointers and ideas guys. Like I said I look forward to working with you all. For now its bed time in KY. Night guys!