[ROM][X][O][8.1][WEEKLY]OmniROM

Search This thread

A Good Kid

Senior Member
Jul 20, 2017
129
21
Snapchat glitching.. When recording video there is a line across the screen.. Otherwise I would have used the rom.. XD but it's glitching so no thanks..
 

twain55

Senior Member
Jan 21, 2018
88
39
you're not formatting userdata, do that to remove stock encryption.
Thanks a lot man, didn't realise that. I successfully flashed the rom, and here's a few things i noticed.
The battery backup isn't as bad as the others are commenting. Actually better than stock Oreo. Rom is very smooth.
But otg doesn't work, 120 hz display doesn't work(didn't expect it to since the kernel probably doesn't support it yet), night light doesn't work, it would be great to have EXFAT support, led light is sort of buggy, and charging is slow.
But I love it. Kudos✌️
 

oshmoun

Senior Member
Aug 29, 2012
1,397
1,458
¯\_(ツ)_/¯
Thanks a lot man, didn't realise that. I successfully flashed the rom, and here's a few things i noticed.
The battery backup isn't as bad as the others are commenting. Actually better than stock Oreo. Rom is very smooth.
But otg doesn't work, 120 hz display doesn't work(didn't expect it to since the kernel probably doesn't support it yet), night light doesn't work, it would be great to have EXFAT support, led light is sort of buggy, and charging is slow.
But I love it. Kudos

:eek:
ok some of those issues are known, but others aren't
otg doesn't work? what device did you try to attach, a usb stick? if yes, is the usb stick you're trying to attach exfat formatted?
exfat support is there, just needs a bit more work. You can see it working if you set selinux to permissive.
120hz and nightlight are known issues
buggy led and slow charging are new issues, care to explain?
 

twain55

