Database Users

[Q] Question about the need for sources...

Hey guys,
As a software developer myself I feel a bit embarrassed that I need to ask this, but I really can't think of the answer myself. Here goes:
Why do we always need the latest sources from Samsung to be able to build an AOSP rom?
The way I see it, unless the kernel's internal APIs that Samsung's device drivers use have changed dramatically between, say, Froyo and Gingerbread, wouldn't it be possible to simply check out AOSP, paste the driver source files from Froyo into the appropriate folder in the kernel tree, and compile? Even if the kernel's internal APIs have changed a bit, they would be minor and well documented changes, so it should only be a moderately difficult task to fix the Froyo sources to work with Gingerbread. Sure, the drivers would still be "Froyo quality," but they seem to work pretty well to me. I'd be happy with a Gingerbread AOSP build w/ Froyo drivers.
It's kind of like what VMWare's tools do in a Linux guest OS - if you update your distro's kernel, the ABI is broken and you just recompile the modules. Same VMWare source code, different kernel, but it works.

[Q] developing a linux native honeyhybrid.

I am currently in the process of developing a game-centric honeylinux hybrid. I have currently managed to get several linux-native operations working on android, including a dedicated game server. My question is this, is it worth my effort to continue this project now or should I wait for ICS and spend my efforts there? I would then release my recooked native honeycomb/linux mod as a non updated effort. Here is what I have done so far:
Installed full bash#
Installed manual tweaks to the ntegra api thru linux
Have a custom desktop screen based off suse, no more scrolling side screens.(option at boot which gui you would like to use)
Stable hybrid honeyvillan 3.4+ w/suse memory integration controller 17% faster ddr3 (you can set ram voltage but with cpu so high you really shouldnt try to get more than 20%)
Every game app avaliable that supports a500+ all ntegra games pre-installed
OC voltage @ 1.5 per core effective 3.0 ghz
Scripts I have toyed with:
Eggdrop successfully running
Ircd server runs
Irc runs
Wine is a work in progress, slowly getting it day by day, remote desktop works.
Several old game servers work
All android apps run, and more effeciently.
My development path was going to take me through emulating graphical apis that the ntegra could handle allowing all linux native games to be playable through a gl wrapper.
So what do you guys think? Pause development and release source for current project? Or do i wait till ICS is out to release a fully functional stable version? Keep in mind that I am working on this project soley because it amuses me and with the hardware is possible. If waiting for ICS and tegra 3 would be a better solution I dont know
Posted from my a500 oc @ 3ghz ddr3 speed 17% boost. Taboonay 2.2 Honeyvillan 2.4+ custom with ntegra fixes. 17890 cf-bench, 9000 antutu. Custom named n-Game OS v 1.2.3b.

note suse kernal is based on opensuse arm kernal.
Reserved for notes

You cant run x86 on an arm processor. Wine Is Not an Emulator. Just so you don't waste your time.
Id say make a git repo so we can check it out, yes.

GamezR2EZ said:
You cant run x86 on an arm processor. Wine Is Not an Emulator. Just so you don't waste your time.
Id say make a git repo so we can check it out, yes.
Click to expand...
Click to collapse
I thought wine allowed you to run a partitioned windows, meaning if i partitioned an arm windows installation (have access to several builds) it should work should it not? Also rumor is the ics 4.0 sdk will be in our (developer) hands by as early as next weekend. I want to make sure things will be completely compatible via a single flash if I am to release the current build, and understand theree will be no support, unless I come out with an update before ICS. I can make a one click app to install it or custom bootable image depending on what is needed but it may take me a few days to get the logistics down on doing that, and understand as a gamer intended rom, the rom comes preloaded with nearly 6gb of data. I can have the data for apks removed but rom size will still be nearly 1gb, so be prepared for a large rom. I will update this thread as more opinions are posted, will work on a full revision list and screenshots, and getting the files on my private server. I am currently waiting for a custom boot image, once I have th at everything sh ould be good to go.
Please note the opensuse implementations work, but be aware of limitations while running in the desktop mode. These include the ability to not be able touse some widgets that were designed specifically for android, you can switch back to the normal android screens tru a reboot of the device.
I will also make availiable the kernal source so for those of you interested in furthering the project you can.
Edit info on my background: linux developer for 8 years for an undisclosed company. Helped develop linux compatible drivers, learning andriod in the hopes of creating a hybrid open source alternative suited more towards pure gamers, and business apps.
Thanks for your response,
Posted from my a500 oc @ 3ghz ddr3 speed 17% boost. Taboonay 2.2 Honeyvillan 2.4+ custom with ntegra fixes. 17890 cf-bench, 9000 antutu. Custom named n-Game OS v 1.2.3b.

