Related
Since data drops on PPP builds still appear to be a major problem for some users, I decided to post this workaround for converting any sense PPP build to RMNET. I have only tested this on Mdeejay Revolution build but should work with any sense build. I have used this for more than 10 days now without any problems whatsoever: everything worked like on the original build.And no data drops.
All attached files were extracted from Sergio's CoreDroid version 0.5 which is an RMNET build. Hope he doesn't mind.I am not at all a developer
The steps are outlined below:
1. Download and extract the attached files on your PC
2. Open the Android folder of your build on your PC, and copy + replace the zImage and rootfs with the extracted ones.
3. Boot into Winmo and transfer your android folder to your SD card; also transfer the extracted module folder to your SD
4. Boot into Android; after initial setup, reboot again.I recommend a clean fresh install (ie without any old data image; you may re-use your data.img after setup is complete)
5. Use Root explorer to copy and replace the 2 files in the extracted modules folder into \system\lib\modules.
6. Reboot and enjoy
UPDATE 7/11/2010
[08/11/2010]After further testing of this update, I have found the screen to be laggy and had a SOD. I tried reinstalling after that and had no data connection but wifi worked ok. I have therefore abandoned using the update and sticking with the original one above. Of course if it works for you stick with it.
I have tested a newer nexus kernel of 5/11/2010 (found here) on Mdeejays Desire Revolution build (Desire based build). Both wifi and data work, and camera is 5MP. However only a clean fresh install appears to work.
Just download the file NewRMNET, extract contents unto desktop, copy all 3 into the Android folder of your build. Then boot into Winmo and transfer to SD card. Boot into android 2-3 times. That's it.
Once again the rootfs.img file is from Coredroid v0.5
Please leave feedback. I dont use BT or wifi Hotspot so will not know if they work.
Cheers.
Hmmmm... I think I'll try this as soon as I get home. Will edit this post with an update in a few hours.
EDIT:: Seems this actually broke my ROM all together.. Sucks... Oh well. I've been meaning to test a few other ROM's out anyway. This just gives me a good excuse to finally do it.
I'm downloading now....gonna try it and see.i'll let you know how it does!!Thanks
Hi,
Thank you for sharing.
So does that mean that for Sergio's CoreDroid version 0.6 ROM ... it already has RMNET right?
CoreDroid 0.5 is RMNET, 0.6 is PPP.
tried it and it didn't help any.and now my wifi doesn't work,just gettin an error message.going back to the way I had it before!
Yz450rider14 said:
tried it and it didn't help any.and now my wifi doesn't work,just gettin an error message.going back to the way I had it before!
Click to expand...
Click to collapse
Wifi will not work if the bcm4329.ko and tun.ko files contained in the modules folder are not replaced in \system\lib\modules folder with root explorer or a file explorer with root rights.
Yz450rider14 said:
tried it and it didn't help any.and now my wifi doesn't work,just gettin an error message.going back to the way I had it before!
Click to expand...
Click to collapse
Was that an internet temper tantrum?
Seems to work well.. so far no problems and data is slow but steady.. Better than constant connection loss.. I created a folder set> 'root/system/lib/modules' in my android folder to make wifi work perfectly...No need to use root explorer. and if I switch zimage again, its easy to delete.. Thanks!
stonesolouk said:
Since data drops on PPP builds still appear to be a major problem for some users, I decided to post this workaround for converting any sense PPP build to RMNET. I have only tested this on Mdeejay Revolution build but should work with any sense build. I have used this for more than 10 days now without any problems whatsoever: everything worked like on the original build.And no data drops.
All attached files were extracted from Sergio's CoreDroid version 0.5 which is an RMNET build. Hope he doesn't mind.I am not at all a developer
The steps are outlined below:
1. Download and extract the attached files on your PC
2. Open the Android folder of your build on your PC, and copy + replace the zImage and rootfs with the extracted ones.
3. Boot into Winmo and transfer your android folder to your SD card; also transfer the extracted module folder to your SD
4. Boot into Android; after initial setup, reboot again.I recommend a clean fresh install (ie without any old data image; you may re-use your data.img after setup is complete)
5. Use Root explorer to copy and replace the 2 files in the extracted modules folder into \system\lib\modules.
6. Reboot and enjoy
Click to expand...
Click to collapse
This work around is a great idea, however changing the zImage file is changing the kernel. I believe coredroid v.05 uses mychiprimas r11 kernel to be rmnet. the internet is great but then there is low incall volume as well as low notification and ringtone volume. Those are a downer for me.
I read somewhere that Hastarin was making a RMNET kernel to try out but I dont know how that turned out.
Try this low volume fix here; worked great for me.
R3BrotherJr said:
This work around is a great idea, however changing the zImage file is changing the kernel. I believe coredroid v.05 uses mychiprimas r11 kernel to be rmnet. the internet is great but then there is low incall volume as well as low notification and ringtone volume. Those are a downer for me.
I read somewhere that Hastarin was making a RMNET kernel to try out but I dont know how that turned out.
Click to expand...
Click to collapse
awesome!!
stonesolouk said:
Try this low volume fix here; worked great for me.
Click to expand...
Click to collapse
thank you so much for the sound fix, does anyone know if bluetooth is working normally with the RMNET workaround?? I mean a2dp and FF, RW, play/pause, as well as in call??
can someone comfirm??
THANK YOU SOOOOOO MUCH!!! Sick and tired of PPP failing!!!! Again many thanks.
R3BrotherJr said:
I read somewhere that Hastarin was making a RMNET kernel to try out but I dont know how that turned out.
Click to expand...
Click to collapse
I did it, but turns out RMNET in the EVO tree is broken.
I'm not sure what the OP has done here. I would presume he's provided a Nexus based kernel and files to convert a particular build to RMNET.
If so that's a step backwards in my opinion. PPP with the recent patches to the kernel and wrapper is about as stable as we could hope for and we have a lot of fixes since the Nexus tree was last updated.
PPP still has to reconnect if your phone hops between towers/bands but seems to do so relatively reliably now. I have no idea how RMNET handles that situation.
Of course I realize others out there may want to live with RMNET and without the other fixes/features (working compass, g-sensor fixes, light sensor, etc). Each to their own.
stonesolouk said:
Since data drops on PPP builds still appear to be a major problem for some users, I decided to post this workaround for converting any sense PPP build to RMNET. I have only tested this on Mdeejay Revolution build but should work with any sense build. I have used this for more than 10 days now without any problems whatsoever: everything worked like on the original build.And no data drops.
All attached files were extracted from Sergio's CoreDroid version 0.5 which is an RMNET build. Hope he doesn't mind.I am not at all a developer
The steps are outlined below:
1. Download and extract the attached files on your PC
2. Open the Android folder of your build on your PC, and copy + replace the zImage and rootfs with the extracted ones.
3. Boot into Winmo and transfer your android folder to your SD card; also transfer the extracted module folder to your SD
4. Boot into Android; after initial setup, reboot again.I recommend a clean fresh install (ie without any old data image; you may re-use your data.img after setup is complete)
5. Use Root explorer to copy and replace the 2 files in the extracted modules folder into \system\lib\modules.
6. Reboot and enjoy
Click to expand...
Click to collapse
Is it possible that this fix be included by the chefs ... because I can't really follow the instruction.
Thank you, thank you, thank you so much!
Sent from my GT-P1000 using XDA App
Did a fresh copy of mdeejay revolution 2.3 and this kernel yesterday evening. No datadrop at all! Also did the wifi and volume fix, wonderful.
Many Many Many Thanks!!!!!
WiFi Hotspot
WiFi hotspot dont works with this.
i1magic said:
Is it possible that this fix be included by the chefs ... because I can't really follow the instruction.
Click to expand...
Click to collapse
All this really does is to swap the build back to using the old nexus kernel, presumably if the chefs wanted the old kernel in their build they'd already be using it.
hastarin said:
PPP still has to reconnect if your phone hops between towers/bands but seems to do so relatively reliably now. I have no idea how RMNET handles that situation.
Click to expand...
Click to collapse
I seem to recall someone saying that it is handled by Android (as opposed to the kernel), since RMNET is the "official" way to do things in Android.
Awesome!
Thanks for making this.
Can't wait to try it with some of the great builds here.
Was getting tired of all the build lately only using busted PPP based kernels.
What good is a data phone if the data connection is a joke.
im compiling 4.4.4 via slimkat source. when i add the governor(s) mtp and file transfer, both windows and ubuntu, breaks. just recieved the device and little to know support for it. steps involved-1. built kernel source and flashed kernel=no problem. 2. added govervor(s) and flashed=no mtp or file transfer. 3. including governors in rom build= not an option. the modules will not build. i edited the defconfig multiple ways, the kernel will build, not adding the new governor(s). adb access is working. any suggestions?
Hi there,
i was searching the forum and the inet without any luck about information on how to create or generate *.dtsi files which are placed (in my case) in:
Code:
android\system\kernel\oppo\msm8939\arch\arm\boot\dts\qcom\15018\
im bringing up a new device the "Oppo R7S" which is a sibling device of the "R7 Plus".
So far i was able to compile and boot CyanogenMod succefully. Everything worked except for the Videorecorder
Here are a few pictures: http://community.oppo.com/en/forum.php?mod=viewthread&tid=45106&extra=&page=2
I have noticed that the display driver that my rom has used in my bring-up was either the one for the 15018/R7Plus or for the 15011/R7.
I can't remember which one. I went back to stock before i wrote it down. However it is not the one which should be used which is 15023.
This is where i noticed i must have missed something. I checked my panel in the stock rom using DevCheck and under Graphics it lists the Panel:
Code:
oppo15023samsung s6e3fa3 1080p cmd mode dsi panel
so i checked my stock rom where it gets that info.
On the stock rom i have a file in "system/etc/" it is named
Code:
pp_calib_data_oppo15023samsung_s6e3fa3_1080p_cmd_mode_dsi_panel.xml
But this couldn't be it. So i assumed it must be the display driver in the kernel.
I looked into the CyanogenMod sources https://github.com/CyanogenMod/android_kernel_oppo_msm8939/tree/cm-13.0/arch/arm/boot/dts/qcom
and i was right. There was no 15023 display driver.
Long story short. How do I create and generate those dtsi files?
At the moment this is an Unofficial Rom but i plan to make it an Official Rom as soon as all problems have been fixed.
I hope anyone can help me on my porting "adventure"
This is my device tree: https://github.com/Celoxocis/android_device_oppo_r7sf
celoxocis said:
I have noticed that the display driver that my rom has used in my bring-up was either the one for the 15018/R7Plus or for the 15011/R7.
I can't remember which one. I went back to stock before i wrote it down. However it is not the one which should be used which is 15023.
This is where i noticed i must have missed something. I checked my panel in the stock rom using DevCheck and under Graphics it lists the Panel:
Code:
oppo15023samsung s6e3fa3 1080p cmd mode dsi panel
so i checked my stock rom where it gets that info.
It gets that info from the kernel device tree.
On the stock rom i have a file in "system/etc/" it is named
Code:
pp_calib_data_oppo15023samsung_s6e3fa3_1080p_cmd_mode_dsi_panel.xml
But this couldn't be it.
Click to expand...
Click to collapse
Yeah, that's just Qualcomm's color calibration stuff.
So i assumed it must be the display driver in the kernel.
I looked into the CyanogenMod sources https://github.com/CyanogenMod/android_kernel_oppo_msm8939/tree/cm-13.0/arch/arm/boot/dts/qcom
and i was right. There was no 15023 display driver.
Long story short. How do I create and generate those dtsi files?
Click to expand...
Click to collapse
dts(i) is essentially just code. It's not autogenerated. In the CM kernel we only include the device tree files for devices we actually support (at the moment that's 14005, 15011 and 15018). For getting those files for your devices, the best source is a stock ROM release. Look's like you're lucky: https://github.com/oppo-source/R7plus-5.1-kernel-source/tree/master/arch/arm/boot/dts/15022
Click to expand...
Click to collapse
maniac103 said:
dts(i) is essentially just code. It's not autogenerated. In the CM kernel we only include the device tree files for devices we actually support (at the moment that's 14005, 15011 and 15018). For getting those files for your devices, the best source is a stock ROM release. Look's like you're lucky: https://github.com/oppo-source/R7plus-5.1-kernel-source/tree/master/arch/arm/boot/dts/15022
Click to expand...
Click to collapse
OMG, i was looking the other day at oppo-source github but i let myself fool by the "R7plus-5.1-kernel-source" naming and didn't look for the dts folder.
Thanks so much!
Could i simply copy the entire 15022 folder into
Code:
"cm-13.0\android\system\kernel\oppo\msm8939\arch\arm\boot\dts\qcom"
and compile the CM-rom?
I have a working device-tree and a working cm-rom, except proper display drivers. My guess is, it would include the display driver files in the kernel at my next compile.
Or would i have to edit specific files to make it work?
So far all i did was to simply copy the
Code:
cp cyanogenmod_r7plus_defconfig cyanogenmod_r7sf_defconfig which is in
cm-13.0/android/system/kernel/oppo/msm8939/arch/arm64/configs
and edit Android.mk in
cm-13.0/android/system/device/oppo/msm8939-common#
to include "r7sf"
Code:
LOCAL_PATH := $(call my-dir)
ifneq ($(filter r7sf f1f r5 r7 r7plus, $(TARGET_DEVICE)),)
One last question. What is the best way to make the Oppo R7Sf Officially supported by CM?
My device tree is already on github. I will soon commit the latest changes to it. I would really love for it to be included in CM Officially.
celoxocis said:
OMG, i was looking the other day at oppo-source github but i let myself fool by the "R7plus-5.1-kernel-source" naming and didn't look for the dts folder.
Thanks so much!
Could i simply copy the entire 15022 folder into
Code:
"cm-13.0\android\system\kernel\oppo\msm8939\arch\arm\boot\dts\qcom"
and compile the CM-rom?
Click to expand...
Click to collapse
You'll also need to add a top level dts file and add it to the Makefile. You can use the r5 commit as reference: http://review.cyanogenmod.org/143086
You'll also need to make some small modifications to get a working accelerometer: http://review.cyanogenmod.org/144868
What DTS to you use currently? Normally you should get an error by the bootloader as no DTS for 15022 is currently included.
One last question. What is the best way to make the Oppo R7Sf Officially supported by CM?
My device tree is already on github. I will soon commit the latest changes to it. I would really love for it to be included in CM Officially.
Click to expand...
Click to collapse
Let's make it work first Once we have it working (by adding the missing kernel bits), we can have ciwrl fork the device tree to CM and include it in nightlies. Please make sure to put up all required changes outside of the device tree to Gerrit.
Gesendet von meinem R7plusf mit Tapatalk
maniac103 said:
You'll also need to add a top level dts file and add it to the Makefile. You can use the r5 commit as reference: http://review.cyanogenmod.org/143086
You'll also need to make some small modifications to get a working accelerometer: http://review.cyanogenmod.org/144868
Let's make it work first Once we have it working (by adding the missing kernel bits), we can have ciwrl fork the device tree to CM and include it in nightlies. Please make sure to put up all required changes outside of the device tree to Gerrit.
Gesendet von meinem R7plusf mit Tapatalk
Click to expand...
Click to collapse
Thank you! Well the good thing is i made no changes except those mentioned above outside of the device tree. I tracked changes in the R7 Plus device tree and forked the device tree for the R7S.
And of course removed the bits which were not needed such as fingerprint support. While tracking Uberlaggydarwins F1f device tree i knew what i had to remove.
Thank you! I have seen the R5 commit and already made a diff check last night between 15011 and 15018 to see which files are common files and which are different, this way i can "base" my 15022 DTS files off.
The common files are probably refreshed (newer) files from CM than those from Oppo's github.
As far as i have noted:
Code:
meaning:
"+" = Identical(common) between 15011 and 15022
"<----" = means 15022 differs here:
+msm8939-bus.dtsi
+msm8939-camera.dtsi
+msm8939-coresight.dtsi
+msm8939-cpu.dtsi
+msm8939-gpu.dtsi<----
+msm8939-iommu.dtsi
+msm8939-iommu-domains.dtsi
+msm8939-ion.dtsi
+msm8939-ipcrouter.dtsi+
+msm8939-mdss.dtsi<----
+msm8939-mdss-pll.dtsi+
+msm8939-pm.dtsi<----
+msm8939-regulator.dtsi<----
+msm8939-smem.dtsi
+msm8939-smp2p.dtsi
+msm-gdsc-8916.dtsi
+msm-iommu-v2.dtsi
+msm-pm8916.dtsi<----
+msm-pm8916-rpm-regulato.dtsi
+skeleton64.dtsi
Not identical / different naming (diff 15011 / 15018):
(not compared with 15022 yet)
msm8939-audio-internal_codec.dtsi
msm8939-camera-sensor-mtp.dtsi
msm8939-common.dtsi
msm8939-mtp.dtsi
msm8939-pinctrl.dtsi
msm8939-v3.0-gpu.dtsi
msm8939-v3.0-pm.dtsi
msm8939-v3.0.dtsi
I can do the DTS files changes and can also do the changes in:
Code:
arch/arm/boot/dts/qcom/Makefile
drivers/input/touchscreen/synaptics_oppo/synaptics_oppo_driver_3508.c
but to be honest the changes below scare me off. I'm not an developer/coder. Im an Windows/Linux/Unix Systems Integrator my skills for coding are limited to simple scripts :-/
Code:
drivers/usb/phy/phy-msm-usb.c
sound/soc/codecs/wcd9xxx-mbhc.c
sound/soc/msm/msm8939-slimbus.c
maniac103 said:
What DTS to you use currently? Normally you should get an error by the bootloader as no DTS for 15022 is currently included.
Click to expand...
Click to collapse
I have not enable insecure adb for adb logging during boot. But I think it is using the DTS file for 15018. Devcheck shows the panel (display driver) as 15018.
I finished compiling CM13.0-20160520
and in this version i don't know why both but Cameras stopped working. Previously they worked but Videocamera did not. I guess this will fix once i include and compile the 15022 DTS files.
Orientation / Rotate is actually inverted. When i rotate the phone 90° Left the Display will rotate 90° right and vice versa. So it is inverted. Same with 180° degree. It will be upside/down.
Not sure what happened here, it worked in an older version. Maybe the "timestamp" fix from a few weeks ago worked for the R7S?
Display driver is 15018 but I'm working on that
Everything else works perfectly fine!
Previously to fix the audio and microphone i used the audio_platform_info.xml and mixer_paths_mtp.xml from the R7Plus.
I did compare mixer_paths_mtp.xml of the R7Plus and R7S from ColorOS stock and they only differed in one single line. It worked.
Only thing left are the TFA9890 profiles for the R7S https://github.com/oppo-dev/proprietary_vendor_oppo/commit/c66367fa3970afe98e1398a532c8553fc61d2f53
So it is not much to fix before everything works as most of the work has been done for the R7Plus by you guys
celoxocis said:
Thank you! I have seen the R5 commit and already made a diff check last night between 15011 and 15018 to see which files are common files and which are different, this way i can "base" my 15022 DTS files off.
The common files are probably refreshed (newer) files from CM than those from Oppo's github.
Click to expand...
Click to collapse
I'd suggest going a different route: diff e.g. the 15018 DTS between Oppo's release at oppo-source and CM. Then take the 15022 DTS off Oppo's kernel and apply the 15018 diff generated before onto that. You'll see at least the changes for the accelerometer interrupt and for the tfa9890 (the latter had reset pin and regulator definitions in the sound card in Oppo's kernel and has an own instantiation in ours)
I can do the DTS files changes and can also do the changes in:
Code:
arch/arm/boot/dts/qcom/Makefile
drivers/input/touchscreen/synaptics_oppo/synaptics_oppo_driver_3508.c
Click to expand...
Click to collapse
The Makefile changes are required, the TS driver likely doesn't need any changes as the 15018 kernel already supports 15022. (BTW, the 15022 TS firmware is named differently from 15018. Make sure you're using the right one.)
but to be honest the changes below scare me off. I'm not an developer/coder. Im an Windows/Linux/Unix Systems Integrator my skills for coding are limited to simple scripts :-/
Code:
drivers/usb/phy/phy-msm-usb.c
sound/soc/codecs/wcd9xxx-mbhc.c
sound/soc/msm/msm8939-slimbus.c
Click to expand...
Click to collapse
You don't need those; those were required for the R5's USB/headset mux. When pointing to the R5 support commit I was mostly referring to the DTS changes, not the (C) code changes.
I have not enable insecure adb for adb logging during boot. But I think it is using the DTS file for 15018. Devcheck shows the panel (display driver) as 15018.
Click to expand...
Click to collapse
Why not? It's only a matter of building -eng instead of -userdebug. I somewhat doubt it's using the 15018 DTS. The DTS features the model number (https://github.com/CyanogenMod/andr.../boot/dts/qcom/msm8939-v3.0-mtp-15018.dts#L23) which the bootloader uses to figure out the DTS to use. If the bootloader fell back to use 15018, that would be kinda weird.
I finished compiling CM13.0-20160520
and in this version i don't know why both but Cameras stopped working. Previously they worked but Videocamera did not. I guess this will fix once i include and compile the 15022 DTS files.
Click to expand...
Click to collapse
Maybe. It's unclear without further debugging. You can look in dmesg whether the kernel drivers found the right camera sensor. What blobs are you using? r7plus' verbatim or did you copy others off the stock ROM?
Orientation / Rotate is actually inverted. When i rotate the phone 90° Left the Display will rotate 90° right and vice versa. So it is inverted. Same with 180° degree. It will be upside/down.
Not sure what happened here, it worked in an older version.
Click to expand...
Click to collapse
It's not just the panel being inverted? You can check whether orientation is correct in recovery. If it is, the accelerometer is off and needs further debugging/fixing.
Maybe the "timestamp" fix from a few weeks ago worked for the R7S?
Click to expand...
Click to collapse
With the old state of timestamps being off the issue was that orientation changes stopped working altogether after some time. It's unrelated to your issues which must be isolated to DTS, as sensor HAL + kernel driver is working just fine on r5, r7 and r7plus.
Only thing left are the TFA9890 profiles for the R7S https://github.com/oppo-dev/proprietary_vendor_oppo/commit/c66367fa3970afe98e1398a532c8553fc61d2f53
Click to expand...
Click to collapse
That's mostly trivial as most of those files are straight copies from the stock ROM, they're just renamed. Only the .eq files need conversion (text -> binary), you can use this tool for doing that.
maniac103 said:
I'd suggest going a different route: diff e.g. the 15018 DTS between Oppo's release at oppo-source and CM. Then take the 15022 DTS off Oppo's kernel and apply the 15018 diff generated before onto that. You'll see at least the changes for the accelerometer interrupt and for the tfa9890 (the latter had reset pin and regulator definitions in the sound card in Oppo's kernel and has an own instantiation in ours)
Click to expand...
Click to collapse
You are right. That is the better route. I will see the changes and be able to apply add/delete the changes onto the 15022 DTS files.
maniac103 said:
The Makefile changes are required, the TS driver likely doesn't need any changes as the 15018 kernel already supports 15022. (BTW, the 15022 TS firmware is named differently from 15018. Make sure you're using the right one.)
Click to expand...
Click to collapse
Yes I saw the TS file naming in the source and have included those in my blob list already.
Should i use
Code:
"ifeq ($(CONFIG_OPPO_COMMON_SOFT),y)
+dtb-$(CONFIG_ARCH_MSM8916) += msm8939-mtp-15022.dtb
or rather
Code:
+dtb-$(CONFIG_ARCH_MSM8916) += msm8939-v3.0-mtp-15022.dtb
as the R7S was later released than the R7 Plus. It should be based of the R7 Plus.
maniac103 said:
Why not? It's only a matter of building -eng instead of -userdebug. I somewhat doubt it's using the 15018 DTS. The DTS features the model number (https://github.com/CyanogenMod/andr.../boot/dts/qcom/msm8939-v3.0-mtp-15018.dts#L23) which the bootloader uses to figure out the DTS to use. If the bootloader fell back to use 15018, that would be kinda weird.
Click to expand...
Click to collapse
I got curious too. I'm compiling and -eng version, once done I will flash and check the bootlog.
maniac103 said:
Maybe. It's unclear without further debugging. You can look in dmesg whether the kernel drivers found the right camera sensor. What blobs are you using? r7plus' verbatim or did you copy others off the stock ROM?
Click to expand...
Click to collapse
I extracted the dmesg and pasted it into pastebin here: http://pastebin.com/306q3xZS
maniac103 said:
It's not just the panel being inverted? You can check whether orientation is correct in recovery. If it is, the accelerometer is off and needs further debugging/fixing.
Click to expand...
Click to collapse
Im using TWRP which has no rotation. I will flash CM recovery later and check if its correct in the recovery.
maniac103 said:
That's mostly trivial as most of those files are straight copies from the stock ROM, they're just renamed. Only the .eq files need conversion (text -> binary), you can use this tool for doing that.
Click to expand...
Click to collapse
Thanks! I was looking how i would convert those two files a few weeks ago but didn't find sources.
This is a simple C-file compile?
Code:
gcc calc-biquad.c -o calc-biquad
While working on the sources and checking the diff's i discovered this difference between 15018 and 15022 (both oppo source).
Which i think could be the cause of the inverted rotation issue
Letf is 15018 and Right is 15022
(see attachment)
celoxocis said:
Should i use
Code:
"ifeq ($(CONFIG_OPPO_COMMON_SOFT),y)
+dtb-$(CONFIG_ARCH_MSM8916) += msm8939-mtp-15022.dtb
or rather
Code:
+dtb-$(CONFIG_ARCH_MSM8916) += msm8939-v3.0-mtp-15022.dtb
as the R7S was later released than the R7 Plus. It should be based of the R7 Plus.
Click to expand...
Click to collapse
Release date isn't relevant there. Check /sys/devices/soc0/revision - if it says 3.0 adding 3.0 to the DTS name is the right thing to do.
I extracted the dmesg and pasted it into pastebin here: http://pastebin.com/306q3xZS
Click to expand...
Click to collapse
dmesg alone likely isn't sufficient here. From it it looks like the sensors don't come up, though. Not sure what exactly the problem is, but are you sure you have the right blobs? Initializing the camera is mostly done by the blobs. If you say it worked some time ago, please try whether the r5 introduction kernel commit broke anything for you.
Thanks! I was looking how i would convert those two files a few weeks ago but didn't find sources.
This is a simple C-file compile?
Code:
gcc calc-biquad.c -o calc-biquad
Click to expand...
Click to collapse
Yeah, except you'll need the math library (-lm).
While working on the sources and checking the diff's i discovered this difference between 15018 and 15022 (both oppo source).
Which i think could be the cause of the inverted rotation issue
Letf is 15018 and Right is 15022
(see attachment)
Click to expand...
Click to collapse
Yes, it could. It's almost as likely that the difference is normal, though, as those properties tell the driver how the sensor is mounted in the device, and the mounting orientation isn't necessarily the same between 15018 and 15022. Worth a try though.
maniac103 said:
Release date isn't relevant there. Check /sys/devices/soc0/revision - if it says 3.0 adding 3.0 to the DTS name is the right thing to do.
Click to expand...
Click to collapse
Thanks! Checked and its "3.0" i applied 3.0 files.
maniac103 said:
dmesg alone likely isn't sufficient here. From it it looks like the sensors don't come up, though. Not sure what exactly the problem is, but are you sure you have the right blobs? Initializing the camera is mostly done by the blobs. If you say it worked some time ago, please try whether the r5 introduction kernel commit broke anything for you.
Click to expand...
Click to collapse
I just finished adding 15022 files into the kernel and started the compile. I will look into the problem as soon as i finish flashing the new rom.
I found my eeprom file for the camera too. I used to extract all blobs because i did not know which was the correct one.
maniac103 said:
Yes, it could. It's almost as likely that the difference is normal, though, as those properties tell the driver how the sensor is mounted in the device, and the mounting orientation isn't necessarily the same between 15018 and 15022. Worth a try though.
Click to expand...
Click to collapse
Yes i agree. I read about it online when i discovered the difference. The sensor is probably mounted differently in the R7S. We will see as soon as the compile is finished and i flashed the rom
So far the compile runs through without any complains to my kernel additions. I went with the suggested route. Diff CM-15018<->Oppo-15022 applied those changes to the Oppo-15022 files and got CM-15022.
I did not create a different defconfig for the R7S. I sticked with the settings from R7Plus. Just renamed it for dependency mode.
I noticed something. While i fixed up the TFA9890 files.
where did you get the "left.tfa9890_n1b12.patch" file from? it's not in the R7S nor R7Plus ColorOS stock rom.
i see one patch "TFA9890_N1C3_1_7_1.patch" which is renamed to "left.tfa9890_n1c2.patch"
i can see a second "coldboot.patch" but that looks empty and has not the same content as "left.tfa9890_n1c2.patch"
is it a generic file which is required for TFA9890? if yes. i guess i can simply copy and paste it. as "left.tfa9890_n1c2.patch" is identical in both roms?
for the compile i just copied the R7plus file as i didn't know where it came from.
n1c2/3 and n1b12 are just different revisions of the tfa9890. r7plus stock firmware carried both files IIRC; it should be OK to omit n1b12 if the r7s doesn't have that revision.
Gesendet von meinem R7plusf mit Tapatalk
maniac103 said:
n1c2/3 and n1b12 are just different revisions of the tfa9890. r7plus stock firmware carried both files IIRC; it should be OK to omit n1b12 if the r7s doesn't have that revision.
Gesendet von meinem R7plusf mit Tapatalk
Click to expand...
Click to collapse
Ok i will just leave that file out of the blob list.
I had time today to flash my new build today and test it, which included the 15022 kernel inclusions and as i hoped all the issues i had, are gone!
Thanks alot for your help!
As far as tested:
Both cameras work!
Videocamera works!
All Sensors + GPS, Wifi work too!
Flashlight works.
Rotation issue fixed too! The guess about the sensor mounting was right!
Display driver is the correct one!
I have yet to grab a boot log. "adb logcat" before and while booting the device should be enough to catch everything. right?
The only thing left to do is to filter out the proper camera blobs.
Im using JackPotClavin's Android-Blob-Utility for that.
Can i leave out the blobs for Camera, Camera autofocus, Camera chromatix which are referenced in "lib64/" ?
I have seen that the R7Plus nor the R7f use these blobs in the proprietary-files.txt.
I will try to commit all changes to github on the next weekend. Once i finish updating the blobs list with the proper camera blobs.
celoxocis said:
The only thing left to do is to filter out the proper camera blobs.
Im using JackPotClavin's Android-Blob-Utility for that.
Click to expand...
Click to collapse
That's one option, another one would be strace'ing the camera daemon (in adb shell):
Code:
su
setprop ctl.stop qcamerasvr
strace -f -eopenat /system/bin/mm-qcamera-daemon
That'll tell you what blobs it tries to open.
Can i leave out the blobs for Camera, Camera autofocus, Camera chromatix which are referenced in "lib64/" ?
I have seen that the R7Plus nor the R7f use these blobs in the proprietary-files.txt.
Click to expand...
Click to collapse
Yeah, you can, the media stack is 32 bit only.
maniac103 said:
That's one option, another one would be strace'ing the camera daemon (in adb shell):
Code:
su
setprop ctl.stop qcamerasvr
strace -f -eopenat /system/bin/mm-qcamera-daemon
That'll tell you what blobs it tries to open.
Yeah, you can, the media stack is 32 bit only.
Click to expand...
Click to collapse
I finished the blob list but there is something i have been trying to fix for days and i can't really figure out whats the cause.
It is Wifi:
In Oppo Stock ColorOS everything is fine and stable. Wifi just works out of the box. It keeps switching between 2.4Ghz and 5Ghz depending where im in the house. (Signal strength)
I have a AVM Fritzbox 7490 with the latest firmware and all features. Dual band etc.
In CyanogenMod i keep having "drop outs". The Wifi is just dropping out. Like i have it turned off.
When i force it to use only 2.4Ghz band in wifi advanced options, it never happens. I believe it happens when it should automatically switch between 2.4Ghz and 5Ghz.
In my device tree im already using the "WCNSS_qcom_wlan_nv_15022.bin" as my "WCNSS_qcom_wlan_nv.bin"
I have already checked following files and made a diff for what the cause could be:
p2p_supplicant_overlay.conf = same as stock
WCNSS_qcom_cfg.ini = same as stock
wpa_supplicant.conf = wifi-direct settings disabled. we don't need that.
wpa_supplicant_overlay.conf = same as stock
It seems like i can fix the issue when enabling "Always allow Wi-Fi Roam Scans" and "Use legacy DHCP client" in Developer Options.
But here is the problem as soon as i reboot the device those settings are unchecked.
How can i make it permanent? Is there a way to make it permanent in the device tree? to compile the ROM using those settings as default?
I can even replicate the problem by turning off those two settings and walking around the house.
Any idea?
Update:
After hours of testing. With and without the above options.
Forced 5Ghz wifi is not stable at all. I tried all combinations getting 5Ghz to work, with no luck.
Forced 2.4Ghz works fine with and without above options. So my conclusion. It is definitly something wrong with how prima handles the 5Ghz.
In stock both work fine.
Hi I am new to kernel tweaking. I am trying to compile the kernel for Xiaomi redmi 5a for latest miui stock rom from source located at
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/tree/riva-o-oss
After flashing the boot image created with compiled kernel , everything except wifi works.
Google search revealed that it is a common issue and one suggestion is to put the wil6210.ko (wifi related) file from compiled kernel in to system/lib/modules which doesn't work.
What confuses me even more is that even in if I delete the wil6210.ko from system/lib/module when the stock kernel is running , the wifi still works . It Seems like this kernel module has no effect on wifi.
But deleting the vendor/lib/modules/pronto/pronto_wlan.ko breaks wifi for stock kernel that came with the rom.
But compiling the kernel from source doesn't generate such files.
one related info at https://github.com/Genom-Project/android_kernel_xiaomi_vince-3.18/issues/2
I found a guide at https://github.com/MiCode/Xiaomi_Ke...#download-qualcomm-android-enablement-project that talks about wifi module.
The download seems to be to big and maybe too many unnecessary files will be downloaded. Tried to init and sync the repo. It seems huge. So if nothing else works will try this.
https://github.com/supercairos/android_device_xiaomi_land/issues/1#issuecomment-259458071 seems to provide a shortcut technique. It asks to download the prima folder from https://source.codeaurora.org/quic/...opensource/wlan/prima/tree/?h=LA.UM.5.3_rb1.1 (I can replace the h value to my kernels tag) , merge it into the source and then compile it to generate the prima_wlan.ko . I did so and also added CONFIG_PRONTO_WLAN=m ( m to compile as module) but such file is not being generated after compiling.
So please, if anyone went through something similar , help me with your recommendations.,
try lineage os aarch64 cumpiler and try prima wlan driver
u can use this https://github.com/baunilla/android...mmit/b7e6d4e6aed50d8ae652f292235be1398be5f344
This is LineageOS 18.1, which is based on Android 11, for the WiFi-only variants of the Samsung Galaxy Tab A 10.1" (2016), with model SM-T580 and codename gtaxlwifi, and the Galaxy Tab A 10.1" (2016) with S-Pen, with model SM-P580 and codename gtanotexlwifi. LineageOS doesn't need much of an introduction - It's a well-known custom firmware/Android distribution.
As was always planned, my LineageOS 18.1 builds continue on from @followmsi's LineageOS 18.1 builds that were intended for use by users. To update from his builds, my builds can simply be installed on top of an existing install from his builds without doing anything further (or "dirty flashed").
Downloads:
Note: While these builds are mainly intended to be used on the WiFi-only variants of these devices, they can be installed and used on LTE variants if you can go without mobile networking (of course), GPS and vibration.
Since I now have a T585, I've got LineageOS 19.1 builds for gtaxllte, and gtanotexllte as well, up in my 19.1 thread. I suggest using those.
For SM-T580/gtaxlwifi:
Latest build from 20221025 (with security patch level 20221005): https://drive.google.com/file/d/18PHMUSUW9A0ZfhjpSYCV0GiHW2Damskw/
Folder for builds (which contains a text file with a SHA256 checksum for the latest build, and a folder containing previous builds): https://drive.google.com/drive/folders/1wuirD9cyoguv7CQdEO5ymZ911k2ASKKD
For the T580, the latest official TWRP build from here should be used. If installing a build for the T580 to the LTE variant, with model SM-T585 and codename gtaxllte, keeping in mind some functionality will of course be missing as described in my note, the latest official TWRP build for gtaxllte from here can also be used.
For SM-P580/gtanotexlwifi:
Latest build from 20221025 (with security patch level 20221005): https://drive.google.com/file/d/11Iv75MtGAx4yvCWz-kN3wZOm-vgN4eE1/
Folder for builds (which contains a text file with a SHA256 checksum for the latest build, and a folder containing previous builds): https://drive.google.com/drive/folders/1fVGx1xGUxAtTvE0rG-OidwbXLM_93om2
For the P580, I've made unofficial TWRP builds from an updated device tree and the same kernel sources used for these LineageOS builds that must be used.
Download link for an image of my latest TWRP build: https://drive.google.com/file/d/1TAFLVpxdYQNvfvUPS_BGKx3imphR1Wd2/
Download link for a tar archive containing it for installation via Odin in the AP slot: https://drive.google.com/file/d/1Ay55ntZj7Uptzm--hiCaeG1C5lamQ1fG/
Changelogs:
Releases for 20221025:
Latest changes from LineageOS, including the 20221005 Android security updates.
The torch has been fixed.
Performance of animations and responsiveness has been improved slightly.
Configuration files for media codecs and profiles have been updated from Samsung's M105FDDS4CVG1 firmware, and audio codec support might be improved slightly (as the Codec 2.0 media codec framework has been fixed and is now used).
Some updates from the 4.9 Android common kernel have been applied to the kernel.
The WiFi drivers RX wakelock feature has been disabled - Heavy battery drain that occurred in sleep when connected to certain WiFi networks due to "qcom_rx_wakelock" wakelocks has been fixed.
Previous releases:
Releases for 20220903:
Latest changes from LineageOS, including the 20220805 Android security updates.
Some things that appeared that are only relevant for devices with mobile networking (such as the baseband version and SIM status sections in About tablet in settings) no longer appear.
The ZRAM size has been increased to 2GiB, and the swappiness is now set to 100.
A higher frequency (1246MHz, was 902MHz previously) is now set for the interactive CPU governors "hispeed_freq" value - This improves responsiveness slightly.
The sepolicy containing device-specific SELinux rules has been improved slightly.
Yet more miscellaneous cleanups have been done.
Some updates from the 4.9 Android common kernel have been applied to the kernel.
Releases for 20220803:
Latest changes from LineageOS, including the 20220705 Android security updates.
Some updates from the 4.9 Android common kernel have been applied to the kernel.
Releases for 20220628:
Latest changes from LineageOS, including the 20220605 Android security updates.
Many updates from the 4.9 Android common kernel, and some from a few other sources, have been applied to the kernel.
Releases for 20220526:
Latest changes from LineageOS, including the 20220505 Android security updates.
The problem where enabling the "Enable on-screen nav bar" option at Settings -> System -> Buttons caused touchscreen input to be disabled has been fixed.
Native support for IPsec tunnels has been enabled.
Support for Vulkan compute is now declared.
A new custom version of the open source Samsung audio HAL from Lineage's android_hardware_samsung repository is now used, rather than the stock, heavily-patched, proprietary Samsung audio HAL, with some fixes for a problem that made it unusable before where occasionally, audio would get outputted from both the speakers and the headphone jack.
The playback and low-latency capture period sizes have been reduced to 128 in the open source audio HAL, which reduces audio latency.
Pro audio support is now declared, since with the reduced period sizes, as well as with the use of the open source audio HAL, round-trip audio latency has been reduced enough for it.
Many updates from the 4.9 Android common kernel have been applied to the kernel.
Several fixes to the Sony HID driver in the 4.9 Android common kernel have been ported over to the kernel - Sony DualShock 4 controllers should now work properly.
Releases for 20220423:
Latest updates from Lineage, including the 20220405 Android security updates.
The tablet product characteristic has been added back after being mistakenly removed - Places where the device was referred to as a phone (such as the "About phone" section in settings) will now refer to it as a tablet again.
Some small improvements from my fixes for LineageOS 19.1 have been applied to the sepolicy containing the SELinux rules.
Some other miscellaneous cleanups have been done.
A few updates from the 4.9 Android common kernel and Samsung's A600FNXXU9CVB1 kernel sources have been applied to the kernel.
Releases for 20220325:
Latest updates from Lineage, including the 20220305 Android security updates.
The previously used 32-bit GPS blobs have been replaced with 64-bit blobs from Samsung's A810SKSS2CTI1 firmware.
The XTRA servers for Assisted GPS have been switched to the servers used in Samsung's stock firmwares - This fixes Assisted GPS, which turned out to actually not appear to work with the previous XTRA servers.
Even more small miscellaneous cleanups have been done.
There are some updates from the 4.9 Android common kernel to the kernel.
Releases for 20220224:
Latest updates from Lineage, including an increase of the Android security patch level to 20220205 (just an increase as interestingly, for this month, there aren't any (relevant) security updates).
The WiFi firmwares have been updated from Samsung's T395XXSDCVA1 firmware.
There are some final updates from the 4.4 Android common kernel (which is unfortunately now also discontinued along with Linux v4.4) and some updates from the 4.9 Android common kernel to the kernel.
[SM-P580/gtanotexlwifi only] Touch input and input from the back and recent apps keys is now ignored when the S-Pen is in use. (Thanks to @unknowwiiplayer for testing the changes for this)
Releases for 20220122:
Latest updates from Lineage, including the 20220105 Android security updates.
There are some updates from the 4.4 Android common kernel to the kernel.
Some changes have been applied to a few drivers specifically for Android in the kernel (mainly the binder driver) from the 4.19 Android common kernel for Q.
A few changes from the 3.18 Android common kernel that were missing from the kernel have been applied.
Releases for 20211222:
Latest updates from Lineage, including the 20211205 Android security updates.
There are some updates from the 4.4 Android common kernel to the kernel.
Releases for 20211114:
Latest updates from Lineage, including the 20211105 Android security updates.
The WiFi driver has been switched from being a kernel module to being built into the kernel. This may improve reliability for enabling and disabling WiFi and the WiFi hotspot very slightly.
The libexynoscamera3.so library has been updated from Samsung's P580ZSS1CTI1 stock firmware - This improves the situation with the issues with stretched/squashed camera previews for images and stretching/squashing in videos at some resolutions.
The MFC (Multi-Format Codec) firmware has been updated from Samsung's A305FDDU6CUI3 firmware.
As the oldest proprietary blobs are now as in Samsung's P580ZSS1CTI1 stock firmware (with a few exceptions), the vendor security patch level has been increased to 2020-09-01, which is the security patch level that firmware has.
Configuration files for media codecs and profiles have been updated from Samsung's T580XXS5CTK1 stock firmware.
Most SELinux rules that are technically not allowed (by neverallow rules) have been replaced with much better rules or removed.
There are some (final) updates from the (unfortunately now deprecated so no longer updated) 3.18 Android common kernel, some updates from Linux 4.4, and a few updates from Samsung's J600FPUUACUH2 and A720SKSU5CUJ2 kernel sources to the kernel.
Releases for 20211023:
Latest updates from Lineage, including the 20211001 Android security updates, and a fix for the issue where the media controls in the notification panel squash the quick settings tiles and make it impossible to swipe through them when in landscape.
Workarounds for an issue with rebooting to recovery and download mode from system using the advanced restart menu or the reboot command in a shell have been replaced with a proper fix.
Yet further slight miscellaneous cleanups have been done.
[SM-P580/gtanotexlwifi only] A problem where S-Pen input wasn't registering in the right directions in orientations other than portrait, as the axes for it didn't change on orientation changes accordingly, has been fixed by enabling orientation awareness for it (Thanks to @retiredtab for sharing that fix).
[SM-P580/gtanotexlwifi only] The cursor that appeared when using the S-Pen has effectively been disabled by setting the device type for the S-Pen input to a touchscreen (Thanks to @Acatzin for the hint for this).
[SM-T580/gtaxlwifi only] The system image size has been increased from 3072000000 bytes to 3145728000 bytes, which is the size of the system partition on Korean and Chinese variant T580s and T585s, and the smallest system partition size out of all T580s and T585s.
[SM-P580/gtanotexlwifi only] The system image size has been decreased from 3072000000 bytes to 3045064704 bytes, to accomodate for the SM-P583s system partition which has that size. With this change, it should now be possible to install this latest build for the P580 on the P583 and for it to boot fine, since the P583 basically seems to be a P580 but for China, although I can't be certain on that.
There are some updates from the 3.18 Android common kernel and Linux 4.4 to the kernel.
Releases for 20210922:
Latest updates from Lineage, including the 20210905 Android security updates.
The ZRAM size has been increased to 768MiB.
Even further miscellaneous cleanups have been done.
The 32-bit wcnss_filter binary, used for Bluetooth, that was used previously has been replaced with the 64-bit wcnss_filter binary from Samsung's A520FZTU4BRB1 firmware.
There are some updates from the 3.18 and 4.4 Android common kernels and Linux 4.4, a few changes backported from mainline Linux, and also a few other insignificant changes to the kernel.
An issue where there was additional extremely quiet high-pitched noise from the right speaker has been fixed. (Thanks to @Kostareka for reporting it. It likely would've gone unnoticed for at least a very long time into the future otherwise.)
First proper release for the P580.
Release for 20210810:
Latest updates from Lineage, including the 20210805 Android security updates.
This is my first build that is signed using my own release keys. This change was removed in the second build released for 20210810 (with "-R2-Test-keys" in the filename).
The BSP sources have been redone to closely match what has been done with the new exynos7880-specific part of Lineage's BSP sources, and with that, there are now more exynos7870-specific changes to the open source gralloc that is in use.
Some further small miscellaneous cleanups have been done.
There are some updates from the 3.18 Android common kernel and Linux 4.4 to the kernel, and a few other insignificant changes.
Release for 20210709:
Latest updates from LineageOS.
Merges of the latest changes from AOSP for repositories forked by Lineage have been picked to skip the wait for them to be merged (repopick -t android-11.0.0_r39), and the rest of the repositories not forked by Lineage were additionally switched to the android-11.0.0_r39 tag, for the 20210705 Android security updates.
A patch to the PermissionController app has been applied that adds the FAKE_PACKAGE_SIGNATURE permission group to it - The signature spoofing permission can now be managed through the permission management interface at Settings -> Privacy -> Permission manager.
The audio outputted from the audio jack while playing media will now be noticeably louder, as the headset "DAC1 playback volume" for media has been increased to the maximum of 175 from 162.
There are some updates from the 3.18 Android common kernel and Linux 4.4 to the kernel.
A few patches have been applied to the qcacld-2.0 WiFi driver in the kernel, which are mainly vulnerability fixes.
Release for 20210617:
Latest updates from LineageOS, including the 20210605 Android security updates.
The WiFi and Bluetooth firmwares have been updated from Samsung's A720SKSU5CTL2 firmware.
The qcom_cfg.ini configuration file for WiFi has been imported from Samsung's A720SKSU5CTL2 firmware - A change within it appears to have made WiFi more reliable.
The sensors.universal7870.so library has been updated from Samsung's stock P580ZSS1CTI1 firmware.
The health HAL has been upgraded to version 2.1.
There are a few other small miscellaneous changes (mostly small cleanups).
There are many updates from the 3.18 Android common kernel and Linux 4.4 to the kernel.
Some unnecessary drivers have been disabled in the kernel.
The sdfat driver in the kernel, which is used for exFAT filesystem support, has been updated to version 2.4.5.
A few changes have been imported to the MMC block device driver in the kernel from Samsung's M105GDXS6CUD4 kernel that fix extremely rare kernel panics that occurred when there was an error with a MMC device (mainly with SD cards).
The fix for an issue where the duration of videos that are taken is lengthened by the time spent in deep sleep/suspended that was previously used has been replaced with a better fix in the Exynos fimc-is2 driver in the kernel.
Release for 20210508:
Latest updates from LineageOS, including the 20210505 Android security updates.
New SELinux denials with Android 11 have been addressed, and with that, SELinux is now set to enforcing by default, and the sepolicy, which contains the SELinux rules, has been rewritten almost entirely, and is now of much better quality.
Some changes have been imported to libbt-vendor from https://github.com/LineageOS/android_hardware_qcom_bt on branch lineage-18.1-caf.
BPF offloading for tethering has been disabled.
The audio HAL has been upgraded to version 6.0.
The rampatch_tlv_tf_1.1.tlv firmware for Bluetooth has been updated from Samsung's stock T585XXS6CTJ7 firmware.
There are some updates from the 3.18 Android common kernel and Linux 4.4 to the kernel.
Some tcp_info-related patches have been applied to the kernel, and with that, a workaround, a patch titled "TcpSocketTracker: Opt-out for TCP info parsing on legacy kernels", is no longer used since it's no longer necessary.
A workaround that was used to get USB tethering and Bluetooth tethering to work is no longer used, and has been replaced with a proper fix (enabling CONFIG_NETFILTER_XT_TARGET_CT in the kernel).
Release for 20210407 (My initial 18.1 build. This changelog continues on from @followmsi's last 18.1 build that was intended for use by users):
Latest changes from LineageOS. The crashes that occurred when setting a new wallpaper that were discussed earlier in this thread appear to have been fixed.
Merges of the latest changes from AOSP, including the 20210405 security updates, have been picked to skip the wait for them to be merged. (repopick -t android-11.0.0_r34)
The same workaround that was used on 17.1 to get USB tethering and Bluetooth internet access sharing to work has been forward-ported and applied.
vintf manifest override enforcement is now enabled.
The vendor/lib[64]/egl/libGLES_mali.so blobs are now symlinked to vendor/lib[64]/vulkan.exynos5.so, rather than copied to vendor/lib[64]/hw/vulkan.exynos5.so - This is a proper fix for Vulkan support.
RSA key verification for ADB is enabled again, and ADB isn't enabled by default and on boot anymore.
There are some updates from the 3.18 Android common kernel and Linux 4.4 to the kernel.
Known issues and workarounds (if any):
Issue 1: Occasionally, when trying to select quick settings tiles in the notification panel, it will crash to the lockscreen.
I have no idea about this issue. It seems like some type of generic systemui crashes. But regardless, it doesn't exist under Android 12 which I've moved onto, and it's here to stay for 11 unfortunately.
Issue 2: Camera previews for images to be taken at resolutions with aspect ratios other than 16:9 using the rear camera are squashed from 16:9 (while final saved images at any resolution are unaffected by any squashing), and videos taken at some resolutions are affected by similar issues with squashing in previews, and, in a smaller set of resolutions, also in final saved video files. (Note that these issues don't affect the front-facing camera)
Somewhat of a workaround to issue 2: Use resolutions at which there are no issues with squashing from 16:9.
To report further issues, get a log from logcat and dmesg. If you're unsure on how to get either, there's good documentation out there for how to do so.
Sources:
A manifest containing all of the necessary repositories to make a build for either the T580 or P580 is in this repository on branch lineage-18.1: https://github.com/TALUAtGitHub/gtaxlwifi-manifests
Thanks to:
@Valera1978 - for all of the previous work for the T580 (and T585) long ago, and for providing his old BSP sources without which the previously used open BSP sources wouldn't have been possible.
@followmsi - for fixes to various issues and other improvements, for useful information, and for working with me on much of this stuff.
Anyone who has previously tested anything new I've put up for testing, reported results, and gave details for me to get it working if it was necessary.
The Lineage team - for the Android distribution itself.
...and everyone else who has worked on anything that is in use.
Just installed it on a device that was still running stock. Works flawlessly, thanks!
Can I get md5 checksum?
ar0177417 said:
Can I get md5 checksum?
Click to expand...
Click to collapse
It's 382e0ae70a956deec826c6867cf80614 for lineage-18.1-20210508-UNOFFICIAL-gtaxlwifi.zip. Anything wrong?
I have a problem with connectivity since April I only get 2mb / s per second when I pay for one 20mbps
This problem is only in android 11 when I go back to some android 10 ROM there is no problem
there are the results of bliss roms
Thank you for your (and @followmsi 's) ongoing support for this device!
My T-580 never felt old to me because of you!
A couple of observations:
TALUAtXDA said:
Issue 3: the on-screen navigation bar feature that can be enabled with the option at Settings -> System -> Buttons -> "Enable on-screen nav bar" doesn't work properly.
Click to expand...
Click to collapse
-onscreen navigation bar works for me, just the "disable hardware buttons" part does not.
For workaround I use Srgrusso's patch from here.
-Safetynet fails where it hadn't before. (no biggie for me, just a thing I noticed)
Great rom!
I flashed this + Flame Gapps and Magisk 22.1.
The first custom rom for this device where Ableton Link works!!
Hi @TALUAtXDA and thanks for your your work ,and the other behind the release
My needs are very basic, I just need something stable, no need for root, sd-card storag etc..
Would this be the preferred ROM? Or is the 17x release a better for my needs?
Regarding Gapps, I noticed that users are using Flame Gapps and NikGapps, but I guess the regular Open Gapps could be an option as well.
What is the recommended Gapps variant?
Kind regards Erik
Issue 4: Adoptable storage (probably) doesn't work.
Somewhat of a workaround to issue 4: format and use your micro SD card with the exFAT filesystem (and a MBR parition table).
Click to expand...
Click to collapse
Anyone else check this yet? It's working for me on @TALUAtXDA's previous version (202010407). I use this feature quite a bit as internal storage is too small, don't want to lose it if I dirty flash this version.
autorage said:
-onscreen navigation bar works for me, just the "disable hardware buttons" part does not.
For workaround I use Srgrusso's patch from here.
Click to expand...
Click to collapse
I'm referring specifically to the "Enable on-screen nav bar" option at Settings -> System -> Buttons, that doesn't require any system-level changes as made by that package that you've linked. When enabling it, no touch input is accepted anymore for some reason. It needs to be locked and unlocked a few times for it to accept input and the on-screen navbar added through that feature to work temporarily.
autorage said:
-Safetynet fails where it hadn't before. (no biggie for me, just a thing I noticed)
Click to expand...
Click to collapse
I have no idea about this. I'd have thought that it's now more likely to pass.
n0j0e said:
The first custom rom for this device where Ableton Link works!!
Click to expand...
Click to collapse
Hmm, wow.... I didn't expect that to be fixed in this release. That's great. :)
gechu said:
My needs are very basic, I just need something stable, no need for root, sd-card storag etc..
Would this be the preferred ROM? Or is the 17x release a better for my needs?
Regarding Gapps, I noticed that users are using Flame Gapps and NikGapps, but I guess the regular Open Gapps could be an option as well.
What is the recommended Gapps variant?
Click to expand...
Click to collapse
For stability, 17.1 would be slightly better. With 18.1, there are certain occasional crashes (see issue 1) that I'm not sure about at the moment, which you may or may not be able to tolerate.
As for Google apps, it's whichever is the smallest variant. For nikgapps, that would be core, and for opengapps, that would be pico. Something to note is that opengapps seems to often be more problematic for Android 11 than other google app packages, so it could be better to go for something else.
jrollf said:
Anyone else check this yet? It's working for me on @TALUAtXDA's previous version (202010407). I use this feature quite a bit as internal storage is too small, don't want to lose it if I dirty flash this version.
Click to expand...
Click to collapse
I actually didn't know if adoptable storage was working in my previous release. I just assumed it didn't considering that it never worked properly with 17.1. Knowing that it did in my previous release of 18.1, it would probably(?) also work with my latest release.
autorage said:
[...]
-Safetynet fails where it hadn't before. (no biggie for me, just a thing I noticed)
Click to expand...
Click to collapse
With NikGAPPS core, SafetyNet passes succesfully in my case.
jrollf said:
Anyone else check this yet? It's working for me on @TALUAtXDA's previous version (202010407). I use this feature quite a bit as internal storage is too small, don't want to lose it if I dirty flash this version.
Click to expand...
Click to collapse
I actually didn't know if adoptable storage was working in my previous release. I just assumed it didn't considering that it never worked properly with 17.1. Knowing that it did in my previous release of 18.1, it will probably(?) also work with my latest release.
Click to expand...
Click to collapse
Ok, I just dirty flashed it, SD as Internal Storage seems to still be working. Thanks!
jrollf said:
Ok, I just dirty flashed it, SD as Internal Storage seems to still be working. Thanks!
Click to expand...
Click to collapse
Alright, thanks for the information. I've removed that from the list of issues. You're welcome.
One more question, does this rom impact supported widevine level?
Had similar question about safetynet, which at least one user claimed worked using NikGAPPS core. Anyway else with experience related to safetynet?
gechu said:
One more question, does this rom impact supported widevine level?
Click to expand...
Click to collapse
The widevine security level is L3, and always will be L3.
Found an issue: system recovery doesn't get overwritten when installing lineage-18.1-20210508-UNOFFICIAL-gtaxlwifi.zip. Might be related with SELinux.
Lumito said:
Found an issue: system recovery doesn't get overwritten when installing lineage-18.1-20210508-UNOFFICIAL-gtaxlwifi.zip. Might be related with SELinux.
Click to expand...
Click to collapse
Wouldn't that be what you would want so that you don't lose TWRP? We've specifically disabled that feature by setting the "persist.vendor.recovery_update" property to "false" since we don't want to use Lineage's recovery.
Maybe, it makes sense. TWRP is more powerful, and faster when installing updates.
TALUAtXDA said:
It's 382e0ae70a956deec826c6867cf80614 for lineage-18.1-20210508-UNOFFICIAL-gtaxlwifi.zip. Anything
Click to expand...
Click to collapse
The downloaded build was corrupted
I downloaded it again. Now it is working fine
Anyways, Thank you for such a great rom
n0j0e said:
Great rom!
I flashed this + Flame Gapps and Magisk 22.1.
The first custom rom for this device where Ableton Link works!!
Click to expand...
Click to collapse
..ok i rushed to fast. Ableton Link didn't sync correctly!
My guess there is something broken or missing in the LOS network stack or WiFi driver for the SM-T580 (gtaxlwifi).
I have an OnePlus 5T with LOS 18.1 (crDroid 7.6) and all apps with Ableton Link are in sync and stable over WiFi.
Here my message from planet-h.com forum:
Hi,
i have a Samsung Tablet SM-T580 WiFi and tried nearly every A10/A11 custom ROM, mostly LineageOS.
I can connect with other devices without trouble but if i start play in G-Stomper the sequencer LED's are flashing absolutely crazy and beats are rumbled.
Same with RemixLive but Snap from Reactable runs rock solid with Ableton Link!
Tried all audio drivers with various latency settings.
Tried switch some network options in the Developer options.
Tried various Devices with WiFi Hotspot or with Wifi AP.
Nothing helped. G-Stomper products & RemixLive connects but didn't sync correctly. Snap plays absolutely stable.
No Firewall, no custom DNS, no AdAway.