Senior Member
Jan 21, 2018
88
39
:eek:
ok some of those issues are known, but others aren't
otg doesn't work? what device did you try to attach, a usb stick? if yes, is the usb stick you're trying to attach exfat formatted?
exfat support is there, just needs a bit more work. You can see it working if you set selinux to permissive.
120hz and nightlight are known issues
buggy led and slow charging are new issues, care to explain?
1. Slow charging with other sony charger than the one provided with the phone.. The one provided with it heats the device up a lot(maybe its just an issue for my device, but didn't have it on the stock rom). Not a big issue for me tho..
2. OTG doesn't work even with FAT32 devices. I tried both, exfat and FAT32.. Maybe a problem With just the dual model? I'll try setting the selinux mode to permissible. Again, not a big issue for me since I transfer files over wifi mostly.
3. Led sometimes keeps blinking when the screen is off for the apps which last showed notification.. (for eg. I've set the led to blink blue for a WhatsApp notif, and it kept blinking blue when I turned the screen off and the notification was dismissed). Also happens when charging. I've set the display to stay off when I plug the device in, but when I disconnect the phone, the light stays on before I turn the screen on.
 
  • Like
Reactions: oshmoun

~Marin

Member
Jul 7, 2018
8
4
could you also please try this recovery? this one is based on aosp kernel, not stock.
If this also works then it's at least known that the aosp kernel is safe to use for recovery.

Did you compile that from Omnirom? If so, how? It looks like all the necessary files and configuration for TWRP are there, but running make recoveryimage yields the stock/AOSP recovery. I'd like to be able to compile and mess with it myself, but probably miss something obvious ;)
More specifically, the AOSP 3.2.1 variant seems to slow down over time, eventually freezing up entirely. I'd like to test a newer version before digging further.

Also, have you found anything useful related to night-light? It works on Omnirom 7.1 without libsdm, even though the codepaths seem identical (besides some renamings). I have not been able to compile 7.1 yet to figure out what I've overlooked.
 

oshmoun

Senior Member
Aug 29, 2012
1,397
1,458
¯\_(ツ)_/¯
Did you compile that from Omnirom? If so, how? It looks like all the necessary files and configuration for TWRP are there, but running make recoveryimage yields the stock/AOSP recovery. I'd like to be able to compile and mess with it myself, but probably miss something obvious ;)
More specifically, the AOSP 3.2.1 variant seems to slow down over time, eventually freezing up entirely. I'd like to test a newer version before digging further.

Also, have you found anything useful related to night-light? It works on Omnirom 7.1 without libsdm, even though the codepaths seem identical (besides some renamings). I have not been able to compile 7.1 yet to figure out what I've overlooked.
omnirom does not automatically include twrp, you need to change the repo for bootable/recovery to point at twrp instead of aosp recovery. that's the obvious you were missing ?
it would be great if you could check what causes the slowdown.

about night light, your observation is correct, the codepath didn't change. the adreno blobs are simply refusing to enable it. what you can try out is to replace adreno blobs in /odm with ones from omni 7.1
 
Last edited:

~Marin

Member
Jul 7, 2018
8
4
omnirom does not automatically include twrp, you need to change the repo for bootable/recovery to point at twrp instead of aosp recovery. that's the obvious you were missing
it would be great if you could check what causes the slowdown.
Thanks! That was too obvious to be seen :D
Slowdowns are still there. I'm not sure if it's caused by just leaving the device booted into TWRP for a while, toggling the screen a few times or flashing an image (more so the workload). Nothing abnormal in the logs, and only a bunch of warning traces about unbalanced regulator disables (one on ibb_reg, the rest on camera regulators). And these are all logged at the startup phase, nothing afterwards. I'll try to find the exact reproduction steps later, and let me know if you need the logs.

about night light, your observation is correct, the codepath didn't change. the adreno blobs are simply refusing to enable it. what you can try out is to replace adreno blobs in /odm with ones from omni 7.1
Unfortunately this yields nothing but a couple "interesting" observations:
  1. On a clean v13 odm partition: After boot, the screen is white, but when "restarting" the graphics composer (adb shell killall [email protected]) the screen turns amber. Turning nightlight off or changing the intensity has no effect; the amount of amber stays the same the entire time.
  2. With the libraries matching *adreno* and all those in egl from the latest Sony 7.1 odm blob (AOSP_N_MR1_5.7_r1_v08_loire), a bunch of E SurfaceFlinger: Error while linking shaders: errors are logged with an empty shader linker log, followed by a null pointer dereference: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 2302 (surfaceflinger), pid 2302 (surfaceflinger):
    Code:
    backtrace:
        #00 pc 0000000000183a30  /odm/lib64/egl/libGLESv2_adreno.so (EsxProgramResult::AllocateSymbols()+3228)
        #01 pc 000000000004583c  [anon:libc_malloc:000000747c400000]
  3. With the same list of libraries, but from the last omirom 7.1.2 weekly release, it does not find any EGL configs:
    Code:
    SurfaceFlinger: no suitable EGLConfig found, giving up
    (This error was thrown with the V08 odm libraries as well, when omitting the non-adreno libraries in the egl folder).
Any suggestion what I should look into going forward? I do not have much if any hardware/driver experience so this is going to be a learning curve ;)
 
  • Like
Reactions: oshmoun

oshmoun

Senior Member
Aug 29, 2012
1,397
1,458
¯\_(ツ)_/¯
Unfortunately this yields nothing but a couple "interesting" observations:
  1. On a clean v13 odm partition: After boot, the screen is white, but when "restarting" the graphics composer (adb shell killall [email protected]) the screen turns amber. Turning nightlight off or changing the intensity has no effect; the amount of amber stays the same the entire time.
  2. With the libraries matching *adreno* and all those in egl from the latest Sony 7.1 odm blob (AOSP_N_MR1_5.7_r1_v08_loire), a bunch of E SurfaceFlinger: Error while linking shaders: errors are logged with an empty shader linker log, followed by a null pointer dereference: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 2302 (surfaceflinger), pid 2302 (surfaceflinger):
    Code:
    backtrace:
        #00 pc 0000000000183a30  /odm/lib64/egl/libGLESv2_adreno.so (EsxProgramResult::AllocateSymbols()+3228)
        #01 pc 000000000004583c  [anon:libc_malloc:000000747c400000]
  3. With the same list of libraries, but from the last omirom 7.1.2 weekly release, it does not find any EGL configs:
    Code:
    SurfaceFlinger: no suitable EGLConfig found, giving up
    (This error was thrown with the V08 odm libraries as well, when omitting the non-adreno libraries in the egl folder).
Any suggestion what I should look into going forward? I do not have much if any hardware/driver experience so this is going to be a learning curve ;)