As wine goes, yes what you are saying is correct. But that doesn't mean the programs compiled for the x86 processor will work. Being that is, all apps currently available will not work. Any ARM app compiled for Windows 8 could work. Im sure it will moving forward. But that means no current windows games will run.

Release a one click app and let me test/play XD
Sent from my A500

GamezR2EZ said:
As wine goes, yes what you are saying is correct. But that doesn't mean the programs compiled for the x86 processor will work. Being that is, all apps currently available will not work. Any ARM app compiled for Windows 8 could work. Im sure it will moving forward. But that means no current windows games will run.
Click to expand...
Click to collapse
Added some thanks for that. I was imagining windows 8 to have some work around, but t heir games will have to be built from the ground p. For all intensive purposes I could do it for the sake of Microsoft Office, but that is still coming along. Guess it would save space as well not bothering with windows integration at this point. Thanks again.
Posted from my a500 oc @ 3ghz ddr3 speed 17% boost. Taboonay 2.2 Honeyvillan 2.4+ custom with ntegra fixes. 17890 cf-bench, 9000 antutu. Custom named n-Game OS v 1.2.3b.

nrnx said:
I thought wine allowed you to run a partitioned windows, meaning if i partitioned an arm windows installation (have access to several builds) it should work should it not?
Click to expand...
Click to collapse
You have access to an ARM build of Windows 8?

FloatingFatMan said:
You have access to an ARM build of Windows 8?
Click to expand...
Click to collapse
Yes
Posted from my a500 oc @ 3ghz ddr3 speed 17% boost. Taboony 2.2 Honeyvillan 2.4+ custom with ntegra fixes. 17890 cf-bench, 9000 antutu. Custom named n-Game OS v 1.2.3b.

nrnx said:
Yes
Posted from my a500 oc @ 3ghz ddr3 speed 17% boost. Taboony 2.2 Honeyvillan 2.4+ custom with ntegra fixes. 17890 cf-bench, 9000 antutu. Custom named n-Game OS v 1.2.3b.
Click to expand...
Click to collapse
Prove it. Leak it!

FloatingFatMan said:
Prove it. Leak it!
Click to expand...
Click to collapse
I want to believe he has it to, but I am unsure as well because in his sig it says he has his Iconia overclocked to 3.0ghz.... seems a bit of an exaggeration. But I tend to stay away from pointless arguments on the internet. Don't feed the trolls, eh?
@nrnx
Any kind of release would be appreciated. Talk is cheap, but most of us are devs, we can handle bleeding edge releases.

GamezR2EZ said:
I want to believe he has it to, but I am unsure as well because in his sig it says he has his Iconia overclocked to 3.0ghz.... seems a bit of an exaggeration. But I tend to stay away from pointless arguments on the internet. Don't feed the trolls, eh?
@nrnx
Any kind of release would be appreciated. Talk is cheap, but most of us are devs, we can handle bleeding edge releases.
Click to expand...
Click to collapse
Working on it now... cannot up w8arm, as am under nda. Perhaps once the system goes live.

[kernel]Cyanogen working on 3.0 kernel for xperia 2011 line

