Porting to Samsung Galaxy Note 4 SM-N910P
-
@tigerpro Should be like that. However, I have only just started looking into this repo stuff and mobile phone development so I'm in an just as early age as you in this area.
I think there are a lot of spot on skilled people around here, who would know exactly what should be added if they just read this thread. I have compiled other Linux source, though, so I have experience with error messages like yours.
-
@hans1977se Yea, I had more errors but I managed to resolve those on my own with a little research, I'm thinking just comment out the offending lines, try make again and see where I end up. Worse case I get another error from the same file, best case it compiles and everything just works. I doubt the latter and I expect the errors when trying to port to an unsupported device like the note 4, but with some luck I'll get there eventually
-
@tigerpro Yes, you can probably give that a go, and hopfully that code is not run.
-
@hans1977se Thats my hope, if it still fails I'll dig deeper
-
So commenting out those 2 lines got me a little further, then I had the same error with hwc_mdpcomp.CPP at lines 507 and 622, from what I can see it doesn't like the variable "dirtyrec" for some reason, its still compiling so I'll let ya know the outcome when it finishes
== Update ==
I kept commenting out the lines with dirtyrec, ended up generating 20 errors before make gave up. I'm gonna try the generic arm v7a build and see what happens, if it compiles then its gotta be something in the Samsung trltespr repos which is beyond my current skill set, if anyone can code and wants to help investigate the errors please let me know.
== Update 2 ==
Generic arm build failed as well ... Not sure where to go from here but I'm thinking try the 4.4.2 build and see if I get any luck with that for my phone, I managed to get the generic arm on that code to build but I wanted to try for latest version. I guess an old version is better than no version for starters, I will update how that goes as well and if it compiles and runs I'll release the .IMG files for people to test. I'll keep the ubports 5.1 code that I have now, but I can't do much without knowing how to really code. I'm still willing to let people help me out with any coding that needs to be done. I'll also post the error logs if anyone wants them just to give a starting point. On a side note, could we get the [code] tag to keep the spammage down with posting logs?
== Update 3 ==
The 4.4.2 repos just kept giving me a "can't find make file" error when I selected my device after typing "lunch" so I'm gonna try my luck with the 6.x repos and if that fails, I'll try the ubports again, and see if I can figure out the issues.
== Update 4 ==
So I couldnt get either 4.x or 6.x to compile, so I am back to ubports 5.1, this time I changed my tactic of commenting out lines to defining "DirtyRect" as a variable with a "#Define" statement. I have managed to get passed the Dirty Rect errors by doing that however I am now stuck with an error Im not sure how to correct, the pertinent parts of the log follow:
"
frameworks/native/services/surfaceflinger/DisplayHardware/HWComposer.cpp:386:44: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
if (currentConfig < 0 || currentConfig > (numConfigs-1)) {
~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
frameworks/native/services/surfaceflinger/DisplayHardware/HWComposer.cpp:1200:34: error: allocating an object of abstract class type 'android::HWCLayerVersion1'
return LayerListIterator(new HWCLayerVersion1(mHwc, disp.list->hwLayers), index);
^
frameworks/native/services/surfaceflinger/DisplayHardware/HWComposer.h:190:22: note: unimplemented pure virtual method 'setDirtyRect' in 'HWCLayerVersion1'
virtual void setDirtyRect(const Rect& dirtyRect) = 0;
^
frameworks/native/services/surfaceflinger/DisplayHardware/HWComposer.cpp:1333:43: error: no member named 'dirtyRect' in 'hwc_layer_1'
l.dirtyRect.left, l.dirtyRect.top, l.dirtyRect.right, l.dirtyRect.bottom,
~ ^
frameworks/native/services/surfaceflinger/DisplayHardware/HWComposer.cpp:1346:43: error: no member named 'dirtyRect' in 'hwc_layer_1'
l.dirtyRect.left, l.dirtyRect.top, l.dirtyRect.right, l.dirtyRect.bottom,
~ ^
frameworks/native/services/surfaceflinger/DisplayHardware/HWComposer.cpp:1533:25: error: no member named 'dirtyRect' in 'hwc_layer_1'
dr = Rect(l.dirtyRect.left, l.dirtyRect.top, l.dirtyRect.right,
~ ^
frameworks/native/services/surfaceflinger/DisplayHardware/HWComposer.cpp:1020:20: error: allocating an object of abstract class type 'android::HWCLayerVersion1'
return new CONCRETE( static_cast<const CONCRETE&>(*this) );
^
frameworks/native/services/surfaceflinger/DisplayHardware/HWComposer.cpp:1036:11: note: in instantiation of member function 'android::Iterable<android::HWCLayerVersion1, hwc_layer_1>::dup' requested here
: Iterable<HWCLayerVersion1, hwc_layer_1_t>(layer), mHwc(hwc) { }
^
1 warning and 5 errors generated.
make: *** [/home/tyg3rpro/phablet/out/target/product/trltespr/obj/SHARED_LIBRARIES/libsurfaceflinger_intermediates/DisplayHardware/HWComposer.o] Error 1
"I have no idea where to go from here, as Im not familiar with coding as much as Id like. I am hoping that someone on the forums here can possibly shed some light on the error and guide me in the right direction to attempt a fix?
Thanks in advance.
-
bump so that hopefully someone with a better skillset than I will see this thread
-
Let's take a step back. I would suggest
- Try the following alternative attempt at fixing the "dirtyrec" story: Instead of taking it out in all places it complains, ensure it is enabled in those places where it seems it was not enabled.
- undo ALL code changes wrt dirtyrec you did
make clean- export CFLAGS="$CFLAGS -D QCOM_BSP" (something like this, I haven't tested it)
- rebuild
- If that doesn't work, I'd almost say delete everything and instead of cm-12.1, try to go down the halium-7.1 / lineageos 14.1 route: https://github.com/Halium/docs/blob/master/porting/index.md
- If that doesn't work, try building ONLY cm / lineage first, don't attempt to directly make a UT port, but instead make sure your build env, settings, etc allows you to recreate this. and only after you have your selfbuilt cm/lineage RUNNING on your device go back to UT.
- Try the following alternative attempt at fixing the "dirtyrec" story: Instead of taking it out in all places it complains, ensure it is enabled in those places where it seems it was not enabled.
-
@doniks looking through the lineage repo, it doesnt look like my device is an official device, the repo from what I can tell only goes to cm13, but I do understand what your suggesting. Make sure DirtyRect is enabled everywhere, try make again, if I give up or just cant get code ro compile try a different repo and see if that works. I think Ill have to just try building cm/lineage for my device and to from there, I have a suspicion that will compile fine cause the errors Im seeing according to the default.xml file are from the ubports repo of android_hardware_qcom_display-caf and the note 4 uses the apq8084 as a display chip so ... yea ... kinda need to figure out whats going on to move forward with ubports. If I het cm to compile then I may have to switch to the cm display-caf to get moving again. A whole OS is definately harder to port than to compile, thats for sure.
-
@tigerpro said in Porting to Samsung Galaxy Note 4 SM-N910P:
@doniks looking through the lineage repo, it doesnt look like my device is an official device, the repo from what I can tell only goes to cm13,
Ah ok. Maybe there is some other android port. What about this:
https://forum.xda-developers.com/note-4-tmobile/development/rom-cmremix-rom-v2-5-12-23-14-t2981479
https://github.com/CMRemix?utf8=✓&tab=repositories&q=trlte&type=&language=
but I do understand what your suggesting. Make sure DirtyRect is enabled everywhere, try make again, if I give up or just cant get code ro compile try a different repo and see if that works. I think Ill have to just try building cm/lineage for my device and to from there, I have a suspicion that will compile fine cause the errors Im seeing according to the default.xml file are from the ubports repo of android_hardware_qcom_display-caf
That's probably it indeed! I remotely remember some conversation about ubports vs caf somewhere. But I can't find it.
@mariogrip , @bshah do you guys have any advice for the good man here?
-
@doniks thank you for the links, I checked those repos for my device and they only go to 13 as well. I have put this on the back burner before I get the urge to grab my biggest heaviest hammer, and teach this system to fly (prob why I never became a full fledged coder) I will keep checking in here and try solutions that are offered (or get whatever info is needed) though. I am also learning to code in my spare time as well, so that eventually I might understand whats supposed to be happening with this DirtyRect better than the comments in the cpp files.
-
So an update, I decided to coetely delete everything and repo sync again, Im back to the original error I got when it was compiling with the dirtyRect errors, Im doing research to see if I can figure anything out, but so far nothing of major note, aside from a old ubuntu touch git repo for galaxy phones, Im trying to get that to sync with my local manifest, but no luck so far, Ill keep trying and if it works Ill post again, if not Ill update this one with the errors and likely start working towards Halium.
-
@tigerpro said in Porting to Samsung Galaxy Note 4 SM-N910P:
a old ubuntu touch git repo for galaxy phones
links?
-
@doniks its just the display-caf, media-caf, and audio-caf portions, and I have yet to get my system to actually retrieve them, but heres the link
https://github.com/Ubuntu-Touch-GalaxyS?tab=repositories
So far the dirtyRect issue Im running into seems to be just with ubports version of display-caf, none of the other repos Ive looked at seem to have any mention of it which makes things a little more complicated for me, but who knows, if I can get this repo to download the files maybe it will actually compile for once, Ill try again when I get home, I also made a thread on XDA-Developers, hoping someone else is trying this or even has an idea on how to progress through, only time will tell.
#=== Edit ===#
I took a crack at porting Halium, I get the same dirtyRect error there as I do with ubports, I am starting to wonder if the dirtyRect is something linux based, which would explain why I havent seen it in any Android repos. I also havent seen anything for qcom's *-caf repos that goes over cm 11 on android which is just adding to my confusion at this point. There is a wip repo that I came across but that doesnt have dirtyRect in it either. So at this point Im just confused about the whole qcom *-caf repos in general. I am gonna try just manually adding the galaxy repos I came across, but I dont expect much to happen with that as its for the phablet 4.4.2 r1 build (which I understand to be deprecaded now) Im all ears if anyone can either help me make heads or tails of the caf repos or has anything I can try to get the code to fully compile. Thanks
#=== Edit 2 ===#
So I manually copied the display-caf repo I came across for galaxy phones, no luck there either. Guess Im going back to the drawing board with dirtyRect and display-caf, I did manage to get the nexus 4 version from the old cannocal guide to compile, however I dont own a nexus 4 so I cant try it to see if it works. I at least know I can compile the nexus 4 version, now I should try it with ubports and see if I het similar results to old porting guide, that at least will narrow down my issue regardless of result.
-
So I have made progress, I managed to find an un-official lineageOS repo for my phone, using that and a little trial and error I managed to get Halium to compile. I follow the halium porting guide, but when I get to the part that tells me to run the halium-install script, I keep getting an error saying that it "cant write 217 blocks, out of space?" Or something along those lines, not in front of my computer atm, I decided to ignore that error just to see if the kernel at least boots (TWRP warns theres no OS if I reboot at this point) and to my shock and amazment, after a couple mins I could actually follow the debug info and telnet in. I had to change a couple things in the kernel config according to diagnosis.log and init.log which Ive done already, but still get that space error when I run halium-install. Anyone out there run into this? If so, tips to tey and move from a working kernel to at least a working gui?
-
@tigerpro said in Porting to Samsung Galaxy Note 4 SM-N910P:
So I have made progress, I managed to find an un-official lineageOS repo for my phone, using that and a little trial and error I managed to get Halium to compile.
Niice! Which version?
I follow the halium porting guide, but when I get to the part that tells me to run the halium-install script, I keep getting an error saying that it "cant write 217 blocks, out of space?" Or something along those lines, not in front of my computer atm,
I remember there was another ubports forum conversation about a similar error message. Something about partition size settings ... I can't remember whether it was actually resolved, but see whether you can find that. Maybe it helps.
EDIT: found it
https://forums.ubports.com/topic/481/porting-to-motorola-moto-g-2013-lte
It seems it was related to the filesystem it was being built on. Weird! -
@doniks I got Halium 7.1 to build, 5.1 kept giving me the dirtyRect error so I decided against trying to compile that. I actually just found the thread you linked, google is such a pain cause it keeps searching for helium despite me typing halium. I checked the respective files on my system, I did like you had mentioned in that post and deleted the same file and ran make systemimage gave me a file that matches the size of my boardconfig.mk size. I will try flashing again when I get home, ssh can only do soo much when your not in front of the computer your sshed too lol
-
@tigerpro said in Porting to Samsung Galaxy Note 4 SM-N910P:
google is such a pain cause it keeps searching for helium
You could give the alternatives a go.
This one is quite good:
https://duckduckgo.com/ -
@hans1977se yea I just usually default to google cause its what I use, duckduckgo is my fallback, someday I wont have to google Halium errors anymore lol
-
@tigerpro yeah i know, i'm far worse with habits than i think i should be.
-
@hans1977se arent we all? I am gonna keep searching if this flash attempt fails, I have a feeling my issue might be halium-install trying to copy the image to the wrong partition cause I tried flashing it with TWRP just out of curiosity, and it says the image is bigger than the partition (which explains the out of space) and TWRP only offers boot or recovery when I select the file, but since I just recompiled the system image it might have resolved itself, wont know until I get home to try it