yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Original Android Development] undercover:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

You are a star. Again, this is just pure curiosity, so I really appreciate you doing that for me.

BTW, long overdue beers on the way (sorry, won't be much, but as an advert says "every little helps", I hope) :beer::beer::beer::beer::beer::beer::beer:

Gotta send some rascarlo way too.
[Nexus 4 Original Android Development] gianton:
That's great! :good:

Can you share this init.d script file?
[Nexus 4 Original Android Development] Harsh:
sure I will post init.d files for Stock google preset and for LG Preset both. And than in there you can edit just amp0 and amp1 values and put it in your device :D...

But all this when I upload new build ;)
[Nexus 4 Original Android Development] ctfrommn:
You're the man Harsh.....glad you and Motley were able to successfully collaborate. It's enjoyable getting a little insight into the different approaches to a common issue and how different devs look at things. Cant wait for the script....would love to be done with kernel apps. I love the idea of flash and forget.
[Nexus 4 Original Android Development] gianton:
You rock, XDA rules!!! :good:

Glad to see devs collaborating for us end users!

Appreciate your hard work guys. :good:
[Nexus 4 Original Android Development] _motley:
Yes, this definitely is a productive conversation. I'm sure many have learned from it. However, just to make sure you understand. By doing it your way, you are not actually improving faux's checksum. You are deactivating it and ignoring the checksum when it is sent from his application. Also, by just counting up to 9, the checksum isn't really a checksum anymore. It has nothing to do with the value passed by the script or application. I think it is better to keep it as a true checksum because it makes the user editing the script pause and go back over the values again perhaps finding a mistake they made. Plus, it will keep users from implementing that don't understand how it works. This was faux's original intent and I agree with it. One of your first instincts, as is mine, when you criticized my implementation was safety and the dangers of users being able to do this. But now you are taking some the original built-in safety away:(

Yes, your version above at first glance makes it seem more simple and elegant in your mind, but aren't you defeating the purpose of it's original intent? Either way we do it, my way or your way with my checks in place, it has the same effect to the kernel as we load the values into the internal char array. If you open fauxclock it displays the values which were set by the init.d script. That's the way it already works in my implementation. My implementation also shows you the checksum of the already valid stored gamma array, making it easy to tune in an application and then spit out the results so you don't have the calculate the checksum.

Just some things for you to think about. This is why I chose not to implement in such a way as you have posted above.
[Nexus 4 Original Android Development] undercover:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

I have no clue what you two are on about, but keep going :D
[Nexus 4 Original Android Development] gianton:
OP has malware, that's what chrome gives me.
[Nexus 4 Original Android Development] undercover:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Don't worry about it. It happens on xda now and again. I guess some links from ads.
[Nexus 4 Original Android Development] trueblueram:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

I think it has something to do with the kernel:D
[Nexus 4 Original Android Development] gianton:
Yes you're right, thanks.
[Nexus 4 Original Android Development] Harsh:
static bool calc_checksum_generic(unsigned int intArr[]) {
int i = 0;
unsigned int chksum = 0;

for (i=1; i<10; i++)
chksum += intArr[i];

if (chksum == intArr[0]) {
return true;
} else {
pr_info("expecting %d, got %d instead!", chksum, intArr[0]);
return false;
}
}

static ssize_t kgamma_red_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
unsigned int kgamma[10];
int i;

sscanf(buf, "%d %d %d %d %d %d %d %d %d %d",
&kgamma[0], &kgamma[1], &kgamma[2], &kgamma[3],
&kgamma[4], &kgamma[5], &kgamma[6], &kgamma[7],
&kgamma[8], &kgamma[9]);

if (calc_checksum_generic(kgamma)) {
kgamma[0] = 0xd0;
for (i=0; i<10; i++) {
pr_info("kgamma_r_p [%d] => %d \n", i, kgamma[i]);
faux123_power_on_set_1[5].payload[i] = (char)kgamma[i];
}

kgamma[0] = 0xd1;
for (i=0; i<10; i++) {
pr_info("kgamma_r_n [%d] => %d \n", i, kgamma[i]);
faux123_power_on_set_1[6].payload[i] = (char)kgamma[i];
}
}
return count;
}

static ssize_t kgamma_red_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
unsigned int kgamma[10];
int i;
unsigned int check_sum =0;

