• 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

evanrobinson85 said:
androidforums.com/triumph-all-things-root/492599-ics-developement-end-user-discussion.html Chit chat thread. Enough said. :-p 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...
 
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.
 
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.
 
progmanos said:
Yes. It's drivers/media/video/msm/msm_camera.c . I did not make any modifications to the file.
Click to expand...

Ok, I just wanted to make sure because, obviously, the path in our kernel is

drivers/media/video/msm/msm_camera.c

and not the

drivers/media/video/msm_camera.c

So if it was looking in the wrong place, it would make sense that it was crashing. But since you say, that is the correct path, then there's something else going on.

I just compared the cm7 and cm9 versions of that kernel file and they're basically the same so I don't think the kernel is the issue. What parameters is the CameraService looking for when comparing between the cm7 and cm9 versions? Are they looking for different parameters?
 
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.
 
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.
 
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
 
NateMckn said:
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
Click to expand...

Sounds like a plan.
 
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
 
2010gleek said:
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
Click to expand...


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

CONFIG_BLK_DEV_LOOP=y
 
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:

Code: 
#if defined(CONFIG_IP6_NF_IPTABLES) || defined(CONFIG_IP6_NF_IPTABLES_MODULE)
#define XT_SOCKET_HAVE_IPV6 1
#include <linux/netfilter_ipv6/ip6_tables.h>
#include <net/ipv6.h>

#define nf_defrag_ipv6_enable()
#endif

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.
 
NateMckn said:
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:

Code: 
#if defined(CONFIG_IP6_NF_IPTABLES) || defined(CONFIG_IP6_NF_IPTABLES_MODULE)
#define XT_SOCKET_HAVE_IPV6 1
#include <linux/netfilter_ipv6/ip6_tables.h>
#include <net/ipv6.h>

#define nf_defrag_ipv6_enable()
#endif
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.
Click to expand...

I'll take a look.
 
You must log in or register to reply here.
Back
Top Bottom