yashsingh1/xdaforums huggingface dataset:
[HTC Droid DNA] crpalmer:
Not very different looking. You are binned faster than I am, I used moonshine and I have a different hboot

board_bootloader_setup: 1.33.0001

board_bootloader_setup: SHIP BUILD

vs.

board_bootloader_setup: 1.33.4444

board_bootloader_setup: default ENG BUILD

The biggest different I see is the touchscreen firmware version(?):

[TP] syn_get_version: packrat_number: 1195020

vs

[TP] syn_get_version: packrat_number: 1293981

My version (the bigger one) is in the code as

#define SYNAPTICS_FW_NOCAL_PACKRAT 1293981

and causes some different initialization to occur and uses slightly different platform data. The m7 kernel has fairly different platform data for these structures, some of which was updated from the Google Edition code but seems like a bit of a stretch to me to be causing such crazy flickering.

Any thoughts?
[HTC Droid DNA] chad0989:
Browsing through the display code for the DNA and similar devices, I noticed that the One in particular has an updated display driver that looks to be more universal for multiple 1080p displays they may use. For the particular Sharp display we use I noticed a few values have been changed, namely the panel clock and some back and front porch values. The same values are used in the butterfly kernel.

I don't really know exactly how the panels and buses they connect to operate and what values do what, but I believe the clock and porch values have something to do with how the panel refreshes / scans. I do recall at one point when I was working on the OG incredible a couple years ago, updated FB code changed a calculation that used the front porch and back porch values. We had all sorts of display issues until the values were updated.

It might be a long shot but I tried the different values awhile ago and it didn't make a difference to me (but I don't have the flickering), but maybe it will to someone else.

I do agree though that flickering that is persisting booting into recovery etc. is definitely real bad.

I also did split some of the display controller code from the panel code awhile ago. It was more to isolate some stuff when I was originally trying to update video/msm. I vote we should probably ditch that split and go back to either our original monarudo-display or use the updated version from the m7. It's possible I screwed something up in the split and a regulator is being enabled/disabled when it shouldn't or somehow getting a wrong voltage.
[HTC Droid DNA] kaliblazin707:
Hdw rev xx3

Can I get you some sort of log information?

I suffer from the flicker
[HTC Droid DNA] crpalmer:
Can you reboot and get a dmesg after boot (it should start with a line that says it is booting Linux at 0 ms)?
[HTC Droid DNA] gdog1977:
Hey guys, just wanted to say that this rom is awesome. One issue though, I use this phone for work and am constantly switching between speaker phone and the handset. If I talk quickly after switching from speaker, the person on the other end complains that I sound garbled or sometime they say I sound far away. About a second later, everything is fine and the conversation is clear. Any ideas? BTW, I'm running crpalmers kernel. Was planning on flashing the newest nightly to refresh the kernel to stock, but it seems CMUpdater is borked at the this time. Haven't ran the stock kernel for any amount of time. Thanks guys.
[HTC Droid DNA] kyleco:
I've attached mine. I have had no screen flickering issues and my firmware version matches chad's. I think you guys are on the right track with this.
[HTC Droid DNA] crpalmer:
[MENTION=3124509]chad0989[/MENTION], I feel like I've done everything possible to the display code without any real luck at stopping the flickering.

I tried the panel setup from the M7 but rolled it back because it changes the panel's frequency which kind of freaked me out.