can someone update .597 kernel here is source
https://github.com/kamarush/semc-kernel-msm7x30-3.0.8
https://github.com/nexx/htc-kernel-msm7x30
also cyanogen start porting 3.0 kernel for msm7x30
http://pocketnow.com/android/cyanogen-porting-linux-30-kernel-to-msm7x30-phones
thers some sorce i just googleing and found this
ps i alo find this : https://github.com/kamarush/semc-msm-3.4
According to a Google+ post (what are we going to call those? Geeps?) Cyanogen himself is working on porting the Linux 3.0 kernel to Android-powered devices running on the msm7x30 chipset.
According to the post “All the subsystem changes from 2.6.35 to 3.0 are super tedious, especially sound.”
What does the 3.0 kernel include?
First of all, it does NOT include any “special scary new features” and “there’s absolutely no reason to aim for the traditional ‘.0′ problems that so many projects have”.
Instead the release includes the “usual two thirds driver changes, and a lot of random fixes” and “some nice VFS cleanups, various VM fixes, some nice initial ARM consolidation (yay!)”.
According to Linus himself, “in general this is supposed to be a fairly normal release cycle”.
So, with no much fanfare, the 3.0 kernel was released, and with the backing of one of the Android greats, it’s coming to smartphones soon.
Click to expand...
Click to collapse

[Kernel][P73XX] A1 Kernel V1.9

Before you do anything: I will not be held responsible for anything bad that happens to your tablet.
Disclaimer: I do not own this device.
**Sources: Check the GT10.1 A1 kernel thread for beginner friendly V1.9 sources.
Compatibility Information: Check the file names for -stock or -cm for the appropriate version. There is no harm in using a 3G kernel on a WiFi only tablet. This makes the build process less messy. I have a WiFi only tablet and I have no problems with it.
Changelog
Voodoo sound added <-- new to V1.0
USB charging automatically enabled <-- new to V1.1
1.2GHz OC <-- new to V1.2
GPU OC'd from 333MHz to 400MHz <-- new to V1.3
1.4GHz OC <-- new to V1.4
Charging widget support, various bug fixes, cifs with utf8 somewhere along the line <--new to V1.5.9
Attempted support for GT8.9 with 1.5GHz and 1.6GHz OC <-- new to V1.6alpha
Enabled XBox controller as xpad.ko kernel module <-- new to V1.6.1
NTFS moved to kernel module instead of built in, CIFS moved to kernel module instead of built in, enabled option.ko and usb_wwan.ko for connection of 3G dongle, all nls charsets/codepages built as modules <--new to V1.6.2
Applied git patch to disable mmc_cap_erase <-- new to V1.6.4
Voltage control, cifs built in again. <--new to V1.7
Changed battery driver to p3_battery.c originally specified by samsung instead of p4_battery.c that the GT10.1 uses <--new to V1.7.1
Cyanogenmod charging mode fix (incompatible with stock rom)
Rebased on P7300_HK Sources <-- new to V1.7.3
attempted CM10 compatibility fix based on GT10.1, enabled Samsung's powersaver governor, GT10.1 450MHz cap fix <--new to V1.7.4b (based on GT10.1 sources for now since I can test all those changes. Maybe I accidentally messed up something in GT8.9 sources??)
Copied in pershoot keyboard driver for CM <--new to V1.7.5
801MB RAM available <-- new to V1.8
Rebased on pershoot's sources as of November 17 11pm EST <--new to V1.8.1
Back to samsung GT10.1 base, follow pershoot's suggestion of Nexus7 mtp drivers to fix mtp, enabled zRam <--new to V1.8.2
Reduced RAM to 785MB to account for intense 3D games, enabled KSM (check settings --> performance --> memory management), reappearance of stock versions
Rebased stock rom kernel on GT10.1 sources. <--new to v1.8.3b (stock version only)
Rebased on 7300_update1 ics sources <--new to V1.8.3c stock versions only
Fixed charging while off bug. (You can now turn your tablet off for the night and charge it), enabled userspace human interface device management for CM10.1 <--new to V1.8.4 (CM only)
V1.8.5, 1.8.6 GT10.1 specific
Added row scheduler from CM10.1 I9300 sources <--new to V1.8.7
Added XDA's grzwolf's hsic wakelock fix <--new to V1.8.8
Added frandom kernel module from GT10.1 request <--new to V1.9
See my GT10.1 thread for more info.