expected as much, and honestly I don't think this is resolvable without major changes. Here are a couple things that may or may not have played a role in the crashes:
1. hardware composer 2 is not supported by omni 7.1 adreno blobs afaik
2. omni 8.1 uses a 4.4 kernel base and display hal (not 3.10 like 7.1) and using blobs compiled for a different kernel version is usually just asking for trouble
3. selinux may have a role to play here as well, consider building a permissive boot.img

Oh and about the amber screen, did you change white point calibration under ExtendedSettings?

All in all, trying to get night light to work this way (i.e using old adreno where it worked) is most probably infeasible
 
  • Like
Reactions: ~Marin

~Marin

Member
Jul 7, 2018
8
4
expected as much, and honestly I don't think this is resolvable without major changes. Here are a couple things that may or may not have played a role in the crashes:
1. hardware composer 2 is not supported by omni 7.1 adreno blobs afaik
2. omni 8.1 uses a 4.4 kernel base and display hal (not 3.10 like 7.1) and using blobs compiled for a different kernel version is usually just asking for trouble
3. selinux may have a role to play here as well, consider building a permissive boot.img
1. I thought that the hardware composer communicated to the screen/GPU/driver, not the other way around; my knowledge is totally lacking here (now that I think of it, adreno drivers are for the GPU, which only does rendering, whose results are then passed on to the composer which puts it on the display in some way, maybe even by using the GPU :D).
2. I guess we can't just ask Sony to compile these libraries for kernel 4.4? Or well, that's probably what's in 8.1 odm images anyway (though with updates and modifications I suppose).
3. I did not see any denials, so it does not come as a surprise that a permissive boot.img doesn't change anything (be it with v08 or omni-7.1 adreno libs).

Anyway, just to be sure: would copying just the libraries with the word adreno, and those in the egl folder be enough? (I could probably verify this myself by checking the dynamic section of these libs, even if I have no idea what half of them do ;)).

Even though we both mentioned the code path is still the same, I'm not too sure about that anymore. Libsdm-color.so is missing from omnirom 7.1 (and I cannot remember having to manually flash an odm image back then, confirmed by the fact that all the other vendor libraries are stored in the flashable zip), so if the code were the same it should've refused to work at all; unless the code takes another route somewhere, or has a working fallback. I might look into this further.

Oh and about the amber screen, did you change white point calibration under ExtendedSettings?
I didn't touch that setting, it's been on 6000k by default. Toggling it does turn the display back to the right white point, so it's probably related (I suppose it's just taking an incorrect default value after being killed).

All in all, trying to get night light to work this way (i.e using old adreno where it worked) is most probably infeasible
Yeah, and I'd rather use newer/updated blobs anyway. Aside from checking why omni-7.1 works without libsdm-color.so I do not have enough knowledge to dig further, except if we can get more debugging information from said library (eg. why it's reporting invalid parameter; if it's not supported in some way I'd expect a different response).

That all said, isn't this "technical" discussion a bit offtopic here?
 

oshmoun

Senior Member
Aug 29, 2012
1,397
1,458
¯\_(ツ)_/¯
Anyway, just to be sure: would copying just the libraries with the word adreno, and those in the egl folder be enough? (I could probably verify this myself by checking the dynamic section of these libs, even if I have no idea what half of them do ;)).

Even though we both mentioned the code path is still the same, I'm not too sure about that anymore. Libsdm-color.so is missing from omnirom 7.1 (and I cannot remember having to manually flash an odm image back then, confirmed by the fact that all the other vendor libraries are stored in the flashable zip), so if the code were the same it should've refused to work at all; unless the code takes another route somewhere, or has a working fallback. I might look into this further.

