yashsingh1/xdaforums huggingface dataset:
[HTC Droid DNA] crpalmer:
Nothing seems to have changed with phone calls and bluetooth (at least not as far as I can tell).

Playing music with google music to any of my three bluetooth devices is working well, but maybe not perfectly (the third is a Voyager Pro headset). There is a little crackle between songs which is midly annoying. The signal strength seems significantly stronger than stock to me, but it's hard to tell without flashing back to a verizon ROM which I'm not going to bother doing. I am not an audiophile and therefore have no immediate opinion on audio quality.

As far as your car, I have no idea whether or not it will work. i would expect it to, but you'll have to wait for a build and try it out to see...
[HTC Droid DNA] Epic 4g:
Wi-Fi tether Question???

Just a quick question, what are people doing for Wi-Fi tether? I can't get it to work at all. Just so I know is Wi-Fi tether something that is broken on CM10.1?

People say that the Wi-Fi tehter app from the play store works but I have tried everything & it's still something that just won't connect. My tablet sees it but won't transfer data. Strange.

Is there any way that the Wi-Fi tether that comes in CM10.1 can work? Maybe I am doing something wrong?

Any help or insight would be greatly appreciated. Thanks in advance.
[HTC Droid DNA] fr4nk1yn:
I've seen in dev threads a few issues contributed to the ROM that I have on a fully stock system.

Crackling between songs is one of them.
[HTC Droid DNA] crpalmer:
Tried a little more with the Bluetooth. A couple of devices pair well but after disconnecting they never reconnect. One of which is my car that did the same thing on a stock ROM/kernel. The other device has never had any problems with my phone but might have the same problem with my nexus 7 (bluedroid stack).
[HTC Droid DNA] erikjonpeterson:
Try Barnacle wifi tether. Works great on flyhalf's cm10.1.
[HTC Droid DNA] chad0989:
Haha. I might have a lead for BT in call. Still working on it.
[HTC Droid DNA] crpalmer:
That would figure. I just got a new wired headset on Friday...

I just sent a few pull requests. When you have a chance to look at them, can you either merge them or close them (I promise I won't be offended, hell, one of them I didn't even "merge" for myself!).
[HTC Droid DNA] chad0989:
Fixed wireless tethering and I *think* the rotation freeze issues.
[HTC Droid DNA] chad0989:
Don't release any builds with the newer egl drivers I just pushed. Performance is not good at the moment.
[HTC Droid DNA] azndan2:
Chad, did you increase the gain on the speaker phone volume? I was pleasantly surprised this morning on the new 5/30 build where I could actually clearly hear the person I was talking to.
[HTC Droid DNA] .torrented:
when did you push them? just recently or earlier today?
[HTC Droid DNA] chad0989:
https://github.com/CM10DNA/android_vendor_htc_dlx/commit/79b2efb561acecfb71a94a34db88e8dc64a5cb78
[HTC Droid DNA] crpalmer:
Did this not pan out or has it just dropped down in the list of priorities? If you still have an idea worth pursuing, care to share it and I'll see if I can spend some time looking at it this weekend?
[HTC Droid DNA] chad0989:
It didn't pan out unfortunately. At a bit of a loss again right now. I'll let you know if I come up any other ideas.
[HTC Droid DNA] Imacellist:
Would this be of any help to us? I figure not but thought I'd share anyways. http://www.droid-life.com/2013/05/3...verizons-galaxy-s4-as-long-as-you-are-rooted/
[HTC Droid DNA] bb12489:
Its the same guide that I linked to in our wallet thread here. I believe we're making some progress, but I hit a wall with what I can do. I can provide logcats for anyone who is interested though.
[HTC Droid DNA] Imacellist:
OK thanks.
[HTC Droid DNA] chad0989:
Looks like someone made some progress with BT in call:

http://review.cyanogenmod.org/#/c/43541/
[HTC Droid DNA] crpalmer:
I cherry-picked that commit and updated the board config and rebuilt it (not make clean) and it didn't seem to make any improvement in the audio quality for me with my BT headset. It's possible that somehow it needs a clean build or I did something stupid though.

