• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [DEV] Continuing Triumph ICS Development

Data seems real flaky.
I can connect to 3g but sometimes I have to restart my phone to get it to come back. also turning data on and off in the settings doesn't solve the problem either


Also when I overclock to 1400mhz my linpack score is 32 max. Is the OC kernel not fully implemented.
 
Getting haptics working with the capacitive buttons was indeed a pretty easy fix. While I was at it, I made sure to understand what input devices we actually have, what keys each can generate, and I cleaned up the keylayouts, which had a bunch of misleading mappings. Devices that only apply to qualcomm evaluation hardware, kitchen sink mappings in devices that only generate one or two events, etc.. I'll push it up and send a pull request, mantera.
 
Either I hadn't pulled the latest in a while, or my keylayout cleanup was what fixed the keyboard for me. Is the keyboard still borked for people? Mine's working great now.
 
I independently got it working as well. I just dropped in the hardware/qcom/gps folder from CM7 and uncommented the GPS variables in our BoardConfig.mk file.

Yeah, I haven't pushed up my stuff yet. Wanted to verify for sure that everything including navigation was working.

I just tested the navigation on my way to work this morning and everything is now working as well as cm7.

Will have to wait for tonight before I can push anything up.
 
Getting haptics working with the capacitive buttons was indeed a pretty easy fix. While I was at it, I made sure to understand what input devices we actually have, what keys each can generate, and I cleaned up the keylayouts, which had a bunch of misleading mappings. Devices that only apply to qualcomm evaluation hardware, kitchen sink mappings in devices that only generate one or two events, etc.. I'll push it up and send a pull request, mantera.

I'll pull this later tonight after work. Thanks.
 
Any answers to my earlier question about hardware acceleration? Is it working? If it's partially working, what's broken? Maybe I can try to help with my limited knowledge.
 
Any answers to my earlier question about hardware acceleration? Is it working? If it's partially working, what's broken? Maybe I can try to help with my limited knowledge.

I believe it's enabled, but not all features are 100% because we are not using the 3.0 kernal. Someone correct me if I'm wrong.
 
HW seems to work, noticing 15 fps in live wallpapers doesn't mean HW acceleration isn't working, it could mean there's something wrong with that particular wallpaper app, or the way it's being used, or maybe it's not optimized yet in CM9. To see if there's something wrong with HW acceleration in general, you'd have to run more tests, like using 3D benchmark apps & some games.
 
HW seems to work, noticing 15 fps in live wallpapers doesn't mean HW acceleration isn't working, it could mean there's something wrong with that particular wallpaper app, or the way it's being used, or maybe it's not optimized yet in CM9. To see if there's something wrong with HW acceleration in general, you'd have to run more tests, like using 3D benchmark apps & some games.

Good point. The UI itself seems to run from anywhere from 2-20 FPS, and the app drawer is quite noticeable (at least on my phone). I'll do some tests like Quadrant and report back.
 
Good point. The UI itself seems to run from anywhere from 2-20 FPS, and the app drawer is quite noticeable (at least on my phone). I'll do some tests like Quadrant and report back.

Yes, drawer is pretty bad. Is not using the 3.0 kernal have anything to do with random HW accel issues?
 
Well, my results: Hardware acceleration is certainly not optimized. Many of my tests get half FPS than they did in CM7 (Quadrant), which is good news- there's quite a bit of room for improvement. Quadrant score was 1803.
 
Got this while doing a repo sync a bit ago:

Code:
error: '/root/android/.repo/repo/.git/clone.bundle' does not look like a v2 bundle file
fatal: Could not read bundle '/root/android/.repo/repo/.git/clone.bundle'.

Is this bad? The word fatal tells me it's bad.
 
Yes, drawer is pretty bad. Is not using the 3.0 kernal have anything to do with random HW accel issues?

Could also be because of the conversion to new adreno 205 drivers. Since we never had old (CM7 & before drivers working with ICS), not sure if it worked better or not. Doomlord was the one who ported the new drivers over, some testing showed better performance, some showed worse from what I remember in other threads.

Unless we have a 3.0 kernel source code for a device in MT's family, it would be very hard to port all the changes Huawei/Motorola put into the 2.6.32.9 kernel just to get it to work on the MT, into a clean 3.0 kernel.
 
Could also be because of the conversion to new adreno 205 drivers. Since we never had old (CM7 & before drivers working with ICS), not sure if it worked better or not. Doomlord was the one who ported the new drivers over, some testing showed better performance, some showed worse from what I remember in other threads.

Unless we have a 3.0 kernel source code for a device in MT's family, it would be very hard to port all the changes Huawei/Motorola put into the 2.6.32.9 kernel just to get it to work on the MT, into a clean 3.0 kernel.

gotcha, are the old ones not compatible, or have they just not beentried yet? yeah merging 2.6.32.9 with 3 would be rough, but it make me curious what changes there would be in UI experience.
 
I don't think the 3.0 is as necessary as people seems to think for this port. There are other devices out there that run on 2.6.32.x through 2.6.39.x respectivly with fully/mostly functional ICS. The amount of code required to make that work is an insane amount of work. Other devs have dropped major projects because of the amount of work that is required for such a port. If things absolutly cannot be remedied with our current kernal, we should only seek that as a last resort. I spoke recently with a very good friend of mine that deals with this kind of thing and he said with closed source code, you might as well write all the drivers yourself, and that isn't easy at all. He said that the current kernal we use should support ICS for full functionality. Reworking or rewriting some of the drivers may be required to get it up and running, but it should be fine.
 
I agree with Sharpie if you guys can include all the things in 3.0 (including Proper Bluetooth peripheral mapping aka full controller support.. that ones for me hehe :D ) in the current kernel go for it.. if its possible it would save a lot of time and headaches..
 
I don't think the 3.0 is as necessary as people seems to think for this port. There are other devices out there that run on 2.6.32.x through 2.6.39.x respectivly with fully/mostly functional ICS. The amount of code required to make that work is an insane amount of work. Other devs have dropped major projects because of the amount of work that is required for such a port. If things absolutly cannot be remedied with our current kernal, we should only seek that as a last resort. I spoke recently with a very good friend of mine that deals with this kind of thing and he said with closed source code, you might as well write all the drivers yourself, and that isn't easy at all. He said that the current kernal we use should support ICS for full functionality. Reworking or rewriting some of the drivers may be required to get it up and running, but it should be fine.
So, it boils down to this?

  • There must be something off with the current kernel, which is why hardware acceleration isn't working fully
  • If it's not that, then it would be nearly impossible to hand-code all of the material needed for a 3.0 kernel (unless we march with fire and pitchforks to Moto's HQ)?
 
Back
Top Bottom