Porting to Samsung Galaxy Note 4 SM-N910P

doniks · 8 Dec 2017, 17:36

@tigerpro WHAT gives that error?

Edit: Oh, make does. mhhhh.
post your manifest

tigerpro · 12 Aug 2017, 17:50

heres my samsung_trltespr.xml manifest file thus far.

<?xml version="1.0" encoding="UTF-8"?>
<manifest>

</manifest>

please let me know if I am missing anything.

thank you for the help so far.

doniks · 12 Aug 2017, 18:57

Well, for starters, don't expect too much from me I'm also just stumbling in the dark. But let me go stumble a bit ...

I assume you did this
repo init -u https://github.com/ubports/android -b ubp-5.1
as pointed out here: https://wiki.ubports.com/wiki/Setting-up-Your-Tree-for-CM12.1-Devices

which means, you are using this default manifest:
https://github.com/ubports/android/blob/ubp-5.1/default.xml

the error you post seems to be in
hardware/qcom/display-caf/apq8084/libhwcomposer/hwc_utils.cpp:1213:29:

which, if I understand it correctly is from here:
https://github.com/ubports/android/blob/ubp-5.1/default.xml#L143

which is here
https://github.com/ubports/android_hardware_qcom_display/blob/cm-12.1-caf-8084/libhwcomposer/hwc_utils.cpp#L1213

which has an ifdef QCOM_BSP around it and is talking about the type hwc_layer_1_t which I cgrep in my locally checked out tree to be in :
./hardware/libhardware/include/hardware/hwcomposer.h

which in turn, looking back at
https://github.com/ubports/android/blob/ubp-5.1/default.xml#L132

is here:
https://github.com/ubports/android_hardware_libhardware/blob/cm-12.1/include/hardware/hwcomposer.h#L221

and indeed is again surrounded by QCOM_BSP

aaaaand, uhm, now I honestly don't know further ... does any of that give you any idea? Or is there someone else reading along?

I mean, I guess you could comment out the two lines 1213 and 1214. It will get you past this specific error, but I wouldn't be surprised if it bites you later on. hwcomposer is part of the machinery that get's pixels on your screen. I guess if no smarter suggestion comes up, you could comment it now and postpone that particular headache until later ....

tigerpro · 12 Aug 2017, 19:19

@doniks if I understand what your saying correctly, it sounds like the display server is having issues compiling. I'll try commenting those 2 lines out if no better suggestions come up, but having nothing on the screen would kinda defeat the purpose of having a screen in the first place, I suppose its possible the android source in my trlte-common repo could have a display server but I'm not gonna hold my breath. I'll keep an eye on here for a few more hours then I'll try commenting out those 2 lines and see what happens. I had a feeling it was something more than just a missing repo. Thank You for the input.

doniks · 12 Aug 2017, 20:00

@tigerpro said in Porting to Samsung Galaxy Note 4 SM-N910P:

@doniks if I understand what your saying correctly, it sounds like the display server

I don't think it's exactly the display server, but then I also don't really know what it is But that name comes up with displaying stuff

is having issues compiling. I'll try commenting those 2 lines out if no better suggestions come up, but having nothing on the screen would kinda defeat the purpose of having a screen in the first place,

haha. totally! I'm suggesting it because a) it might just work anyway, who knows, deal with the problems one at a time and b) even if there is a critical problem here, it buys you some time waiting for smarter comments or insights and maybe also later on you may get a more useful error message making it easier to solve ...

I suppose its possible the android source in my trlte-common repo could have a display server but I'm not gonna hold my breath.

Well, uhm, no the way I understand it. hwcomposer HAS to work. But so far we have no conclusive proof that won't work ... so again, one step at a time

I'll keep an eye on here for a few more hours then I'll try commenting out those 2 lines and see what happens.

I had a feeling it was something more than just a missing repo. Thank You for the input.

that reminds me - looking at your manifest again. How did you put it together? I read the instructions on the ubports wiki to say:

take that stuff from here https://github.com/CyanogenMod/android_device_samsung_trltespr/blob/cm-12.1/cm.dependencies

and then, I guess we're supposed to follow the cm.dependencies files recursively. When I do that, I end up with :

android_device_samsung_trltespr
- android_device_samsung_trlte-common
  - android_device_qcom_common
  - android_device_samsung_qcom-common
    - android_hardware_samsung
  - android_kernel_samsung_trlte

But you have these two in addition: android_device_qcom_sepolicy android_device_generic_goldfish

tigerpro · 12 Aug 2017, 20:05

@doniks that's the result of a couple errors that make failed at, I added those two repos and it seemed to solve it. They could be unneeded, but if it gets the make process further then no harm in trying it at least, there's also one repo that's not listed there cause its not part of CM so I just manually downloaded it and put it in its respective folder, the repo is for the cm12.1 blobs as my note 4 is currently running cm 13

hans1977se · 12 Aug 2017, 22:10

@tigerpro My guess is that is the problem. The version you downloaded is probably not compatible with the rest of the code base.

tigerpro · 12 Aug 2017, 22:52

@hans1977se all my downloaded code is for cm12.1 though, isn't that what ubports uses? The blobs are from a 12.1 ROM its the muppets repo on git

hans1977se · 13 Aug 2017, 05:44

@tigerpro yes, I think they use 12.1, but I thought you meant you have a mix between 12.1 and 13. Anyway, I think it could be worth double checking that you got the right version.

tigerpro · 13 Aug 2017, 08:49

@hans1977se Out of curiosity is there a way to just add that repo to my manifest so I don't have to manually get the files? I tried using "git fetch" but it said it couldn't find the repo, and I'll double check the version on the blobs, is there anything else I could try if it is the right version?

hans1977se · 13 Aug 2017, 14:57

@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.

tigerpro · 13 Aug 2017, 15:12

@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

hans1977se · 13 Aug 2017, 15:18

@tigerpro Yes, you can probably give that a go, and hopfully that code is not run.

tigerpro · 13 Aug 2017, 16:53

@hans1977se Thats my hope, if it still fails I'll dig deeper

tigerpro · 13 Aug 2017, 20:48

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.

tigerpro · 16 Aug 2017, 21:47

bump so that hopefully someone with a better skillset than I will see this thread

doniks · 17 Aug 2017, 06:12

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.

tigerpro · 18 Aug 2017, 19:08

@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.

doniks · 26 Aug 2017, 08:58

@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?

tigerpro · 26 Aug 2017, 14:51

@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.