This is true for the cm-10.1-chad kernel and my kernel with the audio drivers sync'ed to the CM M7 drivers.
[HTC Droid DNA] chad0989:
If you update anything in your BoardConfig you always want to make clobber. For some reason if the build isn't clean it doesn't re-read it and rebuild the parts with the new flags.
[HTC Droid DNA] crpalmer:
I added a #error in the new code and it did fail the build, but I didn't have time to try a clean build (development time, aka nap time for the kids, was about done).

I'll try again later.
[HTC Droid DNA] chad0989:
Fixed the weird multitouch issues.
[HTC Droid DNA] Epic 4g:
Dude you are the man. My 5 year old son told me to thank you because he can play Gunman Clive again. lol
[HTC Droid DNA] crpalmer:
I did a clean rebuild with this commit, added some log messages to it to make sure it was really being used and it sounds better to me, but not great. The "better" could even just be a placebo effect (there is a fair bit of elapsed time between trying the 'before" and "after"). Again, I tried both with and without pulling the m7 (kernel) audio drivers.
[HTC Droid DNA] chad0989:
Hmm, maybe we use different IDs than the M7 or something else is needed that is missing. I can't test it myself until later tonight when I have access to a BT headset.

Right now I'm trying to get our FB/gpu up to date so we get decent performance out of the QDevNet blobs.

CM is going nuts with audio changes for the JF right now so I fully expect some breakage soon that will have to be fixed.
[HTC Droid DNA] crpalmer:
I still hope that i did something stupid and the BT change will work for you. I have very bad cell reception at home too, which is also a bit of a confound for testing audio quality... In terms of the IDs, I think that they must be the same unless there is some magic in there. I verified using log messages that it was really remapping the IDs and I would expect if the 1027 / 1127 IDs weren't correct then I wouldn't have gotten any audio?
[HTC Droid DNA] pyroguysf:
Hey guys, I've just learned to build, etc and have done so successfully for our device from the instructions. Haven't really been using AOSP ROMs on my DNA since I want bluetooth audio, but as an audiophile and with my new knowledge I'd be willing to help you guys test. I'm still trying to wrap my head around git and repo, but I did a fresh sync and build about 10 hours ago I can try unless your working on uncommited stuff, in which case you might have to instruct me on how to cherry-pick the right things or whatever, haha. :p

Just thought I'd offer, otherwise keep up the great work guys.
[HTC Droid DNA] chad0989:
I pushed the fb work to cm-10.1-fb (kernel and device). If others can pull and test it out that would be great. So far it seems to work well but since its a pretty huge change we should probably test it for a bit and see if there are any issues.

Edit: Obviously MHL isn't going to be working right now since I didn't pull it in yet. Also the low backlight issue will probably be back because I haven't pulled that in yet. Debating how I want to patch up from here.
[HTC Droid DNA] crpalmer:
What did you do on this branch? Aka, what are you patching from and what was the starting point?
[HTC Droid DNA] chad0989:
I'm pulling from CAF JB 2.5.1 (https://www.codeaurora.org/cgit/quic/la/kernel/msm/log/?h=jb_2.5.1). I just pushed a bunch more commits.

We should be patched up to current with that branch. Not sure if I want to stick with this, as its running quite well, or try to patch up closer to bleeding edge.
[HTC Droid DNA] crpalmer:
If you mean caf/msm-3.4 as the bleeding edge, I would say to as-is. I keep an eye on the caf commits and my feeling is that if you patch up to its head then you are committed to keep applying all their patches at least until the next release.

Does this fix the performance problem with the egl commit that you pushed awhile ago?
[HTC Droid DNA] chad0989:
Yes. I believe it is running as it should now.
[HTC Droid DNA] chad0989:
I found a couple issues. One with video playback and one during certain animations. Need to check the logs when I have some time to see if I can sort it out.
[HTC Droid DNA] crpalmer:
This didn't boot for me (even after doing a sync this morning to pull in the "oops" fix from last night). Do you have any unpushed kernel changes? The most obvious potential problem in the dmesg:

<3>[ 4.620479] c1 205 ion_system_heap_map_user: cannot map system heap uncached

<3>[ 4.620540] c1 205 ion_mmap: failure mapping buffer to userspace

which is about when the HTC splash screen should be replaced by the cyanogenmod splash screen, but isn't (the display just goes black).

To build, I changed the branch for the kernel in .repo/manifest.xml to cm-10.1-fb and then doing a clean build.
[HTC Droid DNA] chad0989:
Are you sure you got the cm-10.1-fb branch in the device tree also? We moved to the new ION API.

https://github.com/CM10DNA/android_device_htc_dlx/commit/83c0fe9db2786f54a5843794edf7f437247c4210
[HTC Droid DNA] crpalmer:
Yes, that's exactly what I missed. I didn't see that branch!

BTW: I browsed some of the changes in arch/arm/mach-msm and I'm very excited by this set of commits. Very nice work pulling it together!
[HTC Droid DNA] pio_masaki:
Will this branch be the current branch from now on?

Tapatalked from my HTC DNA - Carbon
[HTC Droid DNA] chad0989:
No. Its not ready. I'll merge it when it is.
[HTC Droid DNA] pio_masaki:
Cool, I didn't think it would be but figured I'd ask first.

Tapatalked from my HTC DNA - Carbon
[HTC Droid DNA] crpalmer:
I haven't spent a huge amount of time playing with it and very little time investigating anything.

I'm seeing issues opening the menu in many different apps and when there are pop up messages (e.g. apps that have been granted su access, etc.). I'm guessing that this is the same thing that you're seeing. There are no log messages (dmesg or logcat) during this time.
[HTC Droid DNA] chad0989:
Yep. You'll get it during video playback also. If you turn off overlays it disappears. Also, and this is odd, it doesn't really seem to happen when wifi is off either. Maybe it's an issue with sharing resources?

If we can resolve that, overall I feel its much improved.
[HTC Droid DNA] crpalmer:
Sorry, I haven't had much of a chance to look at this. In principle, I definitely agree that this is better!

I was trying to understand where there might have been a problem introduced with the overlays. The commit:

commit e984076cc333f280270d4eb930d06354b4cb49cb

Author: Chad Froebel <chad0989@rochester.rr.com>

Date: Sun Jun 2 09:44:29 2013 -0400

Bulk update video to JB 2.5.1

Change-Id: I268f5e2fa933a7738bd3262b34b3de33caecc87b

confuses me a little bit. I would have expected

git diff --stat caf-msm/jb_2.5.1 e984076cc333f280270d4eb930d06354b4cb49cb drivers/video/msm

to have no diffs but it actually has:

drivers/video/msm/mdp.c | 159 +++++++-------

drivers/video/msm/mdp.h | 14 +-

drivers/video/msm/mdp4.h | 22 +-

drivers/video/msm/mdp4_overlay.c | 248 +++-------------------

drivers/video/msm/mdp4_overlay_dsi_cmd.c | 71 +++----

drivers/video/msm/mdp4_overlay_dsi_video.c | 135 +++---------

drivers/video/msm/mdp4_overlay_dtv.c | 100 +--------

drivers/video/msm/mdp4_overlay_lcdc.c | 106 ++-------

drivers/video/msm/mdp4_overlay_writeback.c | 2 +-

drivers/video/msm/mdp4_util.c | 2 +

drivers/video/msm/mdp4_wfd_writeback_panel.c | 2 +-

drivers/video/msm/mipi_dsi.h | 3 -

drivers/video/msm/mipi_dsi_host.c | 61 +-----

drivers/video/msm/msm_fb.c | 112 ++++++----

drivers/video/msm/msm_fb.h | 6 +

drivers/video/msm/msm_fb_panel.h | 2 +

16 files changed, 290 insertions(+), 755 deletions(-)

Since this obviously included *overlay*.c, I did git diff caf-msm/jb_2.5.1 | patch -p1 -R to undo these changes and then made it compile (which including re-introducing the display_on / display_off driver commands). This kernel boots but the screen never turns on (after the HTC boot logo).

I also tried taking the cm-10.1-fb head and applying the jb_2.5.2 diffs and I had the same "no display" problem.

So, questions:

* What is the Bulk update video to JB 2.5.1 commit? It has a change-id but I couldn't find it by a google search for that change-id...

* Any idea what in the diff --stat, above, would cause the display to not work and/or why I would suddenly have a problem when adding the jb_2.5.2 commits on top of what you did?
[HTC Droid DNA] chad0989:
It was pulled over from an old tree that was synced about 03/18. Somwhere around this commit:

https://www.codeaurora.org/cgit/qui...1&id=548ff607d8d20792203260e0d74e013b43ea3781

The rest of the commits patch up to current.

If you reset cm10.1-fb to 4f4caad1cb8256893c26e7d7fac087700b05f16c and revert e9391c9a35acb5907919fa001cba39a48071396d

then diff it with CAF you'll see the only changes are for our panel.

As for my current progress, it appears the flickers are definitely an underrun. In board-monarudo-panel I changed:

pinfo.lcdc.underflow_clr = 0x0

to

pinfo.lcdc.underflow_clr = 0xff

so it would flash blue if its an underrun rather than black. It does flash blue.

I've since increased the mdp bandwidth a good amount and it seems to have gotten rid of ~90% of the issue. However, a surefire way to still reproduce it is to play an HD/HQ youtube video in portrait over WiFi. I don't seem to have the issue in other situations now.

I pushed my latest updates where I've been trying various things to sort out the issue. I suspected it could be a DMA problem also so there are a few commits in there that explore that.

I hate pulling over bulk source like this and trying to make it work and troubleshoot. It would be so much better if we could find HTCs fork point and patch up.
[HTC Droid DNA] chad0989:
Okay. I believe BW is the issue and that maybe we should increase it some more. Browsing through some more, the newer mdp4_overlay calculates bw requirements based on a few factors.

Previously the bw was simply set based on a few scenarios:

static int mdp4_calc_pipe_mdp_bw(struct msm_fb_data_type *mfd,
struct mdp4_overlay_pipe *pipe)
{
u32 res;
int ret = -EINVAL;

if (!pipe) {
pr_err("%s: pipe is null!\n", __func__);
return ret;
}
if (!mfd) {
pr_err("%s: mfd is null!\n", __func__);
return ret;
}

if (pipe->flags & MDP_DEINTERLACE) {
pr_info("%s deinterlace requires max mdp bw.\n",
__func__);
pipe->req_bw = OVERLAY_PERF_LEVEL1;
return 0;
}

if (pipe->pipe_type == OVERLAY_TYPE_BF) {
pipe->req_bw = OVERLAY_PERF_LEVEL4;
return 0;
}

res = pipe->src_w * pipe->src_h;

if (res <= OVERLAY_WSVGA_SIZE)
pipe->req_bw = OVERLAY_PERF_LEVEL4;
else if (res <= OVERLAY_VGA_SIZE)
pipe->req_bw = OVERLAY_PERF_LEVEL3;
else if (res <= OVERLAY_720P_TILE_SIZE)
pipe->req_bw = OVERLAY_PERF_LEVEL2;
else
pipe->req_bw = OVERLAY_PERF_LEVEL1;

return 0;
}

Now its set based on calculated requirements and the factors we provide, which can vary based on board/display combo. I'm guessing they made the change to reduce power consumption by using only the amount of bw required for the task. I think we might just need to adjust our factors some more. I'm believe that previously we were always running at max BW for overlays since we have a 1080P display.
[HTC Droid DNA] chad0989:
Increasing the bandwidth further does seem to remedy the rest of the issue. Will push for testing.
[HTC Droid DNA] crpalmer:
That bandwidth looks believable. My math says that we may really need that bandwidth:

1080 * 1920 * 32 bpp * 60 fps = 3.9 GB

I do wonder why the m7 is fine with 2GB. My guess is that there is a doubling for them (or halving for us) that I'm not seeing somewhere in this code. Their bandwidth configuration has MDP4_BW_IB_DEFAULT_FACTOR of 1.25 (our is 2.5) and the _AB_ factor is 1.15 (vs. 2.3 for us) which sounds like we are a factor of 2 higher for the entire computation.
[HTC Droid DNA] chad0989:
I agree. I merged what we have now. I'm going to look through the jb2.5 branch and see if any of the more recent commits relating to how the bw is divided can explain the difference.
[HTC Droid DNA] crpalmer:
FYI, my general impression is that the battery utilization under light load (or "no load") is definitely better I have periodically done a simple test of my phone where I leave it (basically) untouched with the screen on the lowest brightness, no wifi, in a very strong 4G location and it was better after these changes.

Unscientifically, I feel like the screen-on battery drain may be higher now. I do wonder if I am somewhat biased by the knowledge that you doubled the maximum video bandwidth... :)