AAccount said:
Before you do anything: I will not be held responsible for anything bad that happens to your tablet.
Where the name comes from: This kernel is named after the imaginary character A1. A1 was a character of my creation who was powerful, thought on his feet in battles and drove an electrically powered flying SUV. In my signature is his original hand drawn logo that I drew ~10 years ago, scanned, and used gimp to touch up.
I got a request to port this kernel to the galaxy tab 8.9. Only today, did I realize that the GT8.9 sources are included in the GT10.1 sources I downloaded. Very minimal changes needed to be made to make it GT8.9 compatible. However, I do not own this device and cannot afford a second tablet (even wifi only). I tried my best to follow the same steps used to create the GT10.1 version for the GT8.9. Since I have not even booted this kernel yet, it is marked pre alpha. Feedback is much appreciated. I am compiling this kernel in good faith. You will need to flash back the stock kernel and copy in the files from a stock rom's /system/lib/modules to get back to stock. I recommend you have a stock kernel on hand ready to flash from recovery just in case...
**Sources: look for the corresponding A1 thread the the GT10.1 section. Nothing has changed at all except the .config which is directly modelled after the GT10.1 .config.
Changelog
Voodoo sound added <-- new to V1.0
USB charging automatically enabled <-- new to V1.1
1.2GHz OC <-- new to V1.2
GPU OC'd from 333MHz to 400MHz <-- new to V1.3
1.4GHz OC <-- new to V1.4
Charging widget support, various bug fixes, cifs with utf8 somewhere along the line <--new to V1.5.9
Attempted support for GT8.9 with 1.5GHz and 1.6GHz OC <-- new to V1.6alpha
See my GT10.1 thread for more info. Only missing features from GT10.1 version is the boot script support and CM versions. I'd prefer to take it 1 step at a time.
Click to expand...
Click to collapse
Hi...
I am on Overcome now, and wondering if this can be applied on my P7300 ?
If so, should I just flash it over the CWM ?
Please advice.
Thank you.

andikasaja said:
Hi...
I am on Overcome now, and wondering if this can be applied on my P7300 ?
If so, should I just flash it over the CWM ?
Please advice.
Thank you.
Click to expand...
Click to collapse
You need to be running a stock ice cream sandwich rom (Android 4.0). I think overcome rom is honeycomb (Android 3.2). Also remember this is an alpha kernel.

Seems to work fine. I'll play with it for a while before making up my mind about it.
Thanks for doing this for the 8.9.

AAccount said:
You need to be running a stock ice cream sandwich rom (Android 4.0). I think overcome rom is honeycomb (Android 3.2). Also remember this is an alpha kernel.
Click to expand...
Click to collapse
Thank you for the confirmation.
I also thought so, as it was mentioned as [Stock ICS].
Cheers...

Stupid question time! I looked at the notes on the 10.1 kernel thread, and didn't see it, but does this kernel have the game pad (usb xbox controller) support built in? I know the factory one doesnt see my controller.

bluefalcon13 said:
Stupid question time! I looked at the notes on the 10.1 kernel thread, and didn't see it, but does this kernel have the game pad (usb xbox controller) support built in? I know the factory one doesnt see my controller.
Click to expand...
Click to collapse
No it doesn't, but I'll look into it. I've looked into it. Should be included in the next version but first... I want to get feedback on the current port before releasing new versions.

Thanks mate for the built, seems to work properly, do you need some specific test,benchmarks or stuffs like that?

Thank you AAcount for porting it, will test it soon.

Kernel works very well, let's hope it improve the battery life.
Gesendet von meinem GT-P7300 mit Tapatalk 2

ceno80Under volt1 said:
Kernel works very well, let's hope it improve the battery life.
Gesendet von meinem GT-P7300 mit Tapatalk 2
Click to expand...
Click to collapse
For That we need UnderVolt, hope it will be added in next releases

you are the man
i want to thank you for this kernel voodoo support is important to me because the tab is my car stereo. flashed havent had any issues yet. if you want to add uv support thumbs up ill give it a try. thanks for taking the time to compile even though u dont have a 8.9!

