Ana Menü Android Telefon Yazılım Rom Destek Teknoloji Sitesi

Kernel Özellikleri
   
   Changed some auxiliary CPU clock dividers for frequencies 1600,1704,1800 MHz. These frequencies should use less power now and also should be more easily reached with more stability or lower voltage depending on your device.
   Fixed CPUPower driver (Back from alpha20); this will now skew the reported processing capacity of CPU0 in the lower frequencies up until 500MHz to be 8 times greater than CPU1-3, what it does now is that the scheduler will even more migrate tasks onto CPU0 to avoid idle wakeups on the remaining CPUs, resulting in increased power efficiency. For high load > 500MHz, the driver reverts back to the default power configuraitons.
   Reset the regulator configurations to their physical minima; you can now undervolt to 600mV on the GPU. Sorry I missed this before.
   New feature: Dynamic Screen Frequency Scaling.
   
   This decreases the display controller frequency in tandem with the CPU speed. Usually when you have low activity on the screen; i.e. low re-draw rates, then you mostly also have logically low CPU load. I wrote a scaling mechanic to switch between high display frequency (60Hz), and low display frequency (40Hz) in accordance to CPU scaling. This is tied in in the CPUFreq governor, in this case PegasusQ. We have three new governor configurables found in /sys/devices/system/cpu/cpufreq/pegasusq/ (Or alternatively just use SetCPU):
   
   lcdfreq_enable: Enables or disables the mechanic, disabled by default.
   lcdfreq_kick_in_down_delay: The amount of samples to wait on below the threshold frequency before entering low display frequency mode. Default value is 5 for now, a.k.a. in most cases 250ms unless accelerated flexrate is active on low load (fingers touching the screen), then depending on situation it might get as low as 62.5ms.
   lcdfreq_kick_in_freq: The frequency threshold below which the low display frequency kick-in will be active. Default is 500MHz, and should probably stay as such, setting it higher will cause lags as we'd be using 40Hz in an interactive situation.
   
   For the curious: I made a rudimentary time_in_state state accounting sysfs in /sys/devices/platform/samsung-pd.2/s3cfb.0/graphics/fb0/lcdfreq/time_in_state for testing purposes. Currently it shows wrong time values for 60Hz as the driver gets initialized before the high resolution timer, and I'll fix that later, but the 40Hz time statistics are correct.
   
   Notice: There will be now conflicts between this and user-space controlled TwDVFS service/app. The service would limit screen frequency to 40Hz while using the camera app, this will be now overridden. I also thought the service would do more but I could not find it scaling for anything else than the camera, so it's pretty much useless in my mind, and you could theoretically remove it.
   
   Feedback 23.3: This feature causes flickering on bright colours and low brightness. Enable it at your own will.
   Changed the functionality to boost to 60Hz on any touch interaction, regardless of CPU speed.
   
   Please provide feedback on fluidity and battery life.
   
   Değişiklik Listesi
   Perseus alpha35 (06/04):
   
     Further rewrote the in-kernel audio controls:
       Threw out the old detection methods for something more robust.
       This particularly enables non-cellular applications such as Skype, Viber, and so on to be detected correctly. A "calling" state now includes any and all use-cases where the audio is outputted via the phone's earpiece. This fixes microphone levels for such apps to correctly use the calling sensitivity value.
       Added microphone level for camera use, this state is enabled whenever a camera stream is active. It should give more options into adjusting things to your likings.
       By now the sound engine has only little similarities to Boeffla, any bugs and feedback now go directly to me.
     Developers only: MHS: Added a new small tool for tracking media use and reporting it to other in-kernel drivers. Capable of detecting video recording, decoding and camera streams for now. See commit for more info.
     mDNIe control changes:
       Removed several controls in STweaks simply because people misunderstood them or misused them, or they simply had no rational use.
       Video detection, now with the help of MHS, is no longer limited to the stock video player. Any video players using hardware decoding will now be able to make use of edge enhancement, HDR and DNR, this includes any web-based players and the YouTube app.
     Custom LED controls implemented; Exposed most variable controls for the notification LED via sysfs and STweaks (LED tab). :
       Control LED brightness. Currently the OS dictates, depending on brightness detected by the light-sensor, wether to run the LED in a low-power mode or in a high-power mode, you can now set brightness for both.
       Blinking control, this is basically the shape of the wave-pattern that the LED blinks in, you have several controls, best described the data-sheet description:
   
   
       The fade-in time period is TT1 in the graph, while the fade-out period is TT2.
       Slope (1/2/3/4) detention time represents DT1,2,3,4 in the graph, it controls how "steep" the four different curves are.
       The LED fading checkbox simply switches between having the detention times controlled by the sliders to having them to 0 (Stock blinking behaviour).
     Increased default zRAM size to 400mB. This won't override your STweaks setting, so only new users will see the new value. Others should please adjust the value manually to your liking.
   
   
   TAR - Linklerin Görülmesine İzin Verilmiyor Üye ol Veya Giriş Yap
   CWM - Linklerin Görülmesine İzin Verilmiyor Üye ol Veya Giriş Yap