In terms of this merge, I just wanted to confirm that you really meant to do this: you are no longer building acpuclock-8960.o and are now building apuclock-8064.o instead?
[HTC Droid DNA] chad0989:
That's right. We use apuclock-8064.o + acpuclock-krait.o now instead.
[HTC Droid DNA] chad0989:
I bumped the factors up to 3x because of the reported issue in youtube (which I was able to replicate). I think we're good now.

I'm going to keep researching what has changed between 2.5.1 and more current branches to see why the One doesn't need as large of factors. Now that we're in line with a CAF branch I'm going to see if I can patch up to where the other CM devices are (JB 2.5.04.02.02.040.xxx) without any bulk commits. I just need to find the branch point for 2.5.1.

Doing some more research we're not the only device that there was an issue with. I found this commit:

https://github.com/CyanogenMod/andr...mmit/7958864331cf33b0953265b7d68d1f6256ae707f

Which shows that the d2 also needed 3x factors to eliminate underruns at one point also. They are since more up to date though and it looks like they only need ~2x now:

https://github.com/CyanogenMod/andr...mmit/41f55d87458439a481cf587aabd78c952509aab9

Edit: Also with the new factors, it is working fine but it is requesting pretty crazy large amount of BW, from kmsg:

<4>[ 235.853196] c3 259 mdp4_overlay_mdp_perf_req: req ab bw=5016322048 is larger than max bw=4000000000

