User reported problems for Liquid and Mourta kernel goes here.

[Guest juantech]

Well there will be a last stable version of SlimLP but LP will soon be overtaken by M which will probably solve a lot of the version problems from LP.

 

That is unimportant when it comes to the code and the actual updates, they are forthcoming with a new version of KK, it's just that i don't have to hack together something that semi works with KK like i have to do with LP.

If you want to run newer versions of Android for absolutely no reason what so ever other then you're going to have to find another way home.

 

I'm going with the last version where i can implement full support without hacking the living crap out of everything to even get it to boot most of the time.

thanks for the info, well im a person what do not like change much of rom(i only used allways the yours, i only one day i was test others for see the difference and test if my mhl cable works on this phone,later i was seeing things and i sayed mourta kernel its best and then i returned to the rom i was ls 5.0), and how i sayed i like really much your new lollipop version for this i will wait until 6.0 smarthsmallow.

i understand what kk its best but how i sayed i like too much your new lollipop for change it now xD

i have more than 3 hours of battery life with it :)

Edited October 16, 2015 by juantech

[Guest TJHookr]

No, it's not a baseband problem, i have the same baseband and i don't have this problem.

 

It's something else.

 

Try enabling awesome player and if that doesn't help, did you change anything with regards to audio like install some package that affects audio, does switching AudioFX settings change anything?

 

Please understand that i'm not going to spend a lot of effort on this ROM since i don't consider any LP ROM to be something i want to work with, i'm reverting to the last known good that we actually have support for without patching things to hack it into working properly, KK.

I tried switching on awesome player but it didn't help :(

unfortunately I have had this problem since your first 3.4 kernel (the almost vanilla one was the last without this bug)

I grabbed a new catlog and took a look at it (I quoted the logs between the power off and on and attached the whole log):

