MediaTek driver sourcecode (want custom ROMs? read this!)

hanzano · Jul 27, 2014

_tmp said:
On the other hand, the tests on dark background (multitouch test, handwriting test) work. But I do have the impression that I get more small lines instead of points for touches with the custom kernel.

Reminds me a bit of this issue: http://xdaforums.com/showthread.php?t=2647294

_tmp · Jul 27, 2014

chrmhoffmann said:
For me it doesn't work. I tried your kernel sources, too, from https://github.com/benlorenz/alps-fairphone-gpl

I just checked out my repo into a new and clean folder, ran the make command from the README, created the boot.img, dd it to /dev/bootimg and copied the modules. It boots fine.

Maybe there something different in the img creation ?

I'm using the following:

Code:

mediatek/build/tools/mkimage ./zImage KERNEL > ./zImage.img
./repack-MT65xx_mine.pl -boot zImage.img origboot.img-ramdisk.cpio.gz boot.img

I have slightly modified the unpack and repack scripts from https://github.com/bgcngm/mtk-tools so that they dont unpack the ramdisk and origboot.img-ramdisk.cpio.gz is what I extracted from the original boot.img.

But I still get this error here on boot. Seems display related.

http://pastebin.com/raw.php?i=tT2GKSsa

It looks like the display panic appears after the reboot is already initiated, from the "Exception stack" at the beginning I think there was another panic earlier. (And I think I have seen a some panic during reboot once too)

hanzano said:
Reminds me a bit of this issue: http://xdaforums.com/showthread.php?t=2647294

I'll do some more testing and post some screenshots later.

Unrelashade · Jul 30, 2014

About the random touches issue: I remember people posting about random touches while charging the phone. So maybe not having the phone connected will solve that problem and show that this is a hardware problem.
Hope this helps

also, maybe it's easier to collaborate on the wiki and collect information and compiling steps/ manuals?
http://xdaforums.com/wiki/Fairphone_Fairphone

zelendel · Jul 30, 2014

Unrelashade said:
About the random touches issue: I remember people posting about random touches while charging the phone. So maybe not having the phone connected will solve that problem and show that this is a hardware problem.
Hope this helps

IT may not be hardware. As on one of my devices we are working on a software bug that messes up the touch imput when the device is pluged in. We know its software as it was not an issue before. So your issue may also be software and not hardware.

tobwes · Jul 30, 2014

I am home for just about two weeks and since there is a re-partitioning of the phone scheduled in the next update I am willing to test your current code. However, this will be the first time that i try to use a custom (self built) kernel. The most adventurous experience I have so far is installing a cyanogen mod on a galaxy sII (which is quite easy), so a small wiki entry regarding the procedure would actually help me a lot and safe me a lot of time.

Also I still need to figure out how it will be best to backup the phone (especially apps like whatsapp and textsecure).

If someone has the time to give short advice that would highly be appreciated (with testing reports

), otherwise I will have to spent more time on research on the internet.

_tmp · Jul 30, 2014

Unrelashade said:
About the random touches issue: I remember people posting about random touches while charging the phone. So maybe not having the phone connected will solve that problem and show that this is a hardware problem.
Hope this helps

zelendel said:
IT may not be hardware. As on one of my devices we are working on a software bug that messes up the touch imput when the device is pluged in. We know its software as it was not an issue before. So your issue may also be software and not hardware.

Im quite sure it is a software problem. It only happens with my custom kernel, but both when plugged and unplugged.
Moreover, I am using a different display driver than the stock kernel (_ipsboe is not present in the strings of the original kernel) and it happens only when the screen is mostly white.

So I still hope for the correct display driver and maybe we need better touch calibration values.

superdragonpt · Jul 31, 2014

Unrelashade said:
About the random touches issue: I remember people posting about random touches while charging the phone. So maybe not having the phone connected will solve that problem and show that this is a hardware problem.
Hope this helps

also, maybe it's easier to collaborate on the wiki and collect information and compiling steps/ manuals?
http://xdaforums.com/wiki/Fairphone_Fairphone

Hi

This issue isn't related with this kernel, but with MTK API, it happens on several MTK devices (i own 5 MTK devices, same isue on all of them)

Connect your charger, then disconnect and connect again, should be fine now...