<4>[ 235.853196] c3 259 mdp4_overlay_mdp_perf_req: req ib bw=5452529664 is larger than max bw=4000000000

<4>[ 235.853258] c3 259 mdp4_overlay_mdp_perf_req: req ab bw=5016322048 is larger than max bw=4000000000

<4>[ 235.853288] c3 259 mdp4_overlay_mdp_perf_req: req ib bw=5452529664 is larger than max bw=4000000000

<4>[ 235.869922] c3 259 mdp4_overlay_mdp_perf_req: req ab bw=5016322048 is larger than max bw=4000000000

<4>[ 235.869922] c3 259 mdp4_overlay_mdp_perf_req: req ib bw=5452529664 is larger than max bw=4000000000

It looks like cyanogen didn't like the warning message and just got rid of it. I don't really like that idea though.
[HTC Droid DNA] chad0989:
Okay. Pushed some more changes. I think we can get away with lower factors now. At 200/210 with a max bw of just over 4000000000.
[HTC Droid DNA] crpalmer:
I am running pretty happily without overriding the ab/ib factors at all (aka at 1.15 / 1.5).
[HTC Droid DNA] chad0989:
Hmm. I still had one or two underruns when I tried. That was before the last set of patches to fix the rotation freeze though. I'll give them a good long test and lower them again if there's no issue.
[HTC Droid DNA] crpalmer:
I also just posted a kernel with them lowered which will get some extra people testing it too. I'll let you know if anyone reports a problem with it.
[HTC Droid DNA] crpalmer:
Spoke too soon, found a couple of underruns. Setting ab to 1.25 didn't fix them both but 1.5 did (ib unchanged).
[HTC Droid DNA] rjd584:
I'm running FlyHalfs 6/8 build and Bluetooth audio is working for me. I thought this was still broken. I'm using an alpine head unit in my truck. Haven't tested call audio.