Yeah, and I'd rather use newer/updated blobs anyway. Aside from checking why omni-7.1 works without libsdm-color.so I do not have enough knowledge to dig further, except if we can get more debugging information from said library (eg. why it's reporting invalid parameter; if it's not supported in some way I'd expect a different response).

Ah, I think you misunderstood my point. The codepath for the open source part is the same (from the android framework down to the display hal) but then when the blobs are reached, there are changes.
libsdm-color didn't exist on 7.1 because the code handling color transformation was inside another library. the new adreno blobs split that to its own library, and it just so happens that this library refuses to work with our hardware version.

Now that that's cleared up, you've been doing it wrong :)
the libraries to copy aren't only ones named adreno and those in egl, there are others.
https://hastebin.com/ewicirikez.bash
this list is with the additional libsdm blobs, so it's ok to have some of those missing in 7.1
also, there may be eventually some libraries that are missing, but I think with those copied, you should see in logcat what other libraries are getting linked via dlopen, then add those as well.
 

~Marin

Member
Jul 7, 2018
8
4
Ah, I think you misunderstood my point. The codepath for the open source part is the same (from the android framework down to the display hal) but then when the blobs are reached, there are changes.
libsdm-color didn't exist on 7.1 because the code handling color transformation was inside another library. the new adreno blobs split that to its own library, and it just so happens that this library refuses to work with our hardware version.
As far as I can tell the opensource part in the display hal is the same as well, and tries to call setColorTransform through libsdm-color, which doesn't exist. Unless it calls somewhere else and I have just mixed up all these same-named functions in different classes ;)

the libraries to copy aren't only ones named adreno and those in egl, there are others.
https://hastebin.com/ewicirikez.bash
this list is with the additional libsdm blobs, so it's ok to have some of those missing in 7.1
also, there may be eventually some libraries that are missing, but I think with those copied, you should see in logcat what other libraries are getting linked via dlopen, then add those as well.
How exactly did you compile that list? Did you clear out all vendor libraries and started searching for used libs from there? I assume that is what you want me to do to eventually find missing libraries in logcat, otherwise it would just load the ones already there from 8.1 ;)
 

~Marin

Member
Jul 7, 2018
8
4
As it turns out, the opensource part is completely different, and has nothing to do with the Adreno vendor libs. Omnirom 7.1 still uses HWC1, which applies the color transform directly in the Client Compositor (GL shader in SurfaceFlinger): https://github.com/omnirom/android_...ceflinger/SurfaceFlinger_hwc1.cpp#L2173-L2184.
However, Omnirom 8.1 uses HWC2, which supports querying the Display HAL for all kinds of features such as whether the Client Compositor can skip the color transform (because the Device Compositor takes care of it). Luckily HWC2 supports color transforms in the Client Compositor as well (without having to port anything), so all I had to do was remove that flag from the display capabilities to make SurfaceFlinger apply the transform here:
https://github.com/omnirom/android_...surfaceflinger/SurfaceFlinger.cpp#L2631-L2636.

Now that that's covered, how do you propose we continue? This flag could be placed behind a guard (only for Loire boards), or the Adreno libraries "have to" be fixed properly. I can keep this change locally but assume others want to use night light as well ;)
 
Last edited:
  • Like
Reactions: oshmoun

oshmoun

Senior Member
Aug 29, 2012
1,397
1,458
¯\_(ツ)_/¯
As it turns out, the opensource part is completely different, and has nothing to do with the Adreno vendor libs. Omnirom 7.1 still uses HWC1, which applies the color transform directly in the Client Compositor (GL shader in SurfaceFlinger): https://github.com/omnirom/android_...eflinger/SurfaceFlinger_hwc1.cpp#L2173-L2184.
However, Omnirom 8.1 uses HWC2, which supports querying the Display HAL for all kinds of features such as whether the Client Compositor can skip the color transform (because the Device Compositor takes care of it). Luckily HWC2 supports color transforms in the Client Compositor as well (without having to port anything), so all I had to do was remove that flag from the display capabilities to make SurfaceFlinger apply the transform here:
https://github.com/omnirom/android_...urfaceflinger/SurfaceFlinger.cpp#L2631-L2636.

