yashsingh1/xdaforums huggingface dataset:
[HTC Droid DNA] .torrented:
Yeah, I hear ya about work, well I have today off so I have a little bit of time to play around with some stuff, I haven't been able to get a build out because they are working on root-box stuff last time I tried to build something else was broken and it failed, so I will try today and see what happens. I'll try a couple things out and report back in a bit

I really need to switch from my VM to an actualy HDD install, would speed up my builds to about 30~40 minutes or so from 80~90 minutes, I probably will do that today as well heh
[HTC Droid DNA] chad0989:
I've been really busy with work. I'll try to get us up to date sometime this weekend.
[HTC Droid DNA] crpalmer:
I haven't had a lot of time to work on the changes that have been pushed this week. Here are some notes and pointers in case they help you from the bit I have been able to do. Feel free to ignore all of this and reject any and all pull requests, I promise I won't be offended.

There was a big flurry of commits pushed to the m7 kernel. I cherry-picked the bluetooth/bluesleep and the audio ones in this branch:

https://github.com/crpalmer/android_kernel_htc_dlx/commits/cm-10.1-chad-m7-spew

Bluetooth audio (not in call) seems a little choppy to me. I wonder if the msm_serial changes are maybe at fault? The other big difference is that the m7 is using a 4 mbit bluetooth baud rate so I was going to consider changing that again (last time I did so, it didn't seem to have any effect).

I sent a pull request for the trivial change to add the audio_policy.conf if you want it.

The cm10.1 build was failing and I hacked it to build by making this change in hardware/qcom/media:

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

index 6689933..e7fdeb4 100644

--- a/Android.mk

+++ b/Android.mk

@@ -1,9 +1,9 @@

ifneq ($(filter msm8960 msm8660 msm7x30,$(TARGET_BOARD_PLATFORM)),)

ifneq ($(TARGET_QCOM_DISPLAY_VARIANT),legacy)

-ifeq ($(TARGET_QCOM_MEDIA_VARIANT),)

+#ifeq ($(TARGET_QCOM_MEDIA_VARIANT),)

include $(call all-subdir-makefiles)

-endif

+#endif

endif

endif

This change breaks google music and (I think) bluetooth audio in youtube. I spend 0 time on this thinking that maybe the kernel changes were required and focused on that instead but they haven't magically fixed it...
[HTC Droid DNA] .torrented:
I know this doesn't really pertain to CM10.1 development, but I have a development question.

What controls when the notification light turns green when charging? How can I edit that?
[HTC Droid DNA] crpalmer:
[MENTION=220657]chad[/MENTION]0898

Oddly, after a reboot some (streaming) music will play in google music and some won't. They are consistent on which songs play and which don't. Once I play a song that does play, they all seem to play fine. I'm currently listening to one of the problematic albums on my bluetooth headphones with no problems right now.

Looks like they changed things upstream again though. They now (correctly) build media-caf instead of media (which means you don't want the hack in media). Unfortunately, this requires the video changes that were also in the m7 kernel commits. I pushed those up to my m7-spew branch (see my last post). I tried to pull the commits directly from caf (we have a lot of diffs with the m7 video code). I had to pull in a couple of extra commits for things that were missing.

I have no idea if this code works though. It looks like my cm build will finish but I'm out of time to work more on it.
[HTC Droid DNA] chad0989:
Sounds good. I'll build and try to take a look today.
[HTC Droid DNA] crpalmer:
Forgot to say I didn't cherry-pick this commit because I didn't want to blindly change the values:

http://review.cyanogenmod.org/#/c/44470/
[HTC Droid DNA] crpalmer:
I just sent merges requests for the kernel and device tree which I believe should be all you need to get things working again. I had some video problems so I disabled the "turbo mode" that was just added and the routing for the audio changed. Can you take a look and see if you find any problems?

Also, I still didn't include this commit:

commit 8b25d2442147d442ee69292bd596d828de2d1fdb

Author: Shobhit Pandey <cshopan@codeaurora.org>

Date: Fri Apr 12 12:49:28 2013 +0530

msm:board-8064: Correct ab/ib values of 1080p turbo vectors

This change corrects the ab/ib values of turbo vectors

intended for 1080p encoder.

CRs-Fixed: 473197

Change-Id: I172b241e7b8b7b2d8600647ac35af78ed928e052

Signed-off-by: Rajeshwar Kurapaty <rkurapat@codeaurora.org>

I did try including it but it didn't solve the problem I was having with youtube crashing the phone so instead I disabled the turbo mode and omitted the commit. Feel free to include it if you want to.
[HTC Droid DNA] chad0989:
Awesome. Low latency appears to work well. Tunnel is having issues though. Not sure if it has to do with routing or if we're missing something in the kernel. Hmm
[HTC Droid DNA] crpalmer:
Yeah, low latency is nice. Did you cherry pick the m7 fusion3 commit? If so, did you change all the 40s to 41?

Either way, what are you doing to see a problem?
[HTC Droid DNA] chad0989:
Yes, I pulled the m7 commit. I was seeing an issue trying to play compressed audio streams (i.e. google music).

I just looked through our devices. It looks like our tunnel device should be pcm38:

shell@android:/proc/asound/apq8064tablasnd/pcm38p # cat info

card: 0

device: 38

subdevice: 0

stream: PLAYBACK

id: COMPR (*)

name:

subname: subdevice #0

class: 0

subclass: 0

subdevices_count: 1

subdevices_avail: 1

I updated our config and it works well now.
[HTC Droid DNA] crpalmer:
I sent you a pull request that has all of this updated. There may be some others that are wrong as well. All devices 10 and above were shifted by the kernel changes.
[HTC Droid DNA] chad0989:
Ah. I didn't see that. Thanks.

Edit: I also go around to finally updating the voice recognition device to use the correct mic. Google Now should work much better now.

Edit2: Shouldn't our lowlatency device be at pcm11, 41 doesn't exist? We also have a device at 36 we probably could use and avoid the shift. Sticking with 11 will stay more in line with CAF though.
[HTC Droid DNA] crpalmer:
I bet I did something stupid in my kernel and created a mismatch because I'm 99% sure it was really working with it.

I can take a look tonight or you can just change it to be 11 if you haven't already done so.

Sorry about that!
[HTC Droid DNA] crpalmer:
I removed my 41 (had a left over commit from trying to merge the m7 cherry-picked commits before starting over with the original commits, oops!). I can't see any difference between having them set as 41 with the built-in kernel and 11 with either built-in or my kernel. I'll send you a pull request but I'm not sure what I'm seeing...
[HTC Droid DNA] chad0989:
With it set to 11 it uses the the device when low latency audio would be desired (changing ringer volume).

D/alsa_ucm( 211): Set mixer controls for Speaker enable 1

D/alsa_ucm( 211): acdb_id 15 cap 1 enable 1

D/alsa_ucm( 211): Set mixer controls for HiFi Lowlatency enable 1

D/alsa_ucm( 211): Setting mixer control: MI2S_RX Audio Mixer MultiMedia5, value: 1

D/ALSADevice( 211): close: handle 0x4010f018 h 0x0

D/ALSADevice( 211): open: handle 0x4010f018, format 0x2

D/ALSADevice( 211): Device value returned is hw:0,11

D/ALSADevice( 211): handle->format: 0x2

D/ALSADevice( 211): setHardwareParams: reqBuffSize 1024 channels 2 sampleRate 48000

D/ALSADevice( 211): setHardwareParams: buffer_size 4096, period_size 1024, period_cnt 4

Before it would enable the mixer but then fall back to the standard playback device:

D/alsa_ucm( 211): Set mixer controls for HiFi Lowlatency enable 1

D/alsa_ucm( 211): Setting mixer control: MI2S_RX Audio Mixer MultiMedia5, value: 1

D/ALSADevice( 211): switchDevice: mCurTxUCMDevivce None mCurRxDevDevice Speaker

D/alsa_ucm( 211): snd_use_case_set(): uc_mgr 0x400cb828 identifier _enamod value Play Music

D/alsa_ucm( 211): Set mixer controls for Play MusicSpeaker enable 1

D/alsa_ucm( 211): Setting mixer control: MI2S_RX Audio Mixer MultiMedia1, value: 1

D/ALSADevice( 211): close: handle 0x4165b618 h 0x0

D/ALSADevice( 211): open: handle 0x4165b618, format 0x2

D/ALSADevice( 211): Device value returned is hw:0,0

D/ALSADevice( 211): handle->format: 0x2

D/ALSADevice( 211): setHardwareParams: reqBuffSize 2048 channels 2 sampleRate 48000

D/ALSADevice( 211): setHardwareParams: buffer_size 16384, period_size 2048, period_cnt 8

Edit:

I also noticed it would enable the low latency mixer but then use the tunnel device during compressed audio playback. Not sure why it was doing that but it only uses the tunnel mixer/device now. I believe that is the desired behavior as I don't believe tunnel and low latency can mix.
[HTC Droid DNA] nsmal24:
http://www.droid-life.com/2013/06/2...ial-edition-which-is-the-google-play-edition/

For those who haven't seen this yet.
[HTC Droid DNA] kman79:
One "Google Play Edition" Source Code

http://www.htcdev.com/devcenter/downloads

I've been eagerly waiting for this release in hopes that it would help you guys with the BT issue. That's the only reason why I haven't tried the ROM, I use BT Audio everyday. Hope the kernel source code for the One helps development on the DNA
[HTC Droid DNA] chad0989:
I just got home from work so I haven't looked at anything but it looks like there has been some updated bluez source released for the one Google edition that hopefully will help to get BT 100%.
[HTC Droid DNA] .torrented:
How has the phone audio been coming along with low latency and the tunneling stuff?
[HTC Droid DNA] chad0989:
It works and is in the tree already
[HTC Droid DNA] djh816:
And FWIW: http://xdaforums.com/showthread.php?t=2341395
[HTC Droid DNA] chad0989:
Doesn't really help us in regards to CM unfortunately.
[HTC Droid DNA] .torrented:
Loving the new audio stuff man! Great work!

and chris cause i know you help too!
[HTC Droid DNA] crpalmer:
This is really late, but I was looking at something in the AOKP sources (this is different from the CM10.1 source!) last night and I saw this commit:

commit 0ac706e07f20f1acf18c3d2102967a49c9c16b24

Author: bmc08gt <bmc08gt.teamb00sted@gmail.com>

Date: Sun Apr 14 08:36:36 2013 +0200

Battery: Solid green when battery is full and introduce 4th stage

* Solid green when battery is full

* Introduce 4th step in colors which includes 69-99%

0-14: red

15-69: orange

70-99: yellow

100: solid green

Change-Id: I24af9bb012744ea15d411c2aa42afe9388f2a97e

Signed-off-by: bmc08gt <bmc08gt.teamb00sted@gmail.com>

which looks like maybe you want to add an overlay for

<integer name="config_notificationsBatteryAlmostARGB">0xFFECFF00</integer>

to a different colour?
[HTC Droid DNA] .torrented:
Awesome man I'll give that a shot and see what happens :)

Because that's when my battery light is turning green is at 69% when charging
[HTC Droid DNA] renzo.olivares:
Hey chad sent a pull request for device_htc_dlx and vendor_htc_dlx just a cleanup and put more inline with how cm has their devices, i've tested and everything works as should
[HTC Droid DNA] chad0989:
I'll test tonight.
[HTC Droid DNA] 123421342:
I think it should be green at 90%
[HTC Droid DNA] renzo.olivares:
sent a couple more with some m7 changes which they were reporting fixed audio in hangouts these i have not tested yet (did change the pcmplayback values for low latency but not sure if those are the correct ones i used 11) tho.....ill test if you dont beat me to it
[HTC Droid DNA] crpalmer:
11 should be correct.
[HTC Droid DNA] .torrented:
On rootbox its 69%
[HTC Droid DNA] crpalmer:
[MENTION=3124509]chad0989[/MENTION], are you still interested in seeing the kernel video code patched up to:

AU_LINUX_ANDROID_JB_2.5.04.02.02.040.353

Since you made the jb_2.5.1 commit, I've tried a few different ways to do this. I finally have something that is about 90% patched up for drivers/video/msm and about 90% working. Before I spend the time to try to figure out what I've broken and see if I am able to fix it, I want to see if you were still interested in having us head down the CAF path.

This looks to me to be quite a different path from the other alternative which would be to try to update to the m7 video drivers.

Thoughts?
[HTC Droid DNA] chad0989:
I think it would be in our best interest to get on that path if possible. That way we would ensure compatibility with future released binaries and CM since they are on that path.
[HTC Droid DNA] chad0989:
Going to pull and build Joelz commits now and give them a shot.
[HTC Droid DNA] chad0989:
Merged and fixed build
[HTC Droid DNA] crpalmer:
FYI, I have finished what I think needs to be done. I've done:

This completes patching the monarudo source for

drivers/video/msm

drivers/gpu/msm

drivers/gpu/ion

drivers/iommu

with the exception of

drivers/video/msm/external_common.c

drivers/video/msm/hdmi_msm.c

up to the CAF tag

AU_LINUX_ANDROID_JB_2.5.04.02.02.040.353

I didn't touch the hdmi source because I had no way to test it right now. Anything else I should have patched up while I was at it?
[HTC Droid DNA] chad0989:
Asesome. Maybe rotator also if its not up to date, but I believe it is. Can't wait to test it out. I'll give hdmi a shot if I can find my mhl adapter.
[HTC Droid DNA] crpalmer:
Rotator looks up to date with some new additions that looked like HTC additions that were worth keeping.

---------- Post added at 08:58 AM ---------- Previous post was at 07:59 AM ----------

I sent a pull request for you for this. FYI, I also sent you one yesterday for the device tree that seems to fix usb-otg support (works with exactly 1 cable + usbdrive, at least).

FYI, this adds a dependency between the kernel and the rest of the build because the mdp_overlay structure changed which breaks a critical ioctl for code that isn't build using the new kernel headers. After we finish merging this, people building ROMs based on this should absolutely do a clean build if you don't always do so anyway.
[HTC Droid DNA] crpalmer:
Sorry to be a nag, I'm obviously super excited about (hopefully) getting this to work... [MENTION=3124509]chad0989[/MENTION], did you by any chance you get any time to take a look at my changes?
[HTC Droid DNA] chad0989:
Built yesterday. Works great :good:. Just merged it.

I'll try to look at HDMI this week.
[HTC Droid DNA] crpalmer:
Cool, thanks!
[HTC Droid DNA] chad0989:
Got MHL somewhat working. It comes up and outputs fine etc but its real laggy.
[HTC Droid DNA] Zarboz:
Try forcing refresh rate at 60hz there was a patch for HTC one s kernel for this feature and for HTC one flar2s tree has it
[HTC Droid DNA] chad0989:
That's better but still laggy.
[HTC Droid DNA] Zarboz:
That was the extent of my idea lol
[HTC Droid DNA] crpalmer:
We still aren't sync'd on the hdmi code in drivers/video/msm because I was afraid to touch them. That may help if you want to try patching those files. If you don't have time, I ordered a MHL cable so that I could play with it later as well.
[HTC Droid DNA] crpalmer:
[MENTION=3124509]chad0989[/MENTION], I just sent several pull requests for the kernel. This one:

https://github.com/CM10DNA/android_kernel_htc_dlx/pull/23

is a good one to look at first. The rest are not that important.
[HTC Droid DNA] chad0989:
I'll try to take a look today if I get a chance.
[HTC Droid DNA] crpalmer:
[MENTION=3124509]chad0989[/MENTION], in case you didn't see this:

http://xdaforums.com/showpost.php?p=43680794&postcount=165

It's a video showing the screen flicker that a few people have reported. I did a little searching and the fireball sounds like it has a similar problem (but not solution). They include this warning:

If your display flickers noticeably after an hour or so of usage, discontinue use of these builds. Builds 20130616 and newer use linux kernel 3.4, which is still very beta for this phone. The flickering may persist for a few hours on another ROM, but it should eventually subside. I am not responsible for damaged devices as a result of running these builds. Stick with a stock-based ROM if you're uncomfortable with this.

which poking into the thread seems to be because they suspect that they are driving the panel with an incorrect voltage.

Does any of that give you any idea what the problem could be?
[HTC Droid DNA] chad0989:
Hmm. That's interesting. Honestly I have no idea what could be causing it. Incorrect voltage does make sense as a possible cause but I don't recall changing anything that would have changed the voltage. Maybe a calculation was changed in there somewhere and values weren't updated in our panel driver. I'll try to look into it some more this week.
[HTC Droid DNA] crpalmer:
I saw this problem for a day when the jb_2.5.1 changes were going through and then it stopped happening for me. Looking at the commits around there, this one looks like it has a lot of potential to be doing something wrong with regulators, voltages, etc:

commit fd246ecb21b32c4edefb976f0309de1bfb025c05

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

Date: Sat Jun 1 22:51:14 2013 -0400

Updates from m7

Change-Id: Id882322defe64d8017b2983efa53ef3ba639195c

Do you remember how you pulled that set of changes and how confident that you were that they were right?
[HTC Droid DNA] crpalmer:
[MENTION=3124509]chad0989[/MENTION], I now have a "new" DNA (warranty replacement) which has been showing this flickering like crazy. It does look to me like we are doing something very wrong with the hardware. The video really didn't do that justice.

I started looking through that commit last night and it made my brain hurt to try to figure out where we could be driving things at incorrect voltages / frequencies / etc. Rather than think too hard about it, I approached the problem with a hammer. I reverted that commit and then got it compiling and booting.

Given that this has been reported as an intermittent problem, it's hard to make any conclusions. However, I have been using this today (about 6 hours) and it is seeming to be much happier and I haven't noticed anything that is broken. I pushed up the commits needed in case you wanted to look at it and/or play with it as well:

https://github.com/crpalmer/android_kernel_htc_dlx/commits/tmp
[HTC Droid DNA] crpalmer:
After about 12 hours of non-flickering, it started flickering like crazy again. This was when I was outside, using the phone in full sunlight in 95 degree weather. It's possible that the flickering is worse in high heat? Right now, another 2 hours after it started, it has only a slight flicker.

I'm not sure what to make of that.
[HTC Droid DNA] .torrented:
Could it be just a bad batch of devices? Maybe it's not software related. My HTC Evo 4G LTE had screen flicker before I even rooted it. Especially on gray screens it was the most noticeable. Like the whole screen would flicker bad. Drove me insane.
[HTC Droid DNA] orangechoochoo:
I have the flickering too, I noticed it occurs when the phone is warm. The flickering started around June when some major changes in CM occurred.
[HTC Droid DNA] renzo.olivares:
might be on the m7 kernel im using the same voltages and my screen is just fine
[HTC Droid DNA] amit_sen:
I also experienced the exact same thing earlier.

Screen flickering only ocurrs with light background and when u r outdoors. Its intermittent.

DNA | ⓣⓐⓟⓐⓣⓐⓛⓚ | TF300T
[HTC Droid DNA] brennam7:
This may sound stupid, but what about the light sensor? I'm in a dark bar right now and its barely flickering. Its been pretty bad all day in lighter conditions. Not using auto-brightness btw
[HTC Droid DNA] crpalmer:
Actually, it looks like you are using the HTC version of acpuclock and the CM kernel is using the M7 version of acpuclock (we have acpuclock-8064 vs. acpuclock-8960 in the HTC stock and your kernel).

---------- Post added at 05:33 AM ---------- Previous post was at 05:29 AM ----------

For me, the flickering is most noticeable with a grey solid background and on maximum brightness. To test for flickering, I am turning off auto-brightness, setting the brightness to max and the going to http://d-h.st and scrolling down to the bottom of the page and zooming in until I get a solid grey on the screen.
[HTC Droid DNA] renzo.olivares:
https://github.com/Joelz9614/androi...mmit/577fc46a91898a0526ded927df2fb29b54d6801e

i should be using apq8064 unless i missed a change
[HTC Droid DNA] crpalmer:
No, you're right. I was looking at the wrong branch of your git repo. The flickering does seem to be device dependent too though. I only saw it a little bit on my old phone but my new phone flickered within 5 minutes of installing CM on it and just kept flickering.
[HTC Droid DNA] danielhall2689:
I have not once seen it on my phone. So it definitely sounds like that
[HTC Droid DNA] coachcrey:
I have no flickering at all.
[HTC Droid DNA] chad0989:
I wonder if its a newer hardware revision that needs to be accounted for somewhere.
[HTC Droid DNA] coachcrey:
It sounds like it might be my DNA is one of the original ones.
[HTC Droid DNA] crpalmer:
That's an interesting thought. Can you post or PM me a dmesg output that includes all of the initial boot messages? I'll take a look and see if there are any obvious differences.
[HTC Droid DNA] danielhall2689:
I think you are on to something. I bought my dna in December so I guess I would have the "launch model" and have yet to see any flickering.
[HTC Droid DNA] chad0989:
Sure thing when I get home tonight.

Another thought I just had is that the mdp clock used to be pegged at 200000000 and since the update we've allowed it to scale. Maybe they had it locked for a reason.
[HTC Droid DNA] pio_masaki:
I'm also rolling a launch DNA, had it since way before facepalm and so far no flickering, so any additional info for comparison of launch vs newer would help I'm sure. 2 devices that don't have it and are launch devices will help in determining differences with them vs others I would imagine.

Just lemme know.
[HTC Droid DNA] times_infinity:
Intervigilium pushed a change on CM gerrit for the M7 kernel that increased the display bandwidth. Maybe that could help? Or ifdef to the old values for DNA?
[HTC Droid DNA] chad0989:
Not related. We already went through bandwidth changes awhile ago.
[HTC Droid DNA] crpalmer:
I don't know a lot about the hardware side of the kernel, but it seems like we really must be driving something at the wrong voltage or equivalently bad.

It started flickering like crazy this afternoon and has continued to flicker in recovery and has been flickering for the last 30 mins on a sense Rom.

Assuming it is the same issue that the fireball port is seeing, I expect the flickering to stop in a couple of hours running a stock sense Rom.

For it to continue in other kernels sounds rather bad to me.
[HTC Droid DNA] Argumentation:
Yeah, got mine on launch day and I've never seen flickering, so make of that what you will.
[HTC Droid DNA] paulhoop:
DNA is a March 2013 acquisition.

No flickering.

Rev 0004
[HTC Droid DNA] orangechoochoo:
Bought my DNA the day it came out and I have the flickering.
[HTC Droid DNA] Milly7:
In following chad's and crpalmer's line of reasoning in terms of hardware revisions, I think it would be more helpful if people did not just merely state when you bought the phone, but rather state what is actually listed under Hardware info in phone, such as hardware version 0003, etc.
[HTC Droid DNA] TheDanimal:
I'm revision 0004 with no flickering
[HTC Droid DNA] 123421342:
I would wait until chad or palmer says we should just so we don't clog the thread. Its a good idea though and if they want it people should also state the ROM and kernel they are using.
[HTC Droid DNA] orangechoochoo:
That won't help. All I know is crpalmer and Chad said it isperfectly safe and my warranty won't be void if I flash their creations. Now look at my situation: my phone has incredible speed and battery life. I never should have trusted them :highfive:
[HTC Droid DNA] chad0989:
[MENTION=3857343]crpalmer[/MENTION]

Here you go.