The audio does drop out for a split second every now and then and there is a cracking noise very rarely.
[HTC Droid DNA] chad0989:
It's been working for awhile but still has a few issues.
[HTC Droid DNA] renzo.olivares:
hey chad question i can't find it anywhere but are we inheriting from apq8064-common, and what ril are we using i don't see it defined anywere lol thanks
[HTC Droid DNA] .torrented:
I'm not sure what they were doing exactly but they moved audio_policy.conf from msm8960-common to the m7-common tree so now we will lose call audio.

and also removed this from msm8960.mk

$(LOCAL_PATH)/configs/audio_policy.conf:system/etc/audio_policy.conf \
[HTC Droid DNA] renzo.olivares:
it's cause m7 supports the new low latency changes they made while the older msm8960 devices do not
[HTC Droid DNA] .torrented:
Right I saw that, so what was throwing me off is that how do we use that now if it got moved to the m7-common stuff?
[HTC Droid DNA] renzo.olivares:
well i'm not sure how this works yet but don't we pull msm8960-common from cm10dna's git and not the cm's git ?

edit: nvm umm yea that probably will break stuff i believe the dna supports low latency audio i think chad just needs to pull in the kernel changes but idk it's best he answer the question
[HTC Droid DNA] .torrented:
we are using the msm8960-common from cm's git, thats why I mentioned the deal with the audio because thats where it is at and it was broken in one of my builds of Root-Box i ported over