for (i=1; i<10; i++) {
kgamma[i] = (unsigned int)faux123_power_on_set_1[5].payload[i];
check_sum += kgamma[i];
}

kgamma[0] = check_sum;

return sprintf(buf, "%d %d %d %d %d %d %d %d %d %d",
kgamma[0], kgamma[1], kgamma[2], kgamma[3],
kgamma[4], kgamma[5], kgamma[6], kgamma[7],
kgamma[8], kgamma[9]);
}

What this checksum does it in here is, it takes all 0 to 9 kgamma values and pass it to checksum. Right?

Than it compares total sum of value 1 to 9 with kgamma0, right?

What happens if user input values like

ehco "169 9 8 7 6 5 4 80 48 2" >
/sys/devices/platform/mipi_lgit.1537/kgamma_red

, it would take those values as correct values or not?

As we are giving checksum manually and entering values also manually, there is no point of having correct value checking. Because users are entering first value using calculator addition of other 9 values. So by this, checksum will always be true if all values are lower than 31 and USER was able to use calculator correctly. its nothing depending on wrong values anymore when we give users very dangerous stuff to play with.

Let me know if I am wrong in here?

And as per my understanding both checksum if used by normal users is dangerous equivalent. Faux implemented checksum so that users cant use sysfs interface to mess with, thats all.

Maybe my name is like that, lol :D

There are no files or special direct download links in OP. So it cant be, google got a mistake.
[Nexus 4 Original Android Development] Armin_van_buuren:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

I love this low version :D:D

Enviado desde mi Nexus 4 usando Tapatalk 2
[Nexus 4 Original Android Development] zevim2005:
Wich theme is this on your ROM?and wich kernel setting are you using?

*By the way im going to see you on tomorrowland:silly:
[Nexus 4 Original Android Development] Armin_van_buuren:
The theme is this Vicino artwork:

http://xdaforums.com/showthread.php?t=2116198

The kernel configuration is the default leading is Ondemand and ROW.

Moreover, I wish I could go see that meeting the great Armin but being in Spain grabs me a little far :laugh::laugh:
[Nexus 4 Original Android Development] zevim2005:
Thanks men,you live in Spain who need tomorrowland when you have ibiza!!!;)
[Nexus 4 Original Android Development] takethebox:
Anyone running this with XenonHD Stable 3.0? Experiences? Either the Low or Normal.
[Nexus 4 Original Android Development] Armin_van_buuren:
Sorry, I've been with this Codefirex and Harsh is a wonderful thing.
[Nexus 4 Original Android Development] takethebox:
Just installed the low version. So far so good on XenonHD 3.0 Stable. Very smooth.
[Nexus 4 Original Android Development] undercover:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Initial report on stock kernel with custom voltage. At - 125mV from stock (same as what I ran with - 100mV default harsh) temps are identical, if not by 1 degree cooler. Speed wise not faster than Harsh,about the same (good, that means Harsh is as fast as stock). Colours suck big time though. Will report further after full day of use tomorrow.
[Nexus 4 Original Android Development] ctfrommn:
You can change color/gamma with FauxClock as long as it is too different from stock. I know it works with stock and Faux's enhanced stock.
[Nexus 4 Original Android Development] undercover:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Doesn't work with this one :)

I'm aware of compatibility with stock, but thank you. :)
[Nexus 4 Original Android Development] jassycliq:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Since the 22nd harsh's kernel has had gamma control... Its in the op

Edit: never mind didn't read for context
[Nexus 4 Original Android Development] ctfrommn:
Bummer.....off topic, I followed your suggestion to reflash/unroot to stock to improve battery life. Took me near all day to get things back to where I had them, but it was a good cleaning anyway. I will check for any improvement and report back either way. It is a very interesting hypothesis though.
[Nexus 4 Original Android Development] _motley:
Yes, the following is a good transmission because the sum(kgamma 1-9) = 169 = kgamma[0]

echo "169 9 8 7 6 5 4 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_red

The whole idea is to make it a bit harder to use, but not too hard. This will force new users to read the documentation and learn about what they are doing before they try to start pumping numbers in. Also, if an app dev decides to use this interface, it also keeps the app honest and safe (especailly while under development) in case there is a bug in the app and it trys to send the wrong data. This is a sensitve and potentially dangerous operation and having this extra check in place is a good thing. After that, users and app devs are on their own.