just flashed this on my tab and i can report that all is working just as expected! OCd to 1.4Ghz and noticeably smoother!
really like it!
Thanks a lot for taking the time to port this for us!
A few requests for future versions:
Other Shedulers. On my razr I'm using pegasusq which is great for battery life. when the phone is asleep it shuts down one of the two cores completely! hotplug & hotplugx also do this. not sure if the galaxy tab supports something like that but it would be great!
Undervolting. moar batterrrryyyy arrrrgh
Thanks once again!
did some more testing. youtube HD videos now have a slight lag and hickups that were absent on the stock kernel.

Great ! Thanks a bunch. I will give it a try this evening.
Any chance we get a zip with the stock kernel, in case something goes wrong ?

Good idea. Please put an original kernel zip file.
Wysyłane z mojego GT-P7300 za pomocą Tapatalk 2

Just done some benchmark, no oc, but I didn't have stock kernel results to compare yet... 2d test seems very bad, I don't know if it sucks with stock one as well

chemicalbuz said:
Just done some benchmark, no oc, but I didn't have stock kernel results to compare yet... 2d test seems very bad, I don't know if it sucks with stock one as well
Click to expand...
Click to collapse
Did you force 2D gpu rendering in the developpers settings ?
I will benchmark too, before & after the update.

AAccount said:
No it doesn't, but I'll look into it. I've looked into it. Should be included in the next version but first... I want to get feedback on the current port before releasing new versions.
Click to expand...
Click to collapse
Awesome, thanks. Saw this thread as I was headed to bed last night. I'll do a nandroid and install to give it a whirl after work. If there are any issues, I know the controller worked under the Galaxian Soup pre-ics kernel, think it was motley's V3, not 100% on the kernel name.

Any chance using this kernel in JB ports ?

This kernel have support for running scripts in /etc/init.d ? (because _motley's lack it).

Android Oreo 8.0 / Lineage 15.0 Dev Discussion

Currently on hold due to working on Nougat first.
I've got a booting or should I say bootlooping build of Lineage 15.0 for I9000. (galaxysmtd)
I've had to use crazy hacks like adb binary from 7.1 in ramdisk.
Just to get `adb logcat` working.
For now it's stuck at bootlogo. I've attached the logcat here.
I'm looking into it to figure out what needs to be done.
Sources:
manifests and patches I've used.
https://github.com/galaxys1-resurrected/local_manifests
https://github.com/galaxys1-resurrected/android_patches
Kernel:
https://github.com/galaxys1-resurrected/android_kernel_samsung_aries
Device Tree:
https://github.com/galaxys1-resurrected/android_device_samsung_aries-common
https://github.com/galaxys1-resurrected/android_device_samsung_galaxysmtd
Thanks:
@rINanDO for backporting kernel side of things to 3.0
@xc-racer99 and @Coldwindofnowhere for getting the device upto android 7.1
And all others who had worked from beginning till now on this device.

Is there anyone still working on this?
I was curious if anyone this was still being developed? I'm totally newbie in the android scene but have some knowledge of operating systems and am interested in resurrecting my i9000.
I went through the logs and a couple of things jumped out:
1) Surface flinger returning non zero exit status because it needs OpenGL ES v2.0 or greater. I believe i9000's GPU PowerVR SGX540 supports OpenGL ES 2.0, so this issue could be solved.
2) Media extractor crash: /system/bin/mediaextractor: libminijail[1291]: prctl(PR_SET_NO_NEW_PRIVS): Invalid argument, whatever the heck it means.
3) activity_recognition HAL is deprecated, so ActivityRecognitionHardware class's init does not do anything.
For 3 , I got to android_hardware_location_ActivityRecognitionHardware.cpp's source where it comments out activity_recognition.h with the following comment:
Code:
// #include <hardware/activity_recognition.h>
// The activity recognition HAL is being deprecated. This means -
// i) Android framework code shall not depend on activity recognition
// being provided through the activity_recognition.h interface.
// ii) activity recognition HAL will not be binderized as the other HALs.
I believe more work has been done since this post based on git commits lasting upto Nov'17. Would be great if someone could post logs for an updated build. I feel that android oreo with go optimizations would be a really good fit for i9000 and uphold this device's legendary support. I mean a device running from eclair all the way to oreo would be amazing.
Even if this might not work out, I would like to thank @(°_o), @xc-racer99 , @Coldwindofnowhere and @rINanDO for bringing i9000 upto nougat. I believe even i9000's nexus sibling nexus s does not have a working nougat rom.