yea so for now i had to just fork it and revert the audio changes, im still trying to figure it all out, this is all new to me haha

(also wanted to say, the ril thing you asked has something to do with the msm8960-common from cm, i would look there)
[HTC Droid DNA] renzo.olivares:
yea everything makes sense to me now that i realize that we are pulling cm's msm8960-common
[HTC Droid DNA] crpalmer:
Did you also revert this commit?

commit 9e1661aa001153d540343b7669acd7aeed7b626e

Author: Ethan Chen <intervigil@gmail.com>

Date: Tue Jun 18 20:34:01 2013 -0700

msm8960: use CAF media variant

Change-Id: I1779a74076793d868b230e5b7c02ad5ac5503dc9

Doing a clean build (I don't know what happens when not doing a clean build), this breaks the build for me...

In terms of what they did with the audio_policy.conf, they removed audio_policy.conf from the msm8960-common repo because not all msm8960 devices support low latency audio and therefore the moved a low latency audio to the one set of devices that does support low latency audio and they also moved the original audio_policy.conf to the other device (I think there are only two) that does not support low latency audio. So we just need to make the corresponding change to our repo (which I assume they would have done as part of this change if we were an official port):

* copy the audio_policy.conf to device/htc/dlx/configs

* install it by making this change:

diff --git a/device_dlx.mk b/device_dlx.mk

index 3b9fc55..23a7639 100644

--- a/device_dlx.mk

+++ b/device_dlx.mk

@@ -79,6 +79,9 @@ PRODUCT_COPY_FILES += \

PRODUCT_COPY_FILES += \

device/htc/dlx/dsp/snd_soc_msm/snd_soc_msm_2x_Fusion3:/system/etc/snd_soc_m

+PRODUCT_COPY_FILES += \

+ device/htc/dlx/configs/audio_policy.conf:system/etc/audio_policy.conf

+

# Keylayouts and Keychars

PRODUCT_COPY_FILES += \

device/htc/dlx/keylayout/AVRCP.kl:system/usr/keylayout/AVRCP.kl \
[HTC Droid DNA] .torrented:
No I didn't revert the media variant commit, (no idea what it is for, besides that it has something to do with some media stuff) but yea, i guess i didnt realize we could just add that to the device itself.

Edit* But even if we do that, we would still need to revert that Use media CAF variant, so why not just revert both and just leave the audio_policy.conf where it originally was, if using it will break things anyways.
[HTC Droid DNA] crpalmer:
We don't want to have to revert either of them.

I haven't had a chance to see what the right way to fix my build was, I was mostly just curious if you were seeing the same problem. I only really got as far as a repo sync / brunch this morning and haven't looked into it much more (work makes android development much slower...).