Related
bit of a mad idea, but what is stopping us from hacking up our own 3d drivers? im sure a little probing around the instruction set might yeild something partially useful perhaps maybe? *ooh this interupt turns on the imageon chip!11* etc
thoughts?
Don't see why it can't be done, must be someone out there that is up for the challenge
But as this is an new CPU I would thought it would be difficult as there is no previous version with working drivers to work from, would be amazing is someone did it though
Reverse engineering as proved a daunting task even for the resourceful linux development community. for exemple open source (ie non-vendor provided) nvidia and ati drivers are way poorer performers than their vendor provided binary blobs counterparts.
Qualcomm being actively hostile to open their specs, i doubt drivers could be created in a reasonable time frame.
im half inclined to try
maybe this could help you start...
http://forum.xda-developers.com/showpost.php?p=1643361&postcount=32
(qualcomm brew/opengl dlls with source code)
sweet ill give them a look over - i have quite a bit of experience with opengl but not much embedded experience, ill see what i can do, time permitting
edit: mm not so useful really - having lots of trouble finding any info online too - though i think the gfx is Imageon 2388/2380
So, I have a barebones version of MeeGo (barely) running on the Nexus S. I can't really do much with it on my own, but I'm posting the info here so you can build it and try it for yourself.
What works:
• ADB root shell
• X11 & UI apps
• Super-AMOLED brightness control (fixed! still off-colour tho…)
What doesn't work currently:
• Touchscreen
• WiFi
• Anything else
If you've never built a MeeGo rootfs before, it's relatively straightforward, and all the binaries are precompiled for you (but it's definitely for developers only).
I have my boot.img (kernel + ramdisk) and a MeeGo kickstart file at http://blog.steventroughtonsmith.com/2011/01/nexus-s-meego.html ; you can use fastboot to boot the image, or flash it to the recovery partition to dual boot. The actual MeeGo rootfs is run from a rootfs.ext2 file you can drop onto the Nexus S using Mass Storage mode - no need for messy flashing or the like, you can thank me later).
There's not much else I can do on my own right now, so if you want to see anything become of this do get involved!
My kernel is stock git://android.git.kernel.org/kernel/samsung.git ; make herring_defconfig; the only change was modifying the .config to turn on CONFIG_VT (needed for X11).
Go nuts!
Well done on the port so far. This is way beyond my area of expertise, but I do hope that some people can help build off of what you've done so far. Always nice to see what kind of fun stuff we can run on these devices...
Looking forward to more development on this!
Great stuff!
I have been waiting for someone to start something like this, I work as an embedded developer during the day so not much time at night but I will chip in were and if I can, I am pulling the source and looking at the build system / process.
Looks like you have done the heavy lifting of bootstraping the device now its just about porting drivers.
Cheers and great start!
What driver are you using for the X11 and is it accelerated?
ilfccd said:
What driver are you using for the X11 and is it accelerated?
Click to expand...
Click to collapse
It's using unaccelerated graphics; although, with luck, SGX 540 graphics drivers are available for other devices (like the OMAP4) so in theory you may be able to patch those to run.
Update - backlight working; color is still fscked, might be gamma:
According to PowerVR rep on CES there should be an open source driver later this year (info from Phoronix, but they are lately not really reliable source of info).
Here is another question though. Have you tried using the omap tree of linaro for the kernel build?
I don't have Nexus S around currently and I'm doing all my work on TI OMAP (A8) based IGEP v2 board and TI OMAP 44xx Panda (A9) board. As they both have PowerVR 530/540 graphics I'll check tonight or tomorrow if the closed driver is compatible with linaro's kernel as I'm currently running that on the IGEP. As Samsung is part of linaro, there could be some patchests for the hummingbird in there. The current uname -r for the linaro is: 2.6.35-1008-linaro-omap so it could be compatible w/ MeeGo's kernel, there could be even newer version in the git tree.
Keep up the great work, I'm really interested in what you are doing with MeeGo. Thanks!
ilfccd said:
According to PowerVR rep on CES there should be an open source driver later this year (info from Phoronix, but they are lately not really reliable source of info).
Here is another question though. Have you tried using the omap tree of linaro for the kernel build?
I don't have Nexus S around currently and I'm doing all my work on TI OMAP (A8) based IGEP v2 board and TI OMAP 44xx Panda (A9) board. As they both have PowerVR 530/540 graphics I'll check tonight or tomorrow if the closed driver is compatible with linaro's kernel as I'm currently running that on the IGEP. As Samsung is part of linaro, there could be some patchests for the hummingbird in there. The current uname -r for the linaro is: 2.6.35-1008-linaro-omap so it could be compatible w/ MeeGo's kernel, there could be even newer version in the git tree.
Keep up the great work, I'm really interested in what you are doing with MeeGo. Thanks!
Click to expand...
Click to collapse
I'm not sure how compatible the kernels will be, the Hummingbird is not an OMAP device (and it would be more akin to the OMAP3 than OMAP4); but if the kernel works, then it should work with MeeGo too. MeeGo is relatively versatile.
Graphics drivers would be nice!
I actually use the linaro distro (ubuntu essential, which i hate) to build meego inside it, because of the work the linaro guys did on the gcc compiler (should be better versed for arm chips). according to the wiki here https://wiki.linaro.org/Platform/UserPlatforms/2010-09-13
the drivers for omap3 should be freely accessible (the 530 core). there is a mention of the 540 core in there also, but I haven't really used them as I don't run X on the boards. You could try the PVR 540 driver for the OMAP4, you might be lucky with the build, could be compatible with the one in the hummingbird. If it is, this could potentially be far better than the Nexus and HD2 MeeGo 'ports' .
ilfccd said:
I actually use the linaro distro (ubuntu essential, which i hate) to build meego inside it, because of the work the linaro guys did on the gcc compiler (should be better versed for arm chips). according to the wiki here https://wiki.linaro.org/Platform/UserPlatforms/2010-09-13
the drivers for omap3 should be freely accessible (the 530 core). there is a mention of the 540 core in there also, but I haven't really used them as I don't run X on the boards. You could try the PVR 540 driver for the OMAP4, you might be lucky with the build, could be compatible with the one in the hummingbird. If it is, this could potentially be far better than the Nexus and HD2 MeeGo 'ports' .
Click to expand...
Click to collapse
I'd try the OMAP4 driver if it was easy to get! I can only find instructions for the PandaBoard, and no repo or download links.
I will try too, if I can't locate them myself will ask someone there. First of all I have some urgent IPoIB business to attend to, though. Probably later tonight or sometime tomorrow.
Edit:
I forgot to ask, did you build MeeGo from scratch or only the kernel and used the daily userland from the arm tree?
ilfccd said:
I will try too, if I can't locate them myself will ask someone there. First of all I have some urgent IPoIB business to attend to, though. Probably later tonight or sometime tomorrow.
Edit:
I forgot to ask, did you build MeeGo from scratch or only the kernel and used the daily userland from the arm tree?
Click to expand...
Click to collapse
Prebuilt userland, no compiling required. I always use the daily RPMs (when the repo is working…)
google just released new graphics driver dunno if that will help your screen problems https://groups.google.com/group/android-building/browse_thread/thread/90d5498622a6ea4
As far as I've seen this was the most promising thread about porting meego here..
So I would suggest to just contact the ones who dived deeper into the matter and even made some progress.
Thread: http://forum.xda-developers.com/showthread.php?t=764255
tomqman said:
google just released new graphics driver dunno if that will help your screen problems https://groups.google.com/group/android-building/browse_thread/thread/90d5498622a6ea4
Click to expand...
Click to collapse
Unfortunately the graphics driver they released is specific to Android, and Android's version of libc. I don't believe there's a way to get that running on GNU/Linux or MeeGo :-(
Being the noob I am what is meego?
tominater12 said:
Being the noob I am what is meego?
Click to expand...
Click to collapse
Nokia (and Intel)'s future smartphone/tablet platform. A real Linux distribution designed for mobile devices, entirely new touch based UI, GPU acceleration, multitouch, etc.
Whoever gets this done gets a beer from me I am really excited about meego but I wont be able to buy the n9 because im on contract untill march next year. If you can get this to run on the nexus s than it should run on the sgs too, that way I can use meego wothout buying a new phone Keep it up
tomislavp4 said:
Whoever gets this done gets a beer from me I am really excited about meego but I wont be able to buy the n9 because im on contract untill march next year. If you can get this to run on the nexus s than it should run on the sgs too, that way I can use meego wothout buying a new phone Keep it up
Click to expand...
Click to collapse
Am hoping to have it up and running on the HD2 first, and then hopefully some of the work we do for that will port over to the Nexus S. Can't wait for the N9…
I have found sources on the Google git which look like the generic (non device-specific) Android 3.0 kernel sources and have uploaded them to my git https://github.com/Ezekeel/android-3.0. I guess it might be possible to merge these into current Nexus S kernels (and also kernels for other devices) to get a kernel compatible with ICS. I will try that later on; until then I guess other kernel devs probably also find these interesting and useful.
Ezekeel said:
I have found sources on the Google git which look like the generic (non device-specific) Android 3.0 kernel sources and have uploaded them to my git https://github.com/Ezekeel/android-3.0. I guess it might be possible to merge these into current Nexus S kernels (and also kernels for other devices) to get a kernel compatible with ICS. I will try that later on; until then I guess other kernel devs probably also find these interesting and useful.
Click to expand...
Click to collapse
Yes, thanks Ezekeel, I've been browsing through the tree since minutes ago when you opened it and one thing I noticed at least is that it lacks drivers/video/samsung for Nexus S, dunno more of what is missing from our device specific tree, but it might be possible to make this 3.0 working ye.
Lol Ezekeel, I've seen you praying Jean-Baptiste Queru for the Crespo-tree sources! I Think we have to wait one or two weeks...
franciscofranco said:
Yes, thanks Ezekeel, I've been browsing through the tree since minutes ago when you opened it and one thing I noticed at least is that it lacks drivers/video/samsung for Nexus S, dunno more of what is missing from our device specific tree, but it might be possible to make this 3.0 working ye.
Click to expand...
Click to collapse
Pretty much all the device-specific stuff is missing, but maybe we are lucky and no changes have to be made in the device-specific source for the Nexus S and we can simply keep these parts from our current code.
franciscofranco said:
Yes, thanks Ezekeel, I've been browsing through the tree since minutes ago when you opened it and one thing I noticed at least is that it lacks drivers/video/samsung for Nexus S, dunno more of what is missing from our device specific tree, but it might be possible to make this 3.0 working ye.
Click to expand...
Click to collapse
I'm pretty sure this is known, but in case it's being overlooked. The gpu in the galaxy nexus is the same as in the nexus s, just supposedly higher clocked. so if drivers are available for the galaxy nexus gpu, can't they be made to work with nexus s somehow? or does it make a huge difference cause they are on different SoC's?
Luxferro said:
I'm pretty sure this is known, but in case it's being overlooked. The gpu in the galaxy nexus is the same as in the nexus s, just supposedly higher clocked. so if drivers are available for the galaxy nexus gpu, can't they be made to work with nexus s somehow? or does it make a huge difference cause they are on different SoC's?
Click to expand...
Click to collapse
JBQ said that even if gpu is the same (omap4430) in galaxy nexus and in pandaboard he wasn't able to run the gnexus driver on the pandaboard and vice-versa because of some library-dependencies. So I think the drivers will not work out of the box...
awesome!
so your efforts semi paid off. lets hope the device specific stuff gets released shortly.
Nice to know
simms22 said:
awesome!
so your efforts semi paid off. lets hope the device specific stuff gets released shortly.
Click to expand...
Click to collapse
I expect the date we get proprietary files and the date of the ICS OTA to somehow magically be the same.....
Sent from my Nexus S using XDA App
matt2053 said:
I expect the date we get proprietary files and the date of the ICS OTA to somehow magically be the same.....
Sent from my Nexus S using XDA App
Click to expand...
Click to collapse
You might be right. It might also coincide quite nicely with the Galaxy Nexus release date. I got a funny feeling that it will not be officially available on the Nexus S before it launches on the Galaxy Nexus.
Maximilian Mary said:
You might be right. It might also coincide quite nicely with the Galaxy Nexus release date. I got a funny feeling that it will not be officially available on the Nexus S before it launches on the Galaxy Nexus.
Click to expand...
Click to collapse
In one of the google groups replies JBQ said that they will always focus on the flagship phone.
Up until recently that was Nexus S.
Now the torch was passed and it's Galaxy Nexus first.
They will not dull the luster of their flagship phone by making libs and drivers for released phones available before the flagship phone has had time to shine.
I merged these sources into the android-samsung-2.6.35 source and got 450 merge conflicts that I would have to resolve manually. That would a giant pain in the ass and probably not worth to effort.
Ezekeel said:
I merged these sources into the android-samsung-2.6.35 source and got 450 merge conflicts that I would have to resolve manually. That would a giant pain in the ass and probably not worth to effort.
Click to expand...
Click to collapse
That will be a huge effort to fix, and it would probably cause more harm than good if you managed to fix the conflicts. I'm sure we'll have our sources in one/two weeks tops, so that's not worth the hassle in my opinion.
Ezekeel said:
I merged these sources into the android-samsung-2.6.35 source and got 450 merge conflicts that I would have to resolve manually. That would a giant pain in the ass and probably not worth to effort.
Click to expand...
Click to collapse
Thanks for all the effort on that, and for "reminding" Google to release that source.
I'm going to guess that this wouldn't work out, but would it be possible to try to crowd source this at all? Is it the type of thing that would require a lot of knowledge about the kernel, or would a competent programmer be able to walk his way through the conflicts and resolve them?
dvgrhl said:
Thanks for all the effort on that, and for "reminding" Google to release that source.
I'm going to guess that this wouldn't work out, but would it be possible to try to crowd source this at all? Is it the type of thing that would require a lot of knowledge about the kernel, or would a competent programmer be able to walk his way through the conflicts and resolve them?
Click to expand...
Click to collapse
I guess one could make a community effort to get this done. However it still is not guaranteed that the sources, even if properly merged without errors, will compile, because some device specific updates may be missing. Or some of the proprietary files included also need an update. It just seems like a lot of work for something that potentially never will work - especially since a properly working kernel with everything in place will be released in a few weeks tops.
Ezekeel said:
I guess one could make a community effort to get this done. However it still is not guaranteed that the sources, even if properly merged without errors, will compile, because some device specific updates may be missing. Or some of the proprietary files included also need an update. It just seems like a lot of work for something that potentially never will work - especially since a properly working kernel with everything in place will be released in a few weeks tops.
Click to expand...
Click to collapse
First thanks for opening this thread, is a good idea.
At this moment I will wait some days to see if the crespo kernel 3.0 goes into public git, otherwise I will join the project to move the kenel since it will have multiple benefits.
Kalim
Is it possible to download the complete source code that Sony used when they compiled the ROM for Xperia V. I know where to find the kernel source and of course Android is very easy to get but what about everything else. I'm especially interested in knowing if they made any changes to Android or if they only cluttered the phone with add-ons.
Since Sony did abuse the phone and broke it to badly to make a reinstall possible I'm mainly just interested in getting the sources for my own education and understanding of the system. Perhaps even to try some simple reverse engineering to fix some really absurd settings like NFC not working in lock screen and such before I sell the phone and never ever talk about or to Sony again.
please use search and/or google
http://developer.sonymobile.com/downloads/xperia-open-source-archives/
good luck in your development of this
gregbradley said:
please use search and/or google
...
good luck in your development of this
Click to expand...
Click to collapse
Thank you for at least answering me however, I have goggled a lot about this and the link you posted to the best of my knowledge contains only the kernel source plus a few other system programs that are used on the host side when compiling. I'm honestly quite surprised that the answer to this is not well known. I have also since yesterday tried to find out what branch of android is used but that too seem to be obscured in darkness.
AlgoJerViA said:
Thank you for at least answering me however, I have goggled a lot about this and the link you posted to the best of my knowledge contains only the kernel source plus a few other system programs that are used on the host side when compiling. I'm honestly quite surprised that the answer to this is not well known. I have also since yesterday tried to find out what branch of android is used but that too seem to be obscured in darkness.
Click to expand...
Click to collapse
from what I am aware of those are the full sources used to compile the ROM, not just the kernel.
what do you mean by "What branch of android is used"
gregbradley said:
from what I am aware of those are the full sources used to compile the ROM, not just the kernel.
what do you mean by "What branch of android is used"
Click to expand...
Click to collapse
Well, look at the size. It is about 250MB, about the size of the kernel. The Android source is in the gigabyte range, I also have downloaded and compiled the kernel and the file you download contains a kernel folder and a external folder with the helper programs I mentioned.
Well I can't links since I'm to new here but if you do a search for "Codenames, Tags, and Build Numbers" on Google you will see that there are several branches for each version of Android. But now when I looked closer at that list it just so happens that 4.1.2 only has one branch so you can ignore that question, i was tired yesterday and was looking for 4.1.1 that has more like six branches. Still seems hard to find out what would be the right one in that case.
OK, I see what you want.
I am not sure where to find that info, but there will be some on here that will know.
try PMing championshipswimmer or DooMLoRD
They are busy people, but they may be able to point you in the right direction.
Hello XDA Community,
I am interested in using the unofficial build of CyanogenMod 14.1 available here, but I would like to learn how to compile on my own from the repository provided by the developer. Unfortunately, I do not know how to go about doing this. Could someone please help me out? I have looked at the CyanogenMod Wiki entry for how to compile CyanogenMod for the Nexus 6, but the information is out of date according to what I was told in a post I made on Stack Exchange's Android Q&A site. The only thing that I understand about the build process is that I need to use Linux, so I have set up a virtual machine in VMware running the latest version of Ubuntu. Where do I go from here?
Thank you,
David B.
David B. said:
Hello XDA Community,
I am interested in using the unofficial build of CyanogenMod 14.1 available here, but I would like to learn how to compile on my own from the repository provided by the developer. Unfortunately, I do not know how to go about doing this. Could someone please help me out? I have looked at the CyanogenMod Wiki entry for how to compile CyanogenMod for the Nexus 6, but the information is out of date according to what I was told in a post I made on Stack Exchange's Android Q&A site. The only thing that I understand about the build process is that I need to use Linux, so I have set up a virtual machine in VMware running the latest version of Ubuntu. Where do I go from here?
Thank you,
David B.
Click to expand...
Click to collapse
To be honest You will be better off dual booting. Compiling with a VM normally has more issues then not.
Then I would look at Google developer page.
Also keep in mind that compiling from CM means you get all the bugs they never fixed. You would be better off going with AOSP and then finding the features you want to add and then add them yourself.
zelendel said:
To be honest You will be better off dual booting. Compiling with a VM normally has more issues then not.
Then I would look at Google developer page.
Also keep in mind that compiling from CM means you get all the bugs they never fixed. You would be better off going with AOSP and then finding the features you want to add and then add them yourself.
Click to expand...
Click to collapse
I would love to build my own CyanogenMod based on AOSP and then merge in the features, but I don't even know how to build directly from AOSP.
Honestly, all I really want is stock with all of the additional developer mode features that CyanogenMod has along with root access. I love the ability to use root without extra apps, and wireless ADB is sweet when I'm too lazy to go get my USB cable. And of course, I want to be able to use future versions of Android on my phone even though 7.0.1 is supposed to be the last version for Shamu. Could I somehow merge those aspects together and just pull patches from AOSP, build, and flash?
Also what's wrong with using a VM to compile? I've read that problems occur if you don't have enough RAM allocated to the VM, but I've assigned it 16GB so that should not be a problem. As for attaching my phone to the VM, I am using VMware, which has better support for removable devices than VirtualBox.
I'm sorry if I misunderstand something you said. It's probably obvious, but I know pretty much nothing about what I am doing which means I'm likely to ask lots of questions that seem ridiculous to those that are well-versed in this sort of thing.
David B. said:
I would love to build my own CyanogenMod based on AOSP and then merge in the features, but I don't even know how to build directly from AOSP.
Honestly, all I really want is stock with all of the additional developer mode features that CyanogenMod has along with root access. I love the ability to use root without extra apps, and wireless ADB is sweet when I'm too lazy to go get my USB cable. And of course, I want to be able to use future versions of Android on my phone even though 7.0.1 is supposed to be the last version for Shamu. Could I somehow merge those aspects together and just pull patches from AOSP, build, and flash?
Also what's wrong with using a VM to compile? I've read that problems occur if you don't have enough RAM allocated to the VM, but I've assigned it 16GB so that should not be a problem. As for attaching my phone to the VM, I am using VMware, which has better support for removable devices than VirtualBox.
I'm sorry if I misunderstand something you said. It's probably obvious, but I know pretty much nothing about what I am doing which means I'm likely to ask lots of questions that seem ridiculous to those that are well-versed in this sort of thing.
Click to expand...
Click to collapse
You do know that there is an app for SU built into CM right? So it is no extra apps then any other rom.
Could you yes but it will be lots of work due to what CM changes in the source code. It is one of the many reasons (on top of years old bugs that were never fixed) That many teams stopped using them as a source. The Shamu will be supported by 3rd party developers for a while to come.
Normally ram is an issue but other issues also happen.
I dont know anything about having to attach your device to VM as I have never used VM due to advise from the developers here.
Asking questions is not that big of a deal as long as you do your research. There are tons of TUT on the site about setting up a build setup. Just use the search and spend a few days reading. Mainly where the licenses are concerned. Also commit authorship. Which is you make your own rom it is very important.
zelendel said:
You do know that there is an app for SU built into CM right? So it is no extra apps then any other rom.
Could you yes but it will be lots of work due to what CM changes in the source code. It is one of the many reasons (on top of years old bugs that were never fixed) That many teams stopped using them as a source. The Shamu will be supported by 3rd party developers for a while to come.
Normally ram is an issue but other issues also happen.
I dont know anything about having to attach your device to VM as I have never used VM due to advise from the developers here.
Asking questions is not that big of a deal as long as you do your research. There are tons of TUT on the site about setting up a build setup. Just use the search and spend a few days reading. Mainly where the licenses are concerned. Also commit authorship. Which is you make your own rom it is very important.
Click to expand...
Click to collapse
Okay, so I have done some research and have a solution for how to use root with stock Android, but as soon as stock Android support is dropped from the Nexus 6 I will have to compile it myself which I am not sure how to do and would like to learn. Do you have any suggestions for what to go to learn since everything I am finding is not about compiling, but is instead about using an existing build?
David B. said:
Okay, so I have done some research and have a solution for how to use root with stock Android, but as soon as stock Android support is dropped from the Nexus 6 I will have to compile it myself which I am not sure how to do and would like to learn. Do you have any suggestions for what to go to learn since everything I am finding is not about compiling, but is instead about using an existing build?
Click to expand...
Click to collapse
Here you go
https://source.android.com/source/initializing.html
Mind you getting root is more then adding an app for it. You will also have to do some kernel edits.
zelendel said:
Here you go
https://source.android.com/source/initializing.html
Mind you getting root is more then adding an app for it. You will also have to do some kernel edits.
Click to expand...
Click to collapse
Thanks! I also found this. I have not really looked at it too much yet, but it seems like it has the potential to help me with what I want. Why would I need to make kernel edits? I thought all I needed to do was use TWRP to flash SuperSU after flashing the ROM.
David B. said:
Thanks! I also found this. I have not really looked at it too much yet, but it seems like it has the potential to help me with what I want. Why would I need to make kernel edits? I thought all I needed to do was use TWRP to flash SuperSU after flashing the ROM.
Click to expand...
Click to collapse
SuperSU edits the kernel when you flash it. Most of what allows root is in the kernel.
Yes that is a great resource. Just take your time and read it. You could have a working set up and build in about 2 days (given the first sync of the source code could take more then 24 hours depending on your connection.
zelendel said:
SuperSU edits the kernel when you flash it. Most of what allows root is in the kernel.
Yes that is a great resource. Just take your time and read it. You could have a working set up and build in about 2 days (given the first sync of the source code could take more then 24 hours depending on your connection.
Click to expand...
Click to collapse
One thing that I still cannot figure out after all of this reading is what to do to get AOSP to build for devices that are not officially supported by it. Granted, this is not a problem for the Nexus 6 right now, but it will be eventually, and I want to know how to handle it when it does become an issue. I've started cloning the repository. My connection gets a top download speed of 60Mbps so it should be reasonably fast.
David B. said:
One thing that I still cannot figure out after all of this reading is what to do to get AOSP to build for devices that are not officially supported by it. Granted, this is not a problem for the Nexus 6 right now, but it will be eventually, and I want to know how to handle it when it does become an issue. I've started cloning the repository. My connection gets a top download speed of 60Mbps so it should be reasonably fast.
Click to expand...
Click to collapse
At that point you will need to know what you are doing as you will have to make the code changes to make it bootable. I hate to say it but the n6 maybe doa after this as anything after 7.1 will need dual partition setup which the n6 doesn't have
zelendel said:
At that point you will need to know what you are doing as you will have to make the code changes to make it bootable. I hate to say it but the n6 maybe doa after this as anything after 7.1 will need dual partition setup which the n6 doesn't have
Click to expand...
Click to collapse
What's stopping the phone from being repartitioned in the same way you repartition a hard drive?
David B. said:
What's stopping the phone from being repartitioned in the same way you repartition a hard drive?
Click to expand...
Click to collapse
The main issue is none of the software for the n6 are made to work with it. All the drivers have to be rewritten. Also all of the new Vulcan graphics drivers won't work on the n6. This is why it didn't get all the features of 7.0
zelendel said:
The main issue is none of the software for the n6 are made to work with it. All the drivers have to be rewritten. Also all of the new Vulcan graphics drivers won't work on the n6. This is why it didn't get all the features of 7.0
Click to expand...
Click to collapse
I had not heard of this before. I was researching it online a bit and I cannot figure out which features are missing from the Nexus 6 version of Nougat. Also, Nougat has to support older hardware for devices that don't support Vulkan, so there's no reason they can't do that for Android O, and it they don't, surely someone smarter than I will be able to hack it together.
David B. said:
I had not heard of this before. I was researching it online a bit and I cannot figure out which features are missing from the Nexus 6 version of Nougat. Also, Nougat has to support older hardware for devices that don't support Vulkan, so there's no reason they can't do that for Android O, and it they don't, surely someone smarter than I will be able to hack it together.
Click to expand...
Click to collapse
That's the thing is android O will only be official supported by devices that can use it. Remember the nexus 6 support ended in October so there won't be an official O release for it.
Will there be a hacked together set up? Oh I'm sure there will be. It will just be without the Vulcan graphics drivers and the new update system which needs the dual partition layout.
The missing features are no background updates, no Vulcan drivers among other things
zelendel said:
That's the thing is android O will only be official supported by devices that can use it. Remember the nexus 6 support ended in October so there won't be an official O release for it.
Will there be a hacked together set up? Oh I'm sure there will be. It will just be without the Vulcan graphics drivers and the new update system which needs the dual partition layout.
The missing features are no background updates, no Vulcan drivers among other things
Click to expand...
Click to collapse
Well if the only things I lose are Vulkan and background updates, I am cool with that. It sounds like Vulkan is intended for games, and since I hate mobile gaming, an adapted build that works with the existing graphics drivers is not a concern at all. As for background updates, I would rather not have those because I like to know when my phone receives updates.
David B. said:
Well if the only things I lose are Vulkan and background updates, I am cool with that. It sounds like Vulkan is intended for games, and since I hate mobile gaming, an adapted build that works with the existing graphics drivers is not a concern at all. As for background updates, I would rather not have those because I like to know when my phone receives updates.
Click to expand...
Click to collapse
The Vulcan driver will be replacing the graphics drivers for everything soon. I can't think of much as I never use stock software.
zelendel said:
The Vulcan driver will be replacing the graphics drivers for everything soon. I can't think of much as I never use stock software.
Click to expand...
Click to collapse
I am sorry, but I am afraid I do not quite understand what it is that you said. What can't you think of?
David B. said:
I am sorry, but I am afraid I do not quite understand what it is that you said. What can't you think of?
Click to expand...
Click to collapse
There were many features that came with 7.0 like the new advanced doze and some other stuff. I dont use stock software and to be honest most of the stuff from 7.0 wasnt even really worth the update to me.
I have had a nexus since day 1 on and off and this was the first time I wasnt excited about the update. Even less with the new updates coming and google locking android down more as well as them moving most of the new stuff to closed sourced stuff. Heck even just having the bootloader unlocked is causing things not to work.
zelendel said:
There were many features that came with 7.0 like the new advanced doze and some other stuff. I dont use stock software and to be honest most of the stuff from 7.0 wasnt even really worth the update to me.
I have had a nexus since day 1 on and off and this was the first time I wasnt excited about the update. Even less with the new updates coming and google locking android down more as well as them moving most of the new stuff to closed sourced stuff. Heck even just having the bootloader unlocked is causing things not to work.
Click to expand...
Click to collapse
Really? What doesn't work with the unlocked bootloader?
David B. said:
Really? What doesn't work with the unlocked bootloader?
Click to expand...
Click to collapse
Things like android pay and saftynet. They are now starting to look for unlocked bootloaders. then you have those that are blocking apps due to root or xposed.