a1shakes said:
I was curious if anyone this was still being developed? I'm totally newbie in the android scene but have some knowledge of operating systems and am interested in resurrecting my i9000.
I went through the logs and a couple of things jumped out:
1) Surface flinger returning non zero exit status because it needs OpenGL ES v2.0 or greater. I believe i9000's GPU PowerVR SGX540 supports OpenGL ES 2.0, so this issue could be solved.
2) Media extractor crash: /system/bin/mediaextractor: libminijail[1291]: prctl(PR_SET_NO_NEW_PRIVS): Invalid argument, whatever the heck it means.
3) activity_recognition HAL is deprecated, so ActivityRecognitionHardware class's init does not do anything.
For 3 , I got to android_hardware_location_ActivityRecognitionHardware.cpp's source where it comments out activity_recognition.h with the following comment:
Code:
// #include <hardware/activity_recognition.h>
// The activity recognition HAL is being deprecated. This means -
// i) Android framework code shall not depend on activity recognition
// being provided through the activity_recognition.h interface.
// ii) activity recognition HAL will not be binderized as the other HALs.
I believe more work has been done since this post based on git commits lasting upto Nov'17. Would be great if someone could post logs for an updated build. I feel that android oreo with go optimizations would be a really good fit for i9000 and uphold this device's legendary support. I mean a device running from eclair all the way to oreo would be amazing.
Even if this might not work out, I would like to thank @(°_o), @xc-racer99 , @Coldwindofnowhere and @rINanDO for bringing i9000 upto nougat. I believe even i9000's nexus sibling nexus s does not have a working nougat rom.
Click to expand...
Click to collapse
Unfortunately, no one is really actively working on Oreo. As you've found out, it's an issue with the graphics drivers that is holding everything back. No device (that I've found) that uses a PowerVR graphics chip (we use the PowerVR SGX 540) has working graphics drivers on Oreo. There were rumours that someone had found newer working blobs, but weren't able to release them publicly due to intellectual property laws that they were trying to figure out (but this was months ago).
Our GPU does support sufficient enough OpenGL, but only using BGRA8888 as opposed to RGBA8888. BGRA hasn't officially been supported in Android since ~4.2, but there's been a hack used to make things work. Come Oreo, things have changed and the hack no longer applies cleanly. However, I think the really issue is that the gralloc blobs was extended by PowerVR (see https://github.com/xc-racer99/andro...6.0/exynos3/s5pc110/include/hal_public.h#L119) but with the binderized HALs/VNDK/other low-level Oreo changes something has broken. I had a go at trying to work around things, but failed too.
There are a few ways I can think of getting working graphics:
1) Someone finds some updated blobs for the PowerVR SGX 540 for ARM (I've found x86 ones, but they don't work for obvious reasons)
2) Someone hacks around the source code so that the blobs work - but I'm not sure if it's PowerVR "extension" of the gralloc interface that is causing issues or not...
3) We simply use software rendering, but this would be so slow with our ancient CPU that I haven't bothered to try
4) We work on porting a newer kernel so we have the Samsung DRM kernel driver, use the Linux PowerVR blobs coupled with drm_gralloc/drm_hwcomposer and maybe a wrapper like https://github.com/TexasInstruments/dri3wsegl and somehow cobble together working support
In terms of the mediaextractor crash, that's due to the kernel missing seccomp support. There's a whole bunch of different backports, some more successful than others. Due to our ancient kernel, backporting is no longer very easy...
If we could somehow get the graphics drivers working, we'd have a pretty good base as there are free implementations of all HALs/drivers except for GPS and TV-Out (and, of course, graphics....).

Are you really working on porting oreo on the i9000?
How do you deal with the small amount of ram?
Are you using the 'low end device' oreo feature?

nailyk said:
Are you really working on porting oreo on the i9000?
How do you deal with the small amount of ram?
Are you using the 'low end device' oreo feature?
Click to expand...
Click to collapse
No, no one (that I know of) is actively working on Oreo for the first-gen Galaxy S devices. There were attempts, the kernel got in good enough shape that everything wasn't immediately crashing, but due to the graphics driver issues described a couple posts ago nobody has managed to get a fully booting build.