Otherwise, I rearranged out lcd_on code to match the order and timing from the M7 (the GPIOs look slightly different, so I didn't touch them). I changed the lcd_on / display_on to match their code which lets me revert my changes to msm_fb.c to turn the display back on. Added some writeback device configuration that we don't have. Updated msm_xo.c which was using the old clock apis (which generated a warning after a enabled more clock warnings), fixed an incorrect change to the 2d clocks.

None of this seems to matter.

One thing I did notice though... This morning, my screen was completely flicker free when I got up. I took the phone off the charger and used it for a couple of minutes and then shut the screen off for an hour or so. When I turned it back on, it was starting to flicker. Is it possible that the wireless driver is doing something crazy with a clock or gpio?

The reason I'm wondering about the wifi is that it most likely would have shut off during the night and then would have been back on when I was using the phone for a couple of minutes and then continue to be on for awhile after that. Aka, the total display on time was very small but the wifi on time would have been higher.
[HTC Droid DNA] crpalmer:
So, [MENTION=3124509]chad0989[/MENTION], how's your understanding of clocks, fabric, etc? Mine is, ummm, low.

I had [MENTION=3553660]AskieR[/MENTION] run a shell command that printed ,for each clock in /sys/kernel/debug/clk, the current rate (first entry after the clock name) and all the valid rates. There are some scary (to me) looking differences with what I assume are fabric clocks (the diff is - == me on sense and + == him on CM 10.1):

@@ -9,7 +9,7 @@

[MENTION=1879310]@@@[/MENTION] afab_a_clk [MENTION=1065870 [MENTION=1879310]@@@[/MENTION][/MENTION]

-266667000

+533000000

[MENTION=1879310]@@@[/MENTION] afab_acpu_a_clk [MENTION=1065870 [MENTION=1879310]@@@[/MENTION][/MENTION]

@@ -17,11 +17,11 @@

[MENTION=1879310]@@@[/MENTION] afab_clk [MENTION=1065870 [MENTION=1879310]@@@[/MENTION][/MENTION]

-266667000

+533000000

[MENTION=1879310]@@@[/MENTION] afab_msmbus_a_clk [MENTION=1065870 [MENTION=1879310]@@@[/MENTION][/MENTION]

-133000000

+533000000

[MENTION=1879310]@@@[/MENTION] dfab_msmbus_clk [MENTION=1065870 [MENTION=1879310]@@@[/MENTION][/MENTION]

-32000000

+64000000

And, what I'm hoping will be our flickering problem:

[MENTION=1879310]@@@[/MENTION] dsi1_esc_clk [MENTION=1065870 [MENTION=1879310]@@@[/MENTION][/MENTION]

-2

+6

1

2

3

I'll dig into the dsi1_esc_clk because that is going to be something I can figure out. I am curious to know what you make of the other clocks and whether my gut reaction is right that it looks like something else is messed up...

---------- Post added at 08:04 PM ---------- Previous post was at 07:37 PM ----------

The dsi1_esc_clk was easy. In a very early commit:

commit 6add779f32e77ebe1d40fc3725f7f86d4a8eff65

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

Date: Sun Mar 10 13:03:31 2013 -0400

Bulk update all fb and gpu drivers from mako + Fixup for monarudo.

Monarudo display still needs to be worked further but this gets

a working fb and initial display.

we deleted HTC's horrendous hack:

#ifdef CONFIG_MSM_ALT_DSI_ESCAPE_CLOCK

esc_byte_ratio = pinfo->mipi.esc_byte_ratio;

#else

esc_byte_ratio = 2;

#endif

and replaced it with the more sensible esc_byte_ratio = pinfo->mipi_esc_byte_ratio;

Unfortunately, this doesn't seem to fix the flickering problem for me. Sigh.
[HTC Droid DNA] chad0989:
Unfortunately, my knowledge is limited at best also.

I checked my clocks, all of them seem to bounce around depending on the phone state. The only ones that didn't change for me were dfab_msmbus_clk which seems pegged at 64000000 and dsi1_esc_clk which you already noted.
[HTC Droid DNA] crpalmer:
When I check the other clocks, you're right that they do fluctuate but they are fluctuating consistently higher.

If I change the dfab_msmbus_clk (you can just echo to the "rate" file!) the numbers seem more in line with what I had from the Sense ROM. I'm not sure what to make of it because the only place I see setting that clock is setting it to 64MHz (in both our kernel and the stock HTC kernel).

I collected those clock numbers from newtoroot's Sense 5 ROM. Maybe something is different in there?

Either way, I just sent a couple of pull requests.
[HTC Droid DNA] crpalmer:
[MENTION=3124509]chad0989[/MENTION], I'm gradually getting more and more at a loss as to what could be causing the flickering that I'm seeing. This new phone does seem to be VERY finicky (it rebooted when I *over* clocked more than a couple of steps!).

To test my guess that it was wifi related, I disabled wifi when I went to bed and left it off overnight. The next morning the flickering was basically gone but it started to flicker later in the day (before I enabled wif)i.

I tried setting the max_clk to 200000000 but that still let it scale. I then noticed that it seemed to be at 177.... most of the time on my phone. I hacked the code to make the max 2000000000 and then to always select the max speed but that didn't stop the flickering. It actually looks like the stock software does actually scale this clock (I saw the same 1777l.... on stock, the table that made us think it didn't scale was actually used in the stock kernel).

I have made changes which I hoped would make things better and then seen the flicker gradually diminish before it resurfaced in full force. There doesn't seem to be any obvious correlation between it being on and flickering increasing.

I have tried overvolting across the board at +25000 in case it was a voltage issue, but that seems to make no difference.

I've tried to find places where the HTC code was using clk_enable (before the change to split clk_prepare from clk_enable). I might have found one battery improvement there,but nothing that helps my flicker. I tried to look at diffs with the HTC code and with the CAF code and I am not seeing a lot that looks very promising.

The only thing that is odd in my logs is:

<4>[12660.070683] c1 18792 WARNING: at arch/arm/mach-msm/clock-local.c:313 rcg_clk_enable+0x84/0xb0()

<6>[12660.070713] c1 18792 dsi1_byte_clk status stuck at 'off'

which I saw on my old phone and wasn't causing any problem. Do you also have this wanring in your dmesg?

What i believe that I can observe from the phone is:

* when it spends a long time in deep sleep, the flicker goes down

* it can be used with the screen on without flickering much

* it can start to flicker a lot when the screen has been mostly off

Any suggestion on what I could be looking into? I don't really have any idea what to try next...
[HTC Droid DNA] duffman452001:
I'm not a coder but I am a good googler. I'm also not running this rom right now but I am watching the development of it. Does disabling hardware overlay in the dev settings stop the shimmer? I read somewhere else its an issue with 4.2.x.
[HTC Droid DNA] chad0989:
I get that warning also. I always have. I wonder how the panel backlight is controlled. I assume its an LED and is controlled similarly to the flash and notification light. If its over/under volted or has the wrong PWM frequency it could cause a flicker. Maybe a conflict with our lights HAL and our backlight control in the kernel.

That actually would make sense if the ROM is trying to adjust the backlight but the kernel also is attempting to adjust it. But then I would think that it would affect all devices.

This is all just speculation though. From the video I can't really tell if its an LED flicker or something rendered on the display.
[HTC Droid DNA] ML417:
Why not start a thread dedicated to looking into that problem? I'm sure most of the people experiencing that flicker would be happy to help out if you gave them enough instructions on how to properly document and test things out. Maybe someone would come up with something that you totally overlooked. Either way many heads are better then one, and I don't think everyone with that problem is looking specifically at this thread.
[HTC Droid DNA] brennam7:
just my 2¢…

I think its something being rendered on the display. because when I get the flickering on the home screen, I can bring up the app drawer and the flicker immediately stops. Also, if the flicker is very light, and I do a quick reply to a text, it immediately gets worse
[HTC Droid DNA] crpalmer:
I find that certain colours are much worse for showing the flicker. For example, turn up the brightness to 100% and then open d.h-st in your broken and zoom in to fill the screen with the background grey. This is one of the worst for showing the flickering for my phone.

When I open the app drawer it is all black background and doesn't flicker. I don't believe it is different rendering, just different colours.

Can you play with it a bit and see if it's really the colour changes, not different layers on the screen that affect the amount of flicker.

Given that the flickering continues in recovery and also continues in recovery after powering the phone off completely, I'm dubious that it is something rendered in the display (but who knows, I could be wrong).

---------- Post added at 02:04 PM ---------- Previous post was at 02:03 PM ----------

That is an older problem. Disabling the hardware overlay doesn't change the flickering.
[HTC Droid DNA] crpalmer:
Glad to hear that you have the warning as well. I had that on my old phone and therefore i was ignoring it. I would sure have felt stupid if that was the problem staring me in the face!

I assume that the panel backlight is a LED controlled by PWM. I believe that it is controlled by a dedicated chip attached on the i2c bus and that our chip is different from the one in the M7.

The lights HAL looks pretty simple (hardware/qcom/display-caf/liblight) and just writes to files in /sys. The backlight control goes to msm_fb.c which looks like it doesn't have any issues.

I just sent another pull request. I moved closer to the m7 code, got rid of the fact that we still required a display_on function and by doing so got the order of display_on / lcd_on correct. It also includes adding a sleep after enabling the backlight gpio. In addition to the display changes, there is a change to the oscillator code that may be irrelevant or may help improve battery life (it was being left on while in deep sleep).

My flickering has been much better tonight after making these changes this morning, but it still exists. This probably means that the flickering is really unchanged but I think that these are all good changes whether or not they fix my flickering problem. If somehow this fixes the flickering problem, it will be either the sleep after changing the gpio and/or the display_on / lcd_on ordering.
[HTC Droid DNA] crpalmer:
[MENTION=3082717]Flyhalf205[/MENTION], are you actively working on getting 10.2 to build? I see that you setup the branches and that you had merged in a change to the manifests, but I'm not seeing anything else.

This morning, I had it building down to the recovery fstab being in an invalid format (just after building system.img). I hope we're not doing too much duplicate work?
[HTC Droid DNA] Flyhalf205:
Yes. Not much effort I am putting into it though. Really trying to get the Rezound building.

An example of the recovery.fstab @ http://review.cyanogenmod.org/#/c/46077/

I'll be working on this a lot in the next couple of hours.
[HTC Droid DNA] crpalmer:
It booted, but the keyboard force closes which makes it a pretty useless smart phone. Especially when you have a lock screen password!

I'll send a couple of pull requests.
[HTC Droid DNA] Flyhalf205:
Awesome. They've been merged. Thanks for saving me so much time :)

EDIT: btw, did you clean flash?
[HTC Droid DNA] crpalmer:
I tried a dirty flash first, which left me screwed because of the lock-screen password. I then tried a clean flash but I live in a really bad cell area and not being able to enter my wifi password was too painful, so I restored 10.1 and disabled the password and I'm running that dirty flash now.

And, I'll have to say, I'm not sure how much time I saved you in the grand scheme of things.

Bad:

* It locked up when I tried to make a call.

* android.process.media is crashing every now and again.

* It's doing some crazy vibrating, but that might be the IT / security software that my company requires be installed that I had to disable to disable the password *****ing.

* Google Music causes the phone to lock up when I play to a bluetooth headset. It didn't crash when I rebooted and the bluetooth was connected when I hit play.

Good:

* Google Music is streaming music to the speaker and wired headset.

I suspect that at least some of this is based on the fact that I had to dirty flash because of the keyboard issue. I think I would try wiping first and working from that.
[HTC Droid DNA] chad0989:
Most of the platform specific changes haven't been merged upstream yet either. That's great that it boots with minimal modification though. This way it'll be much easier to keep up with changes at they come along. :good:
[HTC Droid DNA] crpalmer:
Agreed. Basically all the modifications are the same changes that all devices will need to make. Nothing specific to us.
[HTC Droid DNA] crpalmer:
The M7 kernel had a big set of video changes. I just sent a merge request with those changes (for the cm-10.2 branch).

The M7 kernel also merged these into the 10.1 branch, so I'm not sure if you want to do the same? Or if you even care to keep supporting 10.1?

This morning's build of CM 10.2 with these gapps:

http://d-h.st/aPi

is actually running very well for me (dirty flash from 10.1). The big things that I'm seeing are that su and the camera aren't working. I think that there are still lots of little issues (I saw a lot of errors in the logcat but didn't look at them) but otherwise much closer than I was expecting.
[HTC Droid DNA] Flyhalf205:
Just looking at the commit. Looks like mtp is configure to be working now?
[HTC Droid DNA] chad0989:
No. Its still not working. I started working on it but haven't finished. Your welcome to pick up with it there though.
[HTC Droid DNA] 123421342:
Do you have any advice on where to get started with any of the current tasks? I would love to help out.
[HTC Droid DNA] Flyhalf205:
Start on Wifi or BT?
[HTC Droid DNA] renzo.olivares:
idk if itll be this easy but for camera someone try camera.msm8960.so libcamera* libmmcamera* mm-qcamera* v4l20qcamera-app awb_camera lsc_camera libbeautychat.so liboemcamera.so probably not the best to use so many prop files...but that might work
[HTC Droid DNA] 123421342:
How exactly do I do that? Or generally doesnt need exact instructions.
[HTC Droid DNA] Flyhalf205:
Got MTP to work. But none of my drivers install for it. I'll upload what i have done. Working on OTG now
[HTC Droid DNA] Bigandrewgold:
You have to figure out what's causing it to not work then attempt to fix it.
[HTC Droid DNA] 123421342:
Thanks :). Im just going to dive right into it.
[HTC Droid DNA] chad0989:
May need to add vendor and product ids to the init.dlx.usb.rc so that the driver will recognize it.
[HTC Droid DNA] 123421342:
Looks like that code starts at line 120 of that file? The vendor id for HTC is 0bb4 but I couldnt find the DNA with a quick google search. Ill try to look into it tomorrow.
[HTC Droid DNA] Flyhalf205:
Down on Line 251 and 252. They have them commented out for mtp and right below for usb also

EDIT: On the stock it's on those lines. looks easy to pull over. Testing now
[HTC Droid DNA] 123421342:
Yeah but there are no vendor ids present there? Wouldnt it not show up if there are incorrect ids?
[HTC Droid DNA] Flyhalf205:
I just modified that post. I was looking at the stock dlx usb init.
[HTC Droid DNA] 123421342:
Gotcha. Where is the one you were talking about found?
[HTC Droid DNA] chad0989:
Any luck? Hopefully I'll be able to work on some stuff tonight.
[HTC Droid DNA] EmericanX:
I can post the vendor I'd when I get off of work. But it's easy to acquire. Anyone running linux can enter "lsusb" via a terminal window.. the one labeled HTC is the info you're looking for. Going off of memory the first number is the manufacturer id the second is the device id...
[HTC Droid DNA] Flyhalf205:
Nope. Flashed over to a sense Rom and still couldn't get MTP to work. Could just be on my end until someone else tries.
[HTC Droid DNA] 123421342:
Try using these ids 0dff/0ebd they were pulled from a dna using mtp on linux. vendor id looks good.
[HTC Droid DNA] chad0989:
If you can, push your changes to a new branch and ill give it a shot later.
[HTC Droid DNA] chad0989:
I'll most likely focus on 10.2 from here on out with the exception of build issues etc with 10.1 that need to be remedied. That is when things finally settle down and I have some time. I haven't gotten to contribute much in the last month or so with both starting a new job and getting married. Things are starting to calm down now though so I should be able to get back into it.
[HTC Droid DNA] Gorilla*:
Nice chad, will their be a new thread for nightly 10.2 builds? or will we use the same thread as the 10.1?
[HTC Droid DNA] chad0989:
I don't post builds. That's up to those who do. There will be a dev thread.
[HTC Droid DNA] orangechoochoo:
Congratulations on the new job and marriage!
[HTC Droid DNA] .torrented:
As of right now AFAIK Google patched the way root used to work and chainfire has a semi-working method to getting root access (something to do with a proxy)

Edit* Looks like its been fixed https://plus.google.com/110558071969009568835/posts/4RRRUedDssF
[HTC Droid DNA] renzo.olivares:
hey chad question couldn't find it when searching the thread but what was the issue with using the gps hal the m7 is using in their device tree?
[HTC Droid DNA] Flyhalf205:
In the main branch cm-10.1. Caught it up to yours. Made the fixes. I do get a android.process.media FC when MTP is activated.

I'm stuck in Roaming still. :p

https://github.com/CM10DNA/android_device_htc_dlx/tree/cm-10.1

Also tried to adb install an .apk. Had some time of internal issue error.
[HTC Droid DNA] chad0989:
That's no good. Might have to take it to vzw. Try RUUing to stock?
[HTC Droid DNA] Flyhalf205:
RUU back to stock. Still in roaming. I did a factory reset in HBOOT(How to fix Rezound 4G issues). Now it can't even read the sdcard.

I have no insurance. Taking it to VZW for a new sim thursday. Upgrade is in 5 months. But i'll be buying retail to keep unlimited.

OTG is all configured correctly I am sure of. But doesn't work. MTP drivers won't install. Probably should worry about those last. Important is Audio and camera. I might look into BT/Wifi tonight.
[HTC Droid DNA] EmericanX:
Is your imei still in tact via system settings?

Another idea just incase it's radio related is possibly flash the radio upgrade zip I thought I see floating around..
[HTC Droid DNA] chad0989:
MTP and storage are being messed up by the usbdisk stuff. I removed that and it fixes MTP and storage. I'll push the fix now.

I also did pull the CAF usb stack into the kernel before I figured out the issue. Its not needed, but it works with the 10.1 format init.usb.rc. Not sure if we should go with that or stick with HTCs implementation.
[HTC Droid DNA] 123421342:
Good job! I think it makes sense to stay away from the HTC implementation unless it breaks something. I know drew used an HTC implementation for WiFi which I will look into.

---------- Post added at 11:25 PM ---------- Previous post was at 11:22 PM ----------

What happened? Did flashing this break something? Is there a way to prevent this? Doing factory reset in hboot is bugged and ruins the sdcard partition. You will have to repartition it I think
[HTC Droid DNA] crpalmer:
In general, I'm unimpressed with some of HTC's kernel work so I would vote for replacing it with the CAF version.

For the USB stack, we might be making the wake lock problems either a lot better or a lot worse. If you decide not to go with it, can you push that commit up in a new branch? I would like to play with it.