The first time you connect the charger you'll notice that all cores will be at full speed (avoiding the IDLE )

Ontopic:
About the sourcecode, there's a lot to merge and fix on the stock sources (this is starting to be anoying on all my kernel MTK projects).

You should REALLY disable the MTK debug functions on mediatek/config/MT../ .... / platform
Not only it will reduce your compiled zImage (+- less 300KB) and it should and will avoid several issues on Booting the kernel

I really can't spent more time on this, i was doing an favour to an friend of mine, still busy weith two other MTK kernels projects (MT6577 zte v970 and MT6582 Wiko darkmoon)

Good Luck

Regards

EDIT:

I noticed that the OEM talked about some issues regarding Reparticioning (I think there's two hardware revisions ???)

Thats hardcoded on the kernel under ../mediatek/custom/ Project/common on the partition.define.h

Example:
https://github.com/dragonpt/ZTE_v970_Kernel/tree/master/mediatek/custom/ztev970/common

Regards

_keesj · Jul 31, 2014

entr0 said:
OK, I'll give it a try.

The problem is not only the file ProjectConfig.mk. I think the following folders are missing:

mediatek/config/FP1

mediatek/custom/FP1

Of course, I don't know if the name of the folders would be FP1 or fairphone or whatever. There are only the ahong89_wet_jb2 folders, which seem to contain some generic template (or maybe are for a development board). Alternatively, it might be that the phone-specific files should actually be in ahong89_wet_jb2. Whatever is the case, either some folders are missing or it is not the kernel source for the Fairphone.

AFAIK makefiles like ProjectConfig.mk are also covered by the GPL. I think this is concrete evidence that the current kernel package does not comply with the GPL. Not to mention the issue with the volume buttons.

So the people at Fairphone should ask again for the kernel sources and point out the probable violation of the GPL.

If one of you is in direct contact with the person responsible for the kernel sources at Fairphone, then please pass on this information.

ahong89_wet_jb2 is the machine named used during the build so no missing config here.

entr0 · Aug 2, 2014

I am very excited to see that there is a new kernel source package (v3) and from the reports above it seems that it almost works. Many thanks to the Fairphone team for being so persistent on this subject, and to everyone helping to make a custom kernel!

_keesj said:
ahong89_wet_jb2 is the machine named used during the build so no missing config here.

Ok, so the config was not missing, it was simply the wrong one

The new sources contain many changes in ProjectConfig.mk and mediatek/custom/ahong89_wet_jb2/kernel/dct/dct/. The latter contains files describing how the board is wired.

Notice that there is a copy of ProjectConfig.mk on the Fairphone ROM, it is in the folder /system/data/misc. The CUSTOM_KERNEL settings there completely agree with the ones in the current kernel package. This is another indication that the correct lcm driver might still be missing.

From above discussion, I think up to now the issues with the current kernel sources are:

need fix for: mediatek/platform/mt6589/kernel/drivers/dum-char/partition_define.c
probably missing folder mediatek/custom/common/kernel/lcm/nt35516_qhd_dsi_cmd/ and/or corresponding changes to mediatek/custom/common/kernel/lcm/mt65xx_lcm_list.c
missing file: mediatek/custom/ahong89_wet_jb2/kernel/accelerometer/bma250/cust_acc.c
missing file: mediatek/custom/ahong89_wet_jb2/kernel/alsps/stk3171/cust_alsps.c
maybe an additional issue with the touchpanel driver/configuration

Correct me if I overlooked something. It would be great if the Fariphone team can ask for another, hopefully 100% complete, kernel package.

Just a wild guess on the touchpanel issue: maybe one can try ft5316_driver.c.bak instead of ft5316_driver.c for the touchpanel driver and see if it works better? I just had a quick look, but there might be omissions related to calibration in the current file.

Unfortunately, I am rather busy these days and have no time to experiment with the new sources right away, but I will try ASAP!

_tmp · Aug 2, 2014

entr0 said:
From above discussion, I think up to now the issues with the current kernel sources are:

need fix for: mediatek/platform/mt6589/kernel/drivers/dum-char/partition_define.c

probably missing folder mediatek/custom/common/kernel/lcm/nt35516_qhd_dsi_cmd/ and/or corresponding changes to mediatek/custom/common/kernel/lcm/mt65xx_lcm_list.c

missing file: mediatek/custom/ahong89_wet_jb2/kernel/accelerometer/bma250/cust_acc.c

missing file: mediatek/custom/ahong89_wet_jb2/kernel/alsps/stk3171/cust_alsps.c

maybe an additional issue with the touchpanel driver/configuration

Correct me if I overlooked something. It would be great if the Fariphone team can ask for another, hopefully 100% complete, kernel package.

A few comments on these issues:

The partition files in the original 1.3 sources seem like they corresponds to after the partition upgrade (no fat, bigger cache) but I was able to generate correct files with the included ptgen script after setting MTK_SHARED_SDCARD=no. [1]
There are working cust_alsps.c cust_acc.c in my github, I got them from other repositories and the parameters are adjusted to the ones extracted from the stock kernel. All those hw sensors work fine and give reasonable values in the the kernel I compiled. [1]
I think we really need that display file (and having a correct display might also fix the touch issue as somehow the brightness has an influence ...)
Moreover, a 1.6 source package would be good.

All parameters for the touch panel I could find so far seem identical between the files and the stock kernel.

entr0 said:
Just a wild guess on the touchpanel issue: maybe one can try ft5316_driver.c.bak instead of ft5316_driver.c for the touchpanel driver and see if it works better? I just had a quick look, but there might be omissions related to calibration in the current file.

I had a look at those files and i think the .bak is really a backup and the file was split up into several source files. Many parts that are not in the .c anymore can be found in ft6x06_ex_fun.{c,h}

[1] see here

_keesj · Aug 4, 2014

_tmp said:
A few comments on these issues:

The partition files in the original 1.3 sources seem like they corresponds to after the partition upgrade (no fat, bigger cache) but I was able to generate correct files with the included ptgen script after setting MTK_SHARED_SDCARD=no. [1]

There are working cust_alsps.c cust_acc.c in my github, I got them from other repositories and the parameters are adjusted to the ones extracted from the stock kernel. All those hw sensors work fine and give reasonable values in the the kernel I compiled. [1]

I think we really need that display file (and having a correct display might also fix the touch issue as somehow the brightness has an influence ...)

Moreover, a 1.6 source package would be good.

All parameters for the touch panel I could find so far seem identical between the files and the stock kernel.

I had a look at those files and i think the .bak is really a backup and the file was split up into several source files. Many parts that are not in the .c anymore can be found in ft6x06_ex_fun.{c,h}

[1] see here

We got a new patch containing *only the LCM changes* I haven't had time to look into it.
http://www.fairphone.com/downloads/software/fp1_source_code/GPL_patch_20140731.tar.gz

_tmp · Aug 4, 2014

_keesj said:
We got a new patch containing *only the LCM changes* I haven't had time to look into it.
http://www.fairphone.com/downloads/software/fp1_source_code/GPL_patch_20140731.tar.gz

Awesome, thanks. The new display driver is correct, works and even fixes the issue with random touches! I pushed the driver to my github.

I will do some more testing of the custom kernel soon and try to start removing some mtk debugging stuff ...

superdragonpt · Aug 4, 2014

_tmp said:
Awesome, thanks. The new display driver is correct, works and even fixes the issue with random touches! I pushed the driver to my github.

I will do some more testing of the custom kernel soon and try to start removing some mtk debugging stuff ...

You can start by :
removing KALLSYMS stuff
Clean main Makefile
Clean *junk* declarations on some mtk drivers under platform/ custom

Try to compile with 4.7+ toolchain ( see if it builts ) usually some fixs are needed on mtk kernels.
( check WiFi modules under /platform)
The old ( stock) toolchain used my mtk ( arm eabi 4.6) is really outdated'...

Regards

step21 · Aug 8, 2014

Re: Release of driver sources ...

If anyone is still interested in this ... you could try to contact gpl-violations.org on their mailing list, to check what they think.
However personally, I don't have too much hope ...

zelendel · Aug 8, 2014

step21 said:
If anyone is still interested in this ... you could try to contact gpl-violations.org on their mailing list, to check what they think.
However personally, I don't have too much hope ...

Contacting them won't do any good. As they are in China they are not held to alot of laws

step21 · Aug 9, 2014

zelendel said:
Contacting them won't do any good. As they are in China they are not held to alot of laws

While I know what you mean, this is not necessarily true. I know people who do enforcement of licenses, including alternative licenses such as the GPL, and they have prevailed most of the time. Often just asking in a professional manner helps. At this point it is for example not clear to me, were they even asked? Who asked, and how?
In case they really don't seem to care, next steps can be thought about - such as - does someone know(or is) a kernel developer that wants to pursue gpl enforcement? In case this is a problem, as I suggested, someone should talk to gpl-violations.org first. This is of course not a guarantee, but they can advise more precisely.

zelendel · Aug 9, 2014

step21 said:
While I know what you mean, this is not necessarily true. I know people who do enforcement of licenses, including alternative licenses such as the GPL, and they have prevailed most of the time. Often just asking in a professional manner helps. At this point it is for example not clear to me, were they even asked? Who asked, and how?
In case they really don't seem to care, next steps can be thought about - such as - does someone know(or is) a kernel developer that wants to pursue gpl enforcement? In case this is a problem, as I suggested, someone should talk to gpl-violations.org first. This is of course not a guarantee, but they can advise more precisely.

We have contacted them on a few oem that don't follow the gpl. Take the MIUI OEM they refuse to release the kernel source for their devices and when asked about it they say flat out that they don't have to follow it as China does that enforce Any copyright laws.

step21 · Aug 10, 2014

zelendel said:
We have contacted them on a few oem that don't follow the gpl. Take the MIUI OEM they refuse to release the kernel source for their devices and when asked about it they say flat out that they don't have to follow it as China does that enforce Any copyright laws.

I didn't say it wasn't a problem with a lot of manufacturers. It is. However I wanted to know specifically if you asked the company resposible for the fairphone chip. Is that the same one that did MIUI? Granted, certain countries are a bit selective in enforcing copyright, but this doesn't mean they don't do it at all. It also doesn't really matter what they say - ofc it's probably easier for them not to do it and try to get away with it, they still have to do it. At the very least, however, they would start to care if someone got an injunction and it threatened their sales or other relationships abroad. (assuming they export most of their stuff) I'm not saying that it is easy, but that is the way to go, if talking (specifically to the relevant manufacturer, about this phone/chipset, with documented communication) didn't work.

zelendel · Aug 10, 2014

step21 said:
I didn't say it wasn't a problem with a lot of manufacturers. It is. However I wanted to know specifically if you asked the company resposible for the fairphone chip. Is that the same one that did MIUI? Granted, certain countries are a bit selective in enforcing copyright, but this doesn't mean they don't do it at all. It also doesn't really matter what they say - ofc it's probably easier for them not to do it and try to get away with it, they still have to do it. At the very least, however, they would start to care if someone got an injunction and it threatened their sales or other relationships abroad. (assuming they export most of their stuff) I'm not saying that it is easy, but that is the way to go, if talking (specifically to the relevant manufacturer, about this phone/chipset, with documented communication) didn't work.

Your missing the point. OEM out of china don't have to do anything. We have been down this road with a few oem like micromax. They import their devices from china and are not provided the kernel source so they can't provide it. They have been reported a dozen times but due to the laws in that country there is nothing they will do to change it. Search around. There are dozens of threads about it. You have to remember that not every one is held to the same laws as we are

Unrelashade · Aug 13, 2014

zelendel said:
Your missing the point. OEM out of china don't have to do anything. We have been down this road with a few oem like micromax. They import their devices from china and are not provided the kernel source so they can't provide it. They have been reported a dozen times but due to the laws in that country there is nothing they will do to change it. Search around. There are dozens of threads about it. You have to remember that not every one is held to the same laws as we are

Something I use to wonder about: Is it not forbidden to cooperate with a company that breaks the law? Would that be too complicated?

MediaTek driver sourcecode (want custom ROMs? read this!)

Member

Member

Senior Member

Senior Member

Member

Member

Recognized Developer

Senior Member

New member

Member

Senior Member

Member

Recognized Developer

Member

Senior Member

Member

Senior Member

Member

Senior Member

Senior Member

Similar threads

Top Liked Posts