xc-racer99 said:
No, no one (that I know of) is actively working on Oreo for the first-gen Galaxy S devices. There were attempts, the kernel got in good enough shape that everything wasn't immediately crashing, but due to the graphics driver issues described a couple posts ago nobody has managed to get a fully booting build.
Click to expand...
Click to collapse
Thanks for fast anwser. Yes, the graphic driver problem exist on another of my exynos device.
Anyway I wasn't able to boot the 7.1 (not able to boot something else than 2.3.6 )
Will attempt to see that post you are talking about but am probably not smart enough to deal with graphics drivers
Thanks for your time.

nailyk said:
Thanks for fast anwser. Yes, the graphic driver problem exist on another of my exynos device.
Anyway I wasn't able to boot the 7.1 (not able to boot something else than 2.3.6 )
Will attempt to see that post you are talking about but am probably not smart enough to deal with graphics drivers
Thanks for your time.
Click to expand...
Click to collapse
If you're serious about trying to mess with graphics drivers, it might be interesting to check out the blobs from https://www.renesas.com/pt-br/produ...ion-boards/renesas-starter-kit-for-rzg1e.html as it's an ARM-based device with the SGX540. It's possible that they're new enough to not run into the same issues as the older blobs (but equally possible that even the kernel part is closed source). The binary blobs are only semi-SoC specific as I've managed to use the OMAP blobs with only having hardware decoding being broken.

Is it for real???
I9000 !!