P.S. Just to point out, the code above doesn't look to be current because I added the extra checks for max char size and the max gamma 0 & gamma 1 in the next commit.
[Nexus 4 Original Android Development] undercover:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

I'm using a different kernel

Well, it's the best explanation I could come up with. Hope it works well for you. :)
[Nexus 4 Original Android Development] ctfrommn:
It was an intriguing enough hypothesis to make me try it.....me too.
[Nexus 4 Original Android Development] DowntownJeffBrown:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

It worked wonders for me.

- Gained 1.5-2 hours screen on time.

- Made my auto brightness work. (when I got my N4 auto brightness didn't work)

- I actually gained 1gb of extra storage with the same set up.

- Now my color/gamma settings stick in faux clock. (When I got my N4 the color setting would reset to stock values after every reboot)

Sent from my Nexus 4 using Xparent BlueTapatalk 2
[Nexus 4 Original Android Development] ctfrommn:
I didnt have any of those issues......did you ever update to 4.2.1 OTA or did you just go straight to root/custom recovery?
[Nexus 4 Original Android Development] Harsh:
I still dont understand why your custom setting of gamma (init.d script) wont interfere with fauxclock... because both values would be called as soon as screen off/on cycle is done. Why is it working? now my C skills failing to understand this...
[Nexus 4 Original Android Development] _motley:
Both faux's sysfs interface and my extended sysfs interface write into the same gamma char array contained in the following structure

#ifdef CONFIG_LGIT_VIDEO_WXGA_CABC
struct dsi_cmd_desc faux123_power_on_set_1[33];
#else
struct dsi_cmd_desc faux123_power_on_set_1[28];
#endif

On store example for kgamma_r_n:

faux123_power_on_set_1[6].payload[i] = kgamma[i]

When the screen comes back on, the LCD is just using whatever is in the char array at that time (i.e. last app or script to write the values)

static int mipi_lgit_lcd_on(struct platform_device *pdev)
...
ret = mipi_dsi_cmds_tx(&lgit_tx_buf,
faux123_power_on_set_1,
mipi_lgit_pdata->power_on_set_size_1);
...

Another point that I should mention that might help and make more sense of it. His app isn't required to keep the gamma settings on screen on, it is only required for keeping the RGB settings. I already fixed this in another commit two months ago. I think I recall seeing you pick up the commit, but I may be thinking of someone else:

https://github.com/motley-git/kernel-Nexus4/commit/4efe7f19a0356677f63be0dc1130fd9a526e5bcd

(notice faux's comment at the bottom:))

That all being said, I probably wouldn't recommend that someone use both interfaces at the same time for the day to day. I don't know what resident values his apps holds and when it tries to set them. You could use the app for tuning the gamma values and then create an init.d script to persist the values without having to have the app resident in memory all the time.

Tune and then just grab the current settings including the valid checksum:

cat /sys/devices/platform/mipi_lgit.1537/kgamma_red
cat /sys/devices/platform/mipi_lgit.1537/kgamma_green
cat /sys/devices/platform/mipi_lgit.1537/kgamma_blue
[Nexus 4 Original Android Development] Harsh:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

@motley Could not quote it as using phone. But I guess I will stick to checksum==9 method. Easy for user and also cooperate with app and original sysfs...

Last execute wins is not what I like again, all due to double implementation. Why don't you fix faux code, and his app as no mechanism to check correct values, though got whole set of defaults from Google and lg both. So it won't matter.

And yes, I do have your "mako LCD: keep RGB custom colors alive after screen off/on" commit. :D

Sent from my Nexus 4
[Nexus 4 Original Android Development] DowntownJeffBrown:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Yes I updated

But this shows me that lg didn't flash my original stock boot.img correctly at the factory

Sent from my Nexus 4 using Xparent BlueTapatalk 2
[Nexus 4 Original Android Development] _motley:
"Last execute wins" has nothing to do with the double implementation. If you follow how this works, this is simply the way it is. You will have the same thing to deal with because your script and the app will write values to the same place. The last one to write will win. That's just the way it will work if you are trying to echo with a script as well as trying to use the app at or near the same time.

Well, I tried to explain the reasons why keeping a checksum is wise...that is all I can do I guess;) The checksum == 9 is no longer a checksum since it doesn't validate the data transmission with the sender. If something is implemented as a standard, I sure hope they keep a real checksum in place. It just makes sense due to the reasons I explained earlier (rouge app under development, new users in a hurry etc.). Nothing is foolproof, but it does help a bit to keep things on the right track by forcing folks to think about what they are doing.
[Nexus 4 Original Android Development] Harsh:
My meaning about "Last execute wins" was when all values are set in both kgamma_r and also in kgamma_red. But different values, example one is Google preset values other is LGPreset (one script to echo both, just for testing). So by this, actually kgamma_red value will only stick...

Anyways checksum used here was not checking actually passing values, it was just to prevent users to do it easy way. And values will always be passed correctly if its going to pass from your new implementation (2nd commit size and 31 limit), so developing app wont have effect of passing bad stuff if its out of range. :D... And not many develop apps based on this I guess :confused:....

But I guess its enough on this, we both know there are risks in here, and we deal in that differently :D
[Nexus 4 Original Android Development] Armin_van_buuren:
It is normal that afternoon so long to load up to 100% battery?

Both yesterday and today I'm noticing that it takes a very long time to complete the load.
[Nexus 4 Original Android Development] romeoliny:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Harsh,

Is it normal for your kernel to kick a** like this? The battery life/speed I'm getting is unmatched with PA.

I'm blown away honestly and I've been flashing for a while now. I also appreciate that you don't *junk* your kernel up with unnecessaries.

There are some good kernels out there but thus far, this is the best. Keep up the good work man!
[Nexus 4 Original Android Development] Pedro Peguero Jr.:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

+10000
[Nexus 4 Original Android Development] Harsh:
What happened? I did not change anything in battery as of yet, which could effect on charging. :(

And guys something that is coming very very soon :D

LG Preset Undercover

#!/system/bin/sh

# First we set colors
echo "255 255 255" > /sys/devices/platform/kcal_ctrl.0/kcal

# Now Gamma, need to change values at place 6 and 7 only
# value at 6 is amp0 and at 7 is amp1
# kgamma_r is for red, g for green and b for blue

# values amp0 and amp1 are located below $$$$
# ---------------------$$$$$-----------
echo "208 114 21 118 0 [B][COLOR="Red"]20 00[/COLOR][/B] 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_r
echo "210 114 21 118 0 [B][COLOR="red"]19 00[/COLOR][/B] 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_g
echo "212 114 21 118 0 [B][COLOR="red"]19 00[/COLOR][/B] 80 48 2" > /sys/devices/platform/mipi_lgit.1537/kgamma_b
# undercover's LG Preset values :D, thank you.

My kernel defaults, Google Preset

#!/system/bin/sh

# First we set colors
echo "255 255 255" > /sys/devices/platform/kcal_ctrl.0/kcal

# Now Gamma, need to change values at place 6 and 7 only
# value at 6 is amp0 and at 7 is amp1
# kgamma_r is for red, g for green and b for blue

# values amp0 and amp1 are located below $$$$
# --------------------$$$$$-----------
echo "208 64 68 118 1 [COLOR="red"][B]04 02[/B][/COLOR] 48 32 1" > /sys/devices/platform/mipi_lgit.1537/kgamma_r
echo "210 64 68 118 1 [B][COLOR="red"]00 00[/COLOR][/B] 48 32 1" > /sys/devices/platform/mipi_lgit.1537/kgamma_g
echo "212 32 35 116 0 [B][COLOR="red"]26 16[/COLOR][/B] 80 51 3" > /sys/devices/platform/mipi_lgit.1537/kgamma_b
# Harshkernel default settings

Maybe you want to keep above script ready and set it your own values :D
[Nexus 4 Original Android Development] persheshhater:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

I gotta fully agree with you!
[Nexus 4 Original Android Development] nokkenas:
Hey guys, I got a question before flashing this. Is reset kernel a stock kernel? Do I need to flash it before I flash this kernel? I was coming from franco's kernel. Also which one should I download if my phone CPU bin is "fast", normal 100 mV UV or low voltage?

Thanks!
[Nexus 4 Original Android Development] ctfrommn:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Yes, coming from Franco you need to flash stock kernel or reflash your ROM.
[Nexus 4 Original Android Development] nokkenas:
I read "Added westwood+ and set as default" on changelog. But on Trickster it's showing as Reno. Is it normal? Or should I change it to westwood? There's only westwood not westwood+ by the way.
[Nexus 4 Original Android Development] DowntownJeffBrown:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Westwood+ is westwood

Westwood is default. Did u have any kernel controlling apps on that had Reno (set at boot)?

Sent from my Nexus 4 using Xparent BlueTapatalk 2
[Nexus 4 Original Android Development] joho5:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

I am running this kernel but have only 3 governors to choose from and 1 i/o scheduler... Is this correct?
[Nexus 4 Original Android Development] gianton:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

That's the beauty of it, simple and fast! Yes it's correct.
[Nexus 4 Original Android Development] DowntownJeffBrown:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Yes

Sent from my Nexus 4 using Xparent BlueTapatalk 2
[Nexus 4 Original Android Development] joho5:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Awesome, thanks.
[Nexus 4 Original Android Development] kennyp987:
OK So I thought it was just in my mind at first but I tried it a few times and my phone is charging very very slow on 1/28 LOW
[Nexus 4 Original Android Development] nokkenas:
I had franco's app when I installed harsh kernel, but I reset it to default then uninstall it. Now I'm using Trickster Mod. Can you give me default values for this kernel? Thanks.
[Nexus 4 Original Android Development] samthe2can:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Every so often my Nexus 4 charges slowly.

Its happened on every ROM and Kernel I've used.

If your problem is the same a mine, when its charging, go to the battery screen, it will either say Charging (AC) or Charging (USB).

When its Charging (USB) there isn't the required voltage getting through to the charger, this happens with mine because I have to have it on a long extension cable to reach my bedside table.
[Nexus 4 Original Android Development] kennyp987:
yup it says USB not AC thanks for the tip
[Nexus 4 Original Android Development] WoozyBE:
Phone freezes...

Mine is fast binned. I tried both kernels, normal and low. Both boot fine and work but the phone freezes as I lock it, screen won't turn on again and I have to hold power to reboot. The uv voltages are as intended by the kernel and I haven't changed any settings. Anybody else having the same problems?
[Nexus 4 Original Android Development] gianton:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

No more app to control the gamma settings, perfect!

Sent from my Nexus 4
[Nexus 4 Original Android Development] DowntownJeffBrown:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

Max- 1.512

Min- 384

Voltage- 0 mv

Up treshold- 90

Sampling rate- 5000

Optimal freq- 384000

Synchro freq- 384000

GPU govenor- On demand

GPU clock- 400 mhz

I/o scheduler (eMMC)- Row

Read head size (eMMC)- 512

EMMC Entropy contribution- on

Sweep to wake- off

TCP congestion- Westwood

Vibration control- 70% (I may have messed with this one so it might actually be 100% as stock harsh)

Sent from my Nexus 4 using Xparent BlueTapatalk 2
[Nexus 4 Original Android Development] Stylez Ray.:
Harsh, I just wanted to say thank you for this lovely kernel.

Ever since I got my N4 back in December I tried every kernel and every settings combination one can imagine but never was satisfied because they all had just OK performance while suffering battery life. By now I know that my battery generally sucks but this is a problem of my usage and not Rom or Kernel related.

Last week I was so pissed off because I tried all kernels but never cared about yours so I flashed it and I am still blown away. Yours gives me incredible performance out of the box with a slight better battery life.

With my usage I can't expect a great jump regarding my battery because one like me who turns on the screen every minute just to scroll through my homescreens and apps to see how smooth everything works can't expect wonders.
[Nexus 4 Original Android Development] DowntownJeffBrown:
Re: [KERNEL][UV][Linux 3.4.28] Harsh Kernel build Jan-28

What type of screen on time/total battery time are u getting? What rev are you?

Sent from my Nexus 4 using Xparent BlueTapatalk 2
[Nexus 4 Original Android Development] more2come:
I had a minor issue this morning with most recent release of harsh kernel. When I turned my device on, screen turned on, but no lockscreen, all black. Turned it off and on again, everything worked fine again. I presume this has to do with the voltage settings? I have a fast binned device and use harsh's "low" voltages.
[Nexus 4 Original Android Development] Armin_van_buuren:
I notice that in the last two loads takes much more time to get to 100% load.

With the release of the 24th did not notice that it took so long and yesterday I consulted with a friend who also uses Low version and also have the feeling that it takes longer to load.

Otherwise Harsh fantastic job.