Now that that's covered, how do you propose we continue? This flag could be placed behind a guard (only for Loire boards), or the Adreno libraries "have to" be fixed properly. I can keep this change locally but assume others want to use night light as well ;)
DUDE!
you worked around the issue? that's awesome!
I wasn't aware of that flag to skip client color transformations.
i would suggest adding a property to check whether the flag should be set or not.

EDIT: I think this is it
https://github.com/omnirom/android_...m8998/sdm/libs/hwc2/hwc_session.cpp#L218-L230
need to patch this to remove the flag

EDIT2: yup, it works :D
 
Last edited:
  • Like
Reactions: ~Marin

~Marin

Member
Jul 7, 2018
8
4
DUDE!
you worked around the issue? that's awesome!
I wasn't aware of that flag to skip client color transformations.
i would suggest adding a property to check whether the flag should be set or not.
Yes, I just needed to build Omnirom 7.1 to see where I was missing the point. I'll get to adding a property to ignore or include that flag; any suggestion on the direction and naming?

Hehe that link is already in my post :D

It doesn't work, music player, Already format SD and nothing happened, music is on SD card.
Is your music in a subfolder in the Music directory on the SD card? I noticed that Phonograph (the default music player in omnirom) refuses to play any file that's not directly in the Music folder.

Also, MusicFX has never been working for me (no obvious errors to be seen), but while messing around with the rom it worked quite a few times and even survived a restart. But unfortunately it's back to being a no-op again (no errors when creating or updating the effect, but the sound is not changed). That's the next thing I'll be looking into...
 
  • Like
Reactions: Polukin

Top Liked Posts

  • There are no posts matching your filters.
  • 19
    X/SUZU/F5121 OmniROM BUILDS

    OREO 8.1

    DOWNLOAD WEEKLY

    REQUIREMENTS TO SUCCESSFULLY FLASH OMNIROM:
    1. The device has the latest stock ftf
    2. The device has an unlocked bootloader
    3. The ODM image zip has been downloaded from HERE, and the ODM image has been extracted from it
    4. The WEEKLY zip file has been downloaded and copied to the device

    INSTALLATION INSTRUCTIONS:

    1. Reboot device to fastboot mode, and flash the ODM image with this command
    Code:
    fastboot flash oem <ODM image>
    2. Reboot device to TWRP and flash the WEEKLY zip file
    3. (Optional) Flash a gapps package
    4. Reboot device to system

    CURRENT ISSUES ON OFFICIAL:

    1. No USB tethering
    2. Wifi sometimes fails to turn on

    KERNEL SOURCE: https://github.com/omnirom/android_kernel_sony_msm/tree/android-8.1

    BUG REPORTS

    REPORT BUGS ONLY:

    - AFTER A CLEAN INSTALL
    - USING STOCK OMNI KERNEL
    - NO MODS OF ANY SORT

    OMNI GERRIT REVIEW

    [url]https://gerrit.omnirom.org/[/URL]

    DISCLAIMER:

    No one is responsible for any damage done to your device but YOU. You've been warned.
    8
    What is the problem with a boot crash? Do you reboot that often? If I can successfully boot my device after some attempts, it is not such a critical issue. The old security level is more critical. Sidechannel updates are problematic, because of the different signatures. I don't want to wipe my device every time.
    How many boot attempts are needed in average?

    well, good news
    I think I narrowed the issue down to a single service (hwcomposer)
    with some luck, it should be simple to find the exact cause now
    4
    Software binaries for AOSP updated
    4
    A notice for the upcoming weekly:
    The kernel has been updated to a new version. This requires an updated odm image.
    If you update to the weekly of 20180128, when it's released, then you MUST flash the new odm image from OP, otherwise you'll end up with issues like a nonfunctional camera.