Apparently, some new SGX540 and SGX544 DDK blobs for OMAP4 have appeared:
https://gerrit.unlegacy-android.org/#/c/Unlegacy-Android/proprietary_vendor_ti/+/10525/
https://gerrit.unlegacy-android.org/#/q/topic:omap-ddk-1.14+(status:open+OR+status:merged
In fact, (Barnes and Noble's) hummingburd and ovation are both based on SGX544 and have gotten an Oreo ROM (using the new blobs).
https://forum.xda-developers.com/showpost.php?p=77526206&postcount=2490

Use android go it will be better.

MYEUHD said:
Apparently, some new SGX540 and SGX544 DDK blobs for OMAP4 have appeared:
https://gerrit.unlegacy-android.org/#/c/Unlegacy-Android/proprietary_vendor_ti/+/10525/
https://gerrit.unlegacy-android.org/#/q/topic:omap-ddk-1.14+(status:open+OR+status:merged
In fact, (Barnes and Noble's) hummingburd and ovation are both based on SGX544 and have gotten an Oreo ROM (using the new blobs).
https://forum.xda-developers.com/showpost.php?p=77526206&postcount=2490
Click to expand...
Click to collapse
Yep, I've seen the blobs, they've been there for awhile now. Just haven't had a chance to run a build with the blobs to see if they work. It's on my to-do list when I find the time

xc-racer99 said:
Yep, I've seen the blobs, they've been there for awhile now. Just haven't had a chance to run a build with the blobs to see if they work. It's on my to-do list when I find the time
Click to expand...
Click to collapse
Alright, I've had a chance to look at the blobs now. I have a build, but unfortunately it looks as if we need to adjust our hwcomposer as well We use a relatively old hwc 1.0 but the new gralloc blob doesn't appear to keep the framebuffer open which is a requirement for a hwcomposer this old. There is a prebuilt blob that is used by omap4 devices but it doesn't work on s5pc110 due to the fact that it uses some DSS stuff which is OMAP-specific. Still plenty of work to do, without even trying to figure out all the Oreo/Pie changes (I'm testing on KitKat as that's the build environment I have setup right now).

xc-racer99 said:
Alright, I've had a chance to look at the blobs now. I have a build, but unfortunately it looks as if we need to adjust our hwcomposer as well We use a relatively old hwc 1.0 but the new gralloc blob doesn't appear to keep the framebuffer open which is a requirement for a hwcomposer this old. There is a prebuilt blob that is used by omap4 devices but it doesn't work on s5pc110 due to the fact that it uses some DSS stuff which is OMAP-specific. Still plenty of work to do, without even trying to figure out all the Oreo/Pie changes (I'm testing on KitKat as that's the build environment I have setup right now).
Click to expand...
Click to collapse
We need a newer hwc anyway, as Pie requires at least hwc 1.3:
ChronoMonochrome said:
In 9.0, to get graphics to work, device is required to support HWC2 (or use either HWC2on1 or HWC2onFb adapters).
Click to expand...
Click to collapse
ChronoMonochrome said:
Yes, HWC has to be at least 1.3, to work with one of aforementioned adapters. With one of those adapters it will work like it was HWC 2 (but actually not exactly same).
Click to expand...
Click to collapse
As a reference, the galaxy S3's hwc was updated from 1.0 to 1.4: Thread
hardware/samsung

MYEUHD said:
We need a newer hwc anyway, as Pie requires at least hwc 1.3:
As a reference, the galaxy S3's hwc was updated from 1.0 to 1.4: Thread
hardware/samsung
Click to expand...
Click to collapse
Was unaware of the fact. Are you volunteering to make the patches?
I've uploaded my changes to https://github.com/xc-racer99/proprietary_vendor_samsung/tree/ddk-1.14 https://github.com/xc-racer99/android_hardware_samsung/tree/ddk-1.14 https://github.com/xc-racer99/android_kernel_samsung_aries/tree/ddk-1.14 https://github.com/xc-racer99/android_device_samsung_telusgalaxys4gmtd/tree/ddk-1.14 https://github.com/xc-racer99/android_device_samsung_aries-common/tree/ddk-1.14 but I think this might be the last I work on this as I don't really have the motivation to work on it anymore. Note the patches are against a custom version of Unlegacy Android 4.4 so you'll need to cherry pick the changes to your ROM of choice if desired.
The changes build, the EGL appears to initialize, but I always get
Code:
E/libEGL ( 471): validate_display:254 error 3008 (EGL_BAD_DISPLAY)
And in dmesg:
Code:
[ 8.509291] init: computing context for service '/system/vendor/bin/pvrsrvinit'
[ 8.509601] init: starting 'pvrsrvinit'
...
[ 8.601890] PVR_K: UM DDK-(4081762) and KM DDK-(4081762) match. [ OK ]
...
[ 8.765955] init: process 'pvrsrvinit', pid 99 exited
...
[ 55.560021] PVR_K:(Error): PVRSyncIOCTLCreate: Failed to find unused fd (-24)
[ 55.563491] PVR_K:(Error): PVRSyncIOCTLCreate: Failed to find unused fd (-24)
[ 55.597577] s3cfb s3cfb: [fb0] video memory released
Whether the issue is in the HWC or the gralloc blob that we've stolen from OMAP, I have no idea.

xc-racer99 said:
Was unaware of the fact. Are you volunteering to make the patches?
Click to expand...
Click to collapse
Will try to do my best!
BTW, do I really need jdk-7 to compile kitkat? or does it simply work with jdk-8??

MYEUHD said:
Will try to do my best!
BTW, do I really need jdk-7 to compile kitkat? or does it simply work with jdk-8??
Click to expand...
Click to collapse
You really do need jdk-7... I used the "reference implementation" available at http://jdk.java.net/java-se-ri/7 and made sure the java executables were in the PATH before the java I actually have installed.
Note that my Unlegacy Android trees will not work for the i9000 (well, they might, but you'd need to install u-boot as well at a bare minimum...)

It's kinda Insane that people are trying to get an 8 year phone to run oreo

@xc-racer99 Do you still have the AOSP 7.1 source code on your computer?

MYEUHD said:
@xc-racer99 Do you still have the AOSP 7.1 source code on your computer?
Click to expand...
Click to collapse
I've got the .repo folder, but don't have the individual files expanded as I don't have the disk space Could run a repo sync and look at things but don't have the disk space for a full build.

The_Pacific_gamer said:
It's kinda Insane that people are trying to get an 8 year phone to run oreo
Click to expand...
Click to collapse
its kinda insane that people are still using this phone.