relevant logs start at
10-17 16:45:28.452 I/PowerManagerService(924): Going to sleep due to power button (uid 1000)...
that is when I pressed the power button
then plugged in my headphones
and there was no wiredaccessorymanager activity like when the phone is awake and I plug them in :(

is there any logs that cloud help debugging the problem, dmesg or something might help? (I can repoduce it 100% of the time)

10-17 16:45:28.452 I/PowerManagerService(924): Going to sleep due to power button (uid 1000)...

10-17 16:45:28.500 I/PowerManagerService(924): Sleeping (uid 1000)...

10-17 16:45:28.506 V/Sensors (924): int poll__activate(sensors_poll_device_t*, int, int)

10-17 16:45:28.512 V/Sensors (924): int sensors_poll_context_t::activate(int, int)

10-17 16:45:28.513 D/Sensors (924): Sensor_enable:4 0

10-17 16:45:28.513 V/Sensors (924): enable - sensor Accelerometer (handle 4) en -> dis

10-17 16:45:28.514 V/Sensors (924): enabled_sensors: 0 dmp_started: 1

10-17 16:45:28.514 V/Sensors (924): Stopping DMP

10-17 16:45:28.515 I/Sensors (924): Disabled 9 axis sensor fusion

10-17 16:45:29.016 I/MPL-mldl_cfg_mpu:(924): inv_mpu_suspend(,,,,7fff) -> 0000

10-17 16:45:29.050 W/SurfaceFlinger(542): captureScreen: error creating EGL fence: 0x3004

10-17 16:45:29.073 D/PhoneStatusBar(28830): disable: < expand ICONS* alerts SYSTEM_INFO* back home recent clock search >

10-17 16:45:29.083 E/WifiStateMachine(924): cancelDelayedScan -> 172

10-17 16:45:29.085 V/AudioWrapper(549): adev_set_parameters

10-17 16:45:29.085 V/nvaudio_hw(549): nvaudio_dev_set_parameters : screen_state=off

10-17 16:45:29.093 E/TaskManager(28830): refreshTaskManagerView

10-17 16:45:29.100 W/ResourceType(28830): No package identifier when getting value for resource number 0x00000000

10-17 16:45:29.101 W/PackageManager(28830): Failure retrieving resources for com.slim.slimlauncher: Resource ID #0x0

10-17 16:45:29.128 D/BluetoothAdapter(28830): 854141229: getState() :  mService = null. Returning STATE_OFF

10-17 16:45:29.129 D/BluetoothAdapter(28830): 854141229: getState() :  mService = null. Returning STATE_OFF

10-17 16:45:29.133 D/BluetoothAdapter(28830): 854141229: getState() :  mService = null. Returning STATE_OFF

10-17 16:45:29.133 D/BluetoothAdapter(28830): 854141229: getState() :  mService = null. Returning STATE_OFF

10-17 16:45:29.136 W/Settings(28830): Setting airplane_mode_on has moved from android.provider.Settings.System to android.provider.Settings.Global, returning read-only value.

10-17 16:45:29.147 D/BluetoothAdapter(28830): 854141229: getState() :  mService = null. Returning STATE_OFF

10-17 16:45:29.147 D/BluetoothAdapter(28830): 854141229: getState() :  mService = null. Returning STATE_OFF

10-17 16:45:29.262 D/PhoneStatusBar(28830): disable: < expand ICONS alerts SYSTEM_INFO back HOME* RECENT* clock SEARCH* >

10-17 16:45:29.286 W/OpenGLRenderer(28830): Incorrectly called buildLayer on View: TextView, destroying layer...

10-17 16:45:29.480 V/Sensors (924): int poll__activate(sensors_poll_device_t*, int, int)

10-17 16:45:29.480 V/Sensors (924): int sensors_poll_context_t::activate(int, int)

10-17 16:45:29.480 D/LightSensor(924): LightSensor-enable EN(0), newState(0),mEnabled(1)

10-17 16:45:29.481 V/LightSensor(924): [LIGHT]APDS LIGHT SET ENABLE: flags = 0

10-17 16:45:29.484 I/DisplayManagerService(924): Display device changed: DisplayDeviceInfo{"Built-in Screen": uniqueId="local:0", 720 x 1280, 60.04139 fps, supportedRefreshRates [60.04139], density 320, 309.966 x 309.638 dpi, appVsyncOff 0, presDeadline 17655177, touch INTERNAL, rotation 0, type BUILT_IN, state OFF, FLAG_DEFAULT_DISPLAY, FLAG_ROTATES_WITH_CONTENT, FLAG_SECURE, FLAG_SUPPORTS_PROTECTED_BUFFERS}

10-17 16:45:29.487 V/ActivityManager(924): Display changed displayId=0

10-17 16:45:29.493 D/SurfaceFlinger(542): Set power mode=0, type=0 flinger=0x40c82000

10-17 16:45:29.493 D/hwcomposer(542): hwc_blank: display 0: blank

10-17 16:45:29.493 D/hwcomposer(542): hwc_blank_display: display 0: [0 -> 1]

10-17 16:45:29.493 D/hwcomposer(542): hwc_blank_display: releasing buffer 0x38

10-17 16:45:29.493 D/hwcomposer(542): dc_blank: display 0, [0 -> 1]

10-17 16:45:29.627 D/PowerManagerService-JNI(924): Excessive delay in autosuspend_enable() while turning screen off: 101ms

10-17 16:45:38.990 I/wpa_supplicant(1061): rfkill: WLAN unblocked

10-17 16:45:38.990 I/wpa_supplicant(1061): rfkill: WLAN unblocked

10-17 16:45:38.990 I/wpa_supplicant(1061): rfkill: WLAN unblocked

10-17 16:45:38.990 I/wpa_supplicant(1061): rfkill: WLAN unblocked

10-17 16:45:41.944 I/wpa_supplicant(1061): rfkill: WLAN unblocked

10-17 16:45:41.944 I/wpa_supplicant(1061): rfkill: WLAN unblocked

10-17 16:45:41.944 I/wpa_supplicant(1061): rfkill: WLAN unblocked

10-17 16:45:41.944 I/wpa_supplicant(1061): rfkill: WLAN unblocked

10-17 16:45:42.984 I/PowerManagerService(924): Waking up from sleep (uid 1000)...

 

logcat_and_device_info.zip

[Guest TJHookr]

took another log this is with dmesg event logcat and radio

the reproduction started at:

10-17 18:32:20.920 I/PowerManagerService(  915): Sleeping (uid 1000)...

there were some failed reproductions in the log, probably didn't wait enough for the phone to go to sleep, but it might be useful to see the differences

I understand that you don't want to bother too much with this rom, but this will probably be present in any future kk roms too, so if it is not that big bother please have a look at the logs, much appriciated

2015-10-17_18.42.zip

[Guest Mourta]

took another log this is with dmesg event logcat and radio

the reproduction started at:

10-17 18:32:20.920 I/PowerManagerService(  915): Sleeping (uid 1000)...

there were some failed reproductions in the log, probably didn't wait enough for the phone to go to sleep, but it might be useful to see the differences

I understand that you don't want to bother too much with this rom, but this will probably be present in any future kk roms too, so if it is not that big bother please have a look at the logs, much appriciated

2015-10-17_18.42.zip

That it was something that existed since the first version of my 3.4 seems very strange because almost all power code as well as regulator and audio has been rewritten and updated since then.

 

However, since earlysuspend is going away pretty much all power code is rewritten once again and new notification call chains are implemented and this is something i'll look into while doing that because it looks like the notification call chain doesn't trigger as it should for this part.

[Guest TJHookr]

That it was something that existed since the first version of my 3.4 seems very strange because almost all power code as well as regulator and audio has been rewritten and updated since then.

 

However, since earlysuspend is going away pretty much all power code is rewritten once again and new notification call chains are implemented and this is something i'll look into while doing that because it looks like the notification call chain doesn't trigger as it should for this part.

great news!

as this doesn't seem to trigger for many people, if you would like me to test something I would be more than happy to help

[Guest Mourta]

great news!

as this doesn't seem to trigger for many people, if you would like me to test something I would be more than happy to help

Tell Giuseppe i recommended you for testing and please report via him.

 

I'm almost done fixing up the power part which is the actual stage that kept us from moving through versions, i removed the X3 code and X3 specific drivers, i may reimplement some later on but it works without them, half of them are just in the way anyway or just used for driving things like the report engine which i'm pretty sure was put in the code with good intentions but is just spyware that accumulates cycles for no good reason.

 

We need to go as far back to basics as possible and we're almost there, once that is done we have a few hundred lines of differing code and that should be easy enough to implement in any version.

 

Not much has changed between 3.10 and 3.19 that we need to care about so once we are up to speed on 3.10, i'm moving to the last stable kernel for everything.

 

That is NOT to say that there are not things from TEGRA 3.14 and 3.16 i might want to use later on, it's just that i'm moving to latest and reviews will be suspended until that feels like a stable option for us.

 

I successfully removed the RGB bridge and since it's not really used for anything by the removal of the old earlysuspend it's not coming back in the form it was, i still have to rewrite the powersaving code and we can't use a simple pin save call notifier on that so i am going to have to implement a new driver for that.

 

Note that writing a new driver is not an easy task and it will take time to test and review to make that work as it should.

 

It's worth the effort though because without it, we're stuck.

[Guest Mourta]

great news!

as this doesn't seem to trigger for many people, if you would like me to test something I would be more than happy to help

BTW, it's solved now, i just tested it in the beta0.10 in every possible way i can think of with three different stereo and headset versions and they all worked just fine no matter if i put them in during sleeping hours (verified via logcat that it was woken up)  and via asp-suspend gadgets (i used to use these testing audio for my own additions to Linux so ... it's the old s*** i use in my toolbox for testing my changes on kernel) and it works fine now.

 

Also fixed the call chain for video, doesn't matter, we'll still need full upgrades for fence sync to make this work. We are now at almost 4300 marks up from 1300 stock and 2500-3400 from my starting point to the last known stable kernel... 

 

So... yeah... we've got something here that works like a mongrel from hell in regards to speed, now let's tame it and tuck it neatly into the rest of our code and make the whole thing work.

 

I'm having fun with the code now, i prefer to have fun with it before release.

[Guest TJHookr]

I just reread the no wipe no whine policy :)

Edited November 2, 2015 by TJHookr

[Guest Mourta]

I am sorry to report that the problem did not go away for me :(  I might have some freak hardware or something?

there are some failed reproductions and the bug happened at 11-02 23:01:48.546

also I noticed today a different behavior: I was listening to music and the sound came from the headset the right way, I paused it, the phone went to sleep but did not pull my headset out, and after a 2-3 minutes I just woke the phone and pressed play and the sound came from the speakers, as if the phone has "forgotten" that the headsets were plugged in, would you like me to try to reproduce this?

also I only dirty flashed it on the 0.9 that I restored with twrp, do you think it would make a difference if I did a clean install?

2015-11-02_23.08.zip

You don't need to wipe anything as long as you are in my SlimROM so that is not the problem.

The call chain is made for a newer version of the kernel, i had to do the same with audio and video since earlysuspend is going away.

This probably means that it will be a bit flakey until i move the powerbase to 3.10 but then i have to move a lot of other things to 3.10 too so it's basically a question of how things are implemented, i have to do them in the right order and i'm sorry about this but you'll have to be patient because the fix i included was for audio during suspend, it is not really a perfect solution until we move first the video, then the powerbase, then move to independent EDP and a multitude of other things, then i can implement the code for the hook in the board files.

Video is near finished, powerbase is already implemented, the rest will be fairly simple, most of it is as i said before a file copying process to bring it up to date, then we'll just patch update to last known T30 support for some things and beyond that for some other things.