[T-Mobile, Samsung Galaxy SIII] decimalman:
Goodies:

dkp doesn't come with its own splash screen. However, the dkp installer (i.e. the install zip) is smarter than you think, and can apply a custom splash screen for you. Here's how:

Create a folder on your internal storage named "dkp"

Copy a PNG image into the directory, and rename it "splash.png". Alternatively, copy an RLE image (i.e. from a flashable custom splash screen zip) and rename it "splash.rle". Ideally, the image should be roughly 1280x720 to begin with, since it won't be resized.

The image will be used as your splash screen whenever you flash dkp. Reflash to apply initially.

mikedavis120 has put together a how-to video that covers tweaking dkp for optimal battery life. If you're new to dkp, take a look! He also put together a zipped collection of apps that will come in handy while tuning dkp. It also includes a flashable zip, "dkp-debug_v1.zip". After flashing it, running

su
dkp

from a terminal emulator will collect lots of useful debug information that will make it much easier for me to track down the issue you're having. :good: mikedavis120 recommends installing SuperSU (included in the zip) instead of what's included in you ROM.

[YOUTUBE]_44LMgwgdnU[/YOUTUBE]

sysfs:

It's possible to adjust all the settings available in dkp without using apps. Because they show up as files, settings can be adjusted with file managers, terminal emulators, adb and initscripts. Here's the most interesting files inside sysfs:

/sys/devices/platform/mipi_samsung_oled.513/lcd/panel/panel_colors (not available on newer AOSP builds): display tint (0 = very red, 2 = default, 4 = trinity colors)

/sys/class/misc/gammacontrol (only available on newer AOSP builds): various color controls. See this post for details on enabling Trinity colors on builds that use these controls.

/sys/devices/system/cpu/cpu<N>/cpufreq/UV_mV_table: voltage table

/sys/devices/system/cpu/cpu<N>/cpufreq/scaling_...: scaling_governor is the governor, scaling_min_freq and scaling_max_freq are the minimum and maximum frequencies, scaling_available_governors and scaling_available_frequencies show the available governors and frequencies

/sys/kernel/dkp/force_fast_charge: fast charge

/sys/kernel/dkp/link_core_settings: when linked (the default), frequency settings and some governors are automatically copied to the other core

/sys/kernel/dkp/vmin: minimum processor voltage in mV

/sys/kernel/mm/uksm/run: activate UKSM

auto-hotplug tuners:

These show up in the governor settings for any governor that doesn't do its own hotplugging. They only take effect when using auto-hotplug, so you'll probably need to disable mpdecision in Trickster.

hotplug_intpulse: when set to 1, automatically turns core 2 on whenever the screen/buttons/whatever is pressed. Default is 0.

hotplug_sampling_periods: number of samples to use for average number of running tasks. Default is 15.

hotplug_sampling_rate: number of 'jiffies' (currently 1 jiffy = 10 ms) between each sample of running tasks. Default is 20 (0.2 sec).

hotplug_enable_one_threshold: the average number of running tasks required to turn core 2 on, multiplied by 100. Default is 125 (1.25 tasks on average).

hotplug_disable_one_threshold: the average number of running tasks required to keep core 2 on, multiplied by 100. Default is 250 (2.5 tasks on average).

freelunch/nanolunch tuners:

freelunch and nanolunch aren't materially based on other governors, so their configuration is quite different than other governors. There's lots of tuners, since I haven't really decided on an ideal tuning. I encourage experimentation! I'll explain a bit of how these governors work before actually listing the tuners.

Generally speaking, there are two modes: in "normal" mode, sampling is done occasionally and frequency is generally increased slowly; in "interactive" mode, sampling is done much more quickly, and frequency increases much more quickly. "Interactive" mode ends after several samples of very low usage. The idea of a "hispeed" frequency is used in lots of governors, and it refers to the frequency that the CPU will jump to when more CPU usage is needed; generally, it's a generous estimate of how much CPU will be needed. Here, the hispeed frequency is adjusted on-the-fly, increasing when more CPU is needed and gradually decreasing when the CPU is idle. In "interactive" mode, the hispeed frequency is kept fairly high so that everything will feel snappy.

Hotplugging is taken care of in the least complicated (and in my opinion, most reasonable) way possible: if core 1 is using lots of CPU, and there are several tasks running (in other words, if it's likely that core 2 will have something to do), core 2 is turned on; if either core isn't doing much except using power, core 2 is turned off.

sampling_rate: the usual

hotplug_up_cycles: number of consecutive heavily-loaded samples before core 2 is turned on

hotplug_down_cycles: number of consecutive lightly-loaded samples before core 2 is turned off

hotplug_up_load: number of running tasks required to bring core 2 online

hotplug_up_usage: number of used CPU cycles (in thousands per second) required to bring core 2 online

hotplug_down_usage: number of used CPU cycles (in thousands per second) required on both cores to keep core 2 online

overestimate_khz: number of CPU cycles to overshoot usage by in "normal" mode

hispeed_thresh: if CPU usage is within this many cycles (in thousands per second) of the maximum frequency, frequency will be increased to the hispeed frequency. Generally, hispeed is pretty low in "normal" mode, and fairly high in "interactive" mode.

hispeed_decrease: when the CPU is sitting idle, the hispeed frequency is decreased by this amount each sample (this isn't ideal, but it works)

interaction_hispeed: the initial hispeed frequency when switching to "interactive" mode

interaction_return_cycles: number of consecutive lightly-loaded samples before returning to "normal" mode

interaction_return_usage: number of used CPU cycles (in thousands per second) required to stay in "interactive" mode

interaction_panic (nanolunch only): when set to 1, allows aggressively jumping past the current hispeed frequency under some circumstances

interaction_sampling_rate/overestimate_khz: equivalent to the "normal" versions of the tuners, these take effect in "interactive" mode