Root [DEV] Continuing Triumph ICS Development

evanrobinson85 said:

androidforums.com/triumph-all-things-root/492599-ics-developement-end-user-discussion.html Chit chat thread. Enough said. everyone remember this is a development thread. Keep it on topic please. It sucks waking up in the morning thinking I will see some new development only to find 6 new posts having nothing to do with development.

Click to expand...

But we are not "end users". Someone's computer got fried while building, and we are just trying to help them get back on their feet. It might be a bit off topic, but certainly not end user material...

...sorry for trying to be helpful. I only said it with the best intentions. ;-)

It developed naturally when discussing development, so it makes some sense to be here, but it's not exactly on topic either. Why don't we agree to make a new thread if the computer discussion wants to continue, as the end user thread is not exactly a "chit chat" thread. No need for anyone to get worked up. We should keep the discussion on development here though.

FYI there is a computer & IT section in the lounge, you can get some great advice there.

evanrobinson85 said:

That's mantera's Chit chat thread specifically for off topic subjects. I'm not trying to be rude or anything, but everyone knows the rules and just ignores them.

Click to expand...

I do want to say that the end user thread (started by zachavm, not mantera) is not for "off topic" but rather ICS non dev posts. There is a whole lounge section for "chit chat".

If you have issues with posts, it is best to report them. Let the mods handle things. It isn't necessarily ignoring rules, just getting caught up trying to help someone in a thread devoted to something else.

so acer icona has the same camera and they just got ics drivers. is that any help to us?

evanrobinson85 said:

...sorry for trying to be helpful. I only said it with the best intentions. ;-)

Click to expand...

No need to be sorry. Everyone has the right to voice their opinions on the internet and we know you said it with the best intentions.

Hmm...msm_get_stats from drivers/media/video/msm/msm_camera.c (from kernel source) is timing out for whatever reason when I make a call to getParameters from CameraService.

mantera said:

Do you see if you're getting anything returned from the camera service?

Click to expand...

The CameraService crashes and media.server along with it.

Yes. It's drivers/media/video/msm/msm_camera.c . I did not make any modifications to the file.

I just uploaded my changes to "experimental" branches at:

https://github.com/progmanos/android_packages_apps_Camera/tree/experimental

https://github.com/progmanos/android_frameworks_base/tree/experimental

https://github.com/progmanos/android_hardware_qcom_camera/tree/experimental

I should also note that many of the changes were for debugging purposes, and the camera still doesn't work yet. The code will need to be cleaned up later.

So CM9 for the HP Touchpad got video playback working (including Netflix!). I know it is a completely different device, but is there any chance the fix applies to us?

https://plus.google.com/117962666888533781522/posts/5SCcwSMx9Sv

mantera said:

If you can figure out the commit, we can try it.

Click to expand...

I've been poking around github and r.cyanogenmod.com trying to find the commit(s) where the touchpad team fixed it, but haven't been able to yet. I suspect that whatever they did may have been submitted to gerrit but hasn't been merged yet because the unofficial nighties for the touchpad do not contain the fixed video yet. Or maybe they haven't released the fix at all yet.

Looking through the open commits in gerrit, there are a lot that have to do with video decoders, stagefright, and omx, a whole bunch by this guy. I'm kinda hoping that once the cm team merges them then video playback on our Triumph just magically starts working (I know its a long shot).

But if someone here actually understands what all those commits do maybe they will help.

mantera said:

I took a look at those commits and there's a lot of them. I think the best course of action is to just let the review process go through them as normal.

It's a pain if I pull them early and then they get merged because it takes a little bit of work to get them merged in properly to our repo at that point. However, we'll see how long it takes them to commit some of this stuff.

Click to expand...

Agreed. Though i was taking a look at Lord clockan's desire HD builds to see if he is able to get it working on an adreno chip.

It looks like he is close but doesn't quite have it working. If/when he does, I'll try to mimic it

I just can't leave the wifi auto connect issue alone (since it affects me) so I did a system dump while the phone will not auto connect and found this in the wifi section.


Locks acquired: 0 full, 0 full high perf, 2 scan
Locks released: 0 full, 0 full high perf, 2 scan

Locks held:


Then I found in the Android reference the following:

public static final int WIFI_MODE_FULL

Since: API Level 3
In this Wi-Fi lock mode, Wi-Fi will be kept active, and will behave normally, i.e., it will attempt to automatically establish a connection to a remembered access point that is within range, and will do periodic scans if there are remembered access points but none are in range.
Constant Value: 1 (0x00000001)
public static final int WIFI_MODE_FULL_HIGH_PERF

Since: API Level 12
In this Wi-Fi lock mode, Wi-Fi will be kept active as in mode WIFI_MODE_FULL but it operates at high performance with minimum packet loss and low packet latency even when the device screen is off. This mode will consume more power and hence should be used only when there is a need for such an active connection.
An example use case is when a voice connection needs to be kept active even after the device screen goes off. Holding the regular WIFI_MODE_FULL lock will keep the wifi connection active, but the connection can be lossy. Holding a WIFI_MODE_FULL_HIGH_PERF lock for the duration of the voice call will improve the call quality.
When there is no support from the hardware, this lock mode will have the same behavior as WIFI_MODE_FULL
Constant Value: 3 (0x00000003)
public static final int WIFI_MODE_SCAN_ONLY

Since: API Level 3
In this Wi-Fi lock mode, Wi-Fi will be kept active, but the only operation that will be supported is initiation of scans, and the subsequent reporting of scan results. No attempts will be made to automatically connect to remembered access points, nor will periodic scans be automatically performed looking for remembered access points. Scans must be explicitly requested by an application in this mode.
Constant Value: 2 (0x00000002)

From what it looks like to me is that it is in scan mode only.

I may be way off since I know next to nothing about the android system or c programming but this does raise a flag in my head. Hope this helps.

FWIW it shows the same in the system dump mwhen it does manage to connect automatically.

Mantera,

I'm currently messing around with installing ubuntu on my triumph and I have the ICS Rom that you and a group of others have been working on installed and I was wanting to check and make sure that the kernel that is used for the ICS rom has loop device support?

Thanks,
2010gleek

I think I may have found how to fix the data limit issues (see http://androidforums.com/triumph-all-things-root/503210-data-usage-warning.html). Its definitely a kernel issue, but I have never built a kernel myself and I don't have the time today to figure that out, so I can't test this.

In the following file:
/net/netfilter/xt_socket.c

Comment out or delete lines 26-32:


My theory is that our kernel doesn't support nf_defrag_ipv6 and that part of the code is causing our data limit feature to be only half functional.

See here for an example:
https://github.com/CyanogenMod/andr...ory/blob/ics/Kernel/net/netfilter/xt_socket.c

If someone with kernel building ability could try that out for me, that would be great.

Disclaimer: I know very little about kernels so I could be completely off base here. Feel free to call me an idiot if this makes no sense.

mantera said:

The option is there in the kernel config as far as I can tell:

CONFIG_BLK_DEV_LOOP=y

Click to expand...

Thank you so much!!