Develop Bugs

[Dev] ICS Camera Driver Development

Due to the change in ICS that requires moving the camera driver from libcamera to libhardware (like GPS and other devices for Gingerbread), a new driver has to be written.
The problem with this is that many data structures have changed. I couldn't get a single one to compile with the ICS SDK. There are many fundamental changes in the way memory is shared for preview/pictures/video, so that will need to be addressed. I have addressed picture only functionality in the skeleton driver, which will show how to transfer a picture back to the HAL.
ICS Camera Driver Overview
The driver seems to be very generic to most Qualcomm SoCs, so either approach should work for many other devices.
New Driver
See CameraHal_Module.cpp from the ICS source code to see what functions needs to be implemented. It needs to be placed in /system/lib/hw/camera.<target_name_in_build.prop>.so and have the struct "camera_module_t HAL_MODULE_INFO_SYM" inside the code, which the HAL looks for before loading. Once it is loaded, you must implement a few dozen functions to get it to work.
Old Driver
The old drivers primary interface with Android is through libcamera. This loads liboemcamera, which sends commands to the camera kernel driver and the Snapdragon DSP. Liboemcamera is a propriatary library with no documentation apart from the source for QualcommCameraHardware.cpp (which compiles to libcamera.so). The actual Linux kernel module is just a simple I2C bridge to control the camera, and provides no real interface.
Current code/skeleton driver available:
http://forum.xda-developers.com/showpost.php?p=20281617&postcount=17
Please do not comment in this thread unless you are able to contribute to the actual development process.

Please keep this DEV only!
Thank you.

If you're having a problem with the autolocks not releasing when needed, just do the locking manually. It's definitely tedious, but doable. I would guess, however, it's going to be easier in the long run to just implement a proper CameraHal module. If structures that you're relying on have changed... it's almost certainly better to rewrite from scratch.

blarfiejandro said:
If you're having a problem with the autolocks not releasing when needed, just do the locking manually. It's definitely tedious, but doable. I would guess, however, it's going to be easier in the long run to just implement a proper CameraHal module. If structures that you're relying on have changed... it's almost certainly better to rewrite from scratch.
Click to expand...
Click to collapse
Unfortunately, I cannot recompile it with the current ICS source, as the structures the module uses have changed significantly. I could get the 2.3 source and compile against that, but then I might as well just re-write it as you have suggested.
Re-writing it based off of QualcommCameraHardware.cpp will involve the exact same hurdles. The previous driver (libcamera.so, which is compiled from QualcommCameraHardware.cpp) supplied only some functionality to Android, and passed numerous others to liboemcamera.so (completely closed source) via the same dlsym's. So there still wouldn't be a proper driver, just one less layer wrapper.
Ultimately, the only solution looks to be just to use the very core initialization methods from libcamera and find the proper ioctl calls to /dev/msm_camera/control0
I have tried to do that earlier, but liboemcamera.so has callbacks to libcamera.so (which may be passed back again to libcameraservice in Android), so its going to take some reverse engineering to figure out out.
I have been working on a skeleton camera HAL driver, but all callbacks to Android cause libcameraservice to crash (like autofocus finished event). Perhaps its an issue of the libcameraservice.so being distributed with the roms here, I will try it on an emulator.

zivan56 said:
Unfortunately, I cannot recompile it with the current ICS source, as the structures the module uses have changed significantly. I could get the 2.3 source and compile against that, but then I might as well just re-write it as you have suggested.
Re-writing it based off of QualcommCameraHardware.cpp will involve the exact same hurdles. The previous driver (libcamera.so, which is compiled from QualcommCameraHardware.cpp) supplied only some functionality to Android, and passed numerous others to liboemcamera.so (completely closed source) via the same dlsym's. So there still wouldn't be a proper driver, just one less layer wrapper.
Ultimately, the only solution looks to be just to use the very core initialization methods from libcamera and find the proper ioctl calls to /dev/msm_camera/control0
I have tried to do that earlier, but liboemcamera.so has callbacks to libcamera.so (which may be passed back again to libcameraservice in Android), so its going to take some reverse engineering to figure out out.
I have been working on a skeleton camera HAL driver, but all callbacks to Android cause libcameraservice to crash (like autofocus finished event). Perhaps its an issue of the libcameraservice.so being distributed with the roms here, I will try it on an emulator.
Click to expand...
Click to collapse
With the Optimus V, at least, there's a lot of logic in liboemcamera such that any IOCTLs you call on the device will more or less get ignored unless they're what liboemcamera is expecting. I wouldn't spend a lot of time trying to preserve the 2.3 shim.

blarfiejandro said:
With the Optimus V, at least, there's a lot of logic in liboemcamera such that any IOCTLs you call on the device will more or less get ignored unless they're what liboemcamera is expecting. I wouldn't spend a lot of time trying to preserve the 2.3 shim.
Click to expand...
Click to collapse
So that pretty much only leaves direct calls to liboemcamera basically. I don't see any easy way duplicate liboemcameras functionality, as it does lots of non-camera related hardware setup having to do with the DSP.
It might be easier to backport the old camera library instead to ICS if liboemcamera cannot be used.

Is it an option to simply port the gingerbread camera related AOSP code into use for ICS that way there is no trouble with the camera.
Sent from my HTC HD2 using Tapatalk

Its an option. The camera API presented to apps themselves doesn't appear to have changed, so it shouldn't affect the functionality of them. Hopefully only libcameraservice needs to be changed.
I will be giving calling liboemcamera a go again before trying that.

Just a small update (no progress on the HD2 itself)
I have a partially complete skeleton HAL driver written dealing with taking images (not panorama or video). I figured out how to deal with the various callbacks, and now have most major events handled (auto focus, take picture, transfer picture to Android)...it even returns a fake image to test memory operations. Will post it later if anybody is interested.

update: managed to get the camera HAL to negotiate the settings with the camera app and HD2 (i.e picture size, saturation, etc) and init the hardware. Now I am struggling with the preview stuff.
Seeing this error:
E/mm-camera 8x vfe( 69): vfe_util_updaterollofftbl: sensor doesn't support rolloff correction by VFE
When it tries to register memory for the camera to put images into. I will have to look through the kernel source and see what its tripping up on.

Next issue is I need /dev/pmem_smipool . Only some kernels provide this, so I will have to look for one that supports it.

Great work! I know this is developer only thread but I want to help. I do not know how to code however I can test.
Sent from my NexusHD2 using xda premium

I'm afraid unless you know how the pmem stuff works, you can't really.
The main problem now is that the driver (based off QualcommCameraHardware.cpp) and the kernel don't agree on where the shared memory is located (one of MSM_PMEM_OUTPUT1, MSM_PMEM_OUTPUT2 or MSM_PMEM_RAW_MAINIMG, MSM_PMEM_PREVIEW).
Now this depends on the 720p option being enabled/disabled in the kernel (which strangely enough, doesn't actually give 720p support for the HD2).
This is where it errors out:
E/mm-camera 8x-vfe snapshot( 69): vfe_snapshot_raw_axi_init: failed
(message comes from liboemcamera.so)
Kernel reports this:
msm_frame_axi_cfg 1293: pmem region lookup error
So it never transfers the picture/video/preview frames to the shared memory region
Likewise, the QSD8250 CPU has some very unique settings that other MSM devices do not. For example, its preview mode is just video capture mode. Whereas others have a dedicated preview mode.
So far what works:
- Init sensor, set effects, zoom, contrast, etc (and adjust on the fly)
- Take JPEG picture process and transfer to camera app (but only returns solid green due to the kernel not copying the picture into the proper pmem)
- Set video mode

zivan56 said:
MSM_PMEM_OUTPUT1, MSM_PMEM_OUTPUT2 or MSM_PMEM_RAW_MAINIMG, MSM_PMEM_PREVIEW
Click to expand...
Click to collapse
Would it be possible to physically assign a memory address for these variables within the kernal? I understand theirs probably not much I can do, but I'm more than happy to if something comes up I can do. (I can't wait to take programming in school soon)
Sent from my NexusHD2 using xda premium

If your finding yourself getting stuck at any point the best person I can recommend from past knowledge would be XDA member DZO (Martin) who had done alot of sensational work on porting android to nand onto a number of QVGA WinMo devices i.e. Kaiser, vogue, polaris... rewriting many of the drivers himself from scratch.
I hope he is still active here on XDA, his work will be greatly remembered, even more so for myself as I used to own a HTC Kaiser in the past...
If your interested here's a bit about him from an XDA Interview: http://www.xda-developers.com/android/developer-interview-dzo/
XDA Member Profile: http://forum.xda-developers.com/member.php?u=917443
(Looks like he's still active too xD)
Best Regards,
ST1Cl<^^aN

kylew1212 said:
Would it be possible to physically assign a memory address for these variables within the kernal? I understand theirs probably not much I can do, but I'm more than happy to if something comes up I can do. (I can't wait to take programming in school soon)
Sent from my NexusHD2 using xda premium
Click to expand...
Click to collapse
Unfortunately, it doesn't look possible. The kernel driver (msm_camera.c) needs a special type of memory that the DSP can write to. The userspace driver tells the kernel to set up the memory and passes the details back to the kernel driver which tells the hardware to write to this special shared memory. I can copy the data from this buffer to the camera HAL, that works fine...but there is no data in the memory obviously.
Stickman89 said:
If your finding yourself getting stuck at any point the best person I can recommend from past knowledge would be XDA member DZO (Martin) who had done alot of sensational work on porting android to nand onto a number of QVGA WinMo devices i.e. Kaiser, vogue, polaris... rewriting many of the drivers himself from scratch.
I hope he is still active here on XDA, his work will be greatly remembered, even more so for myself as I used to own a HTC Kaiser in the past...
If your interested here's a bit about him from an XDA Interview: http://www.xda-developers.com/android/developer-interview-dzo/
XDA Member Profile: http://forum.xda-developers.com/member.php?u=917443
(Looks like he's still active too xD)
Best Regards,
ST1Cl<^^aN
Click to expand...
Click to collapse
Thanks for the contact. As long as they are Qualcomm MSM/QSD devices, it should be really similar.

Since there were a number of requests for the current code, I am releasing the code for two things:
1. Skeleton.zip - A skeleton HAL which shows you how to do simple image transfers back to the HAL/setting negotiation. This should help with developing drivers for any device or if someone wants to start the HD2 driver from scratch. It will also complete the process of picture transfer back to the camera HAL (with a fixed picture of course)
2. libcamera3.zip - Progress so far on the HD2 driver. It will init the sensor, change/negotiate settings with the HAL.
It also implements notify/data callbacks which have changed significantly with ICS. There are scripts in there to help with getting the driver to the HD2 and chmod the devices so you dont have permission issues.
I used tytung's latest ICS build and the HD2 AOSP dev environment (http://forum.xda-developers.com/showthread.php?t=1361859) see post #3 how to set it up. You may need to pull binaries from the ICS build to the prebuilt folders in the SDK in order to link the driver properly.
The scripts assume the git repository above is in ~/ICS/ and the Android SDK (with adb) is in ~/android-sdk-linux/
Documentation is nonexistant, but it should be easy to figure out. I cannot help anyone with what QualcommCameraHardware.cpp does, I did not change it much apart from implementing the new callbacks and the ICS HAL wrapper.
I wont have much time to work on it, so hopefully someone else can get the ball rolling on getting the shared memory stuff to work properly. Likewise, set up a git repo somewhere for others to contribute.

thx
thanks for effort and work
how does the development continue ?

I am sure someone will pick it up. Its in the interest of owners of the Nexus One and a bunch of other Qualcomm Snapdragon based phone owners who want the camera working in ICS. If someone fixes the driver I was working on, it should support at least a couple more devices with very small changes in the code (or perhaps 1 driver that works on all of them by detecting the phone).

from ankuch ICS sd build: http://forum.xda-developers.com/showpost.php?p=20305195&postcount=677
ankuch said:
Yes. I got first image from camera
Click to expand...
Click to collapse
Edit: Sorry not a dev post

[Q] ICS ROM with Qualcom Hardware decoder

Can someone let me know the ICS ROM for HTC Desire which has Qualcom Hardware decoder enabled.
All CM and MIUI ROMs seems to use software decoder with hardware acceleration hack.

Have a look here:
http://forum.xda-developers.com/showthread.php?t=1355660
Not sure how, but they say they have full HWA now.

I tried it. But it still uses software decoder.

In which case, nothing will be using it. Dont forget we havent got driver source for GPU.

But you guys are making petitions to Qualcomm for getting those, isn't it?
Maybe i should write a letter of supporting too,
The many, the mere eh! ;D

I actually e-mailed them the other day. They simply didn't respond.

GB Camera Libs and Voice Libs in ICS

OK, so i've been running a few different ICS roms and i notice that most have issues with VoiceSearch (or the mic in general in anything outside of a phone call) and obviously they all have issues with the camera.
I'm not too experienced but i know it has to do with the /system/lib or rather the libraries for ICS and lack of support from qualcom and htc. Is there any way to bring over the GB Lib (and even the GB Cam) into ICS?
I tried messing with it a bit myself but with no luck. I also notice ICS has a lot more files in /system/lib/hw that don't even exist in GB. Is this because ICS is using more "hw" (hardware) decoding so there are more "hw" libs?
Any answer would be greatly appreciated. Not looking for anyone to solve my problems, just let me know if you think it's possible

Ah crud, thanked instead of quoting.
Anyway, that would probably not work as these are two completely different operating systems. They have different frameworks, hence different libs, hence why it will not work.

perhaps for camera, but i've read of people doing it for the mic.. which is why i was curious. Actually 90% of the libs seem the same, its just the ones in /hw that seem to be the most diff

The andromadous v12 seems to have a working mic for voice search and other apps like shazam same with quattro these are the only 2 roms I came across that had the working mic

All of the lib files tell the hardware how to interact with GB, we need files that tell them how to interact with ICS. Its hit or miss what will work and what won't as some things in ics work the same as GB but others (camera, mic, videorecprding) don't. So don't expect support for devices like the G2 which htc has no plans on updating to ICS. Our best bet is to wait for another official release of some other phone that has similar enough libs to work. Imho
Sent from my HTC Desire Z using Tapatalk

regarding cm7 and cm9 for galaxy y

i'm not here to disappoint you , but want to reduce your expectations , this thread is not about my cm9 or anythin of mine , its simply common
Actually its impossible to make hw acceleration work in cm7 and cm9 for galaxy y,
that simply means that even if developed it wont be smooth and will be unstable with sw acceleration , simply unusable
Maclaw too pointed out the same that bcm gpu in galaxy y cant support hw acceleration (this applies for cm7 and cm9 , dont complain that ur phone has hw acceleration , yes ur phone does have hw acceleration with stock and aosp rom)
but u still can have hope with sw acceleration , as there is a way to make the rom smooth with sw acceleration but thats too demanding and nearly impossible .
on vivekalady's cm7, he is trying to make hw acceleration work , sw acceleration works already but low graphics performance
so i'm conveying to you people that , dont expect much in terms of cm7 and cm9 for sgy , also miui , but a gud news is that hw acceleration can work with aosp , so miui can be possible .
so u people need to settle with stock based rom's , but with this kind of attitude towards the dev who theme roms and make custom based roms(i'm not making one) , you are actually making the devs pull out of this forum.
this thread was made to reduce expectations and make people clear of the present situations .
edit: hw acceleration has slight chances to work with cm7 , but wont giv full gpu , around 60% is possible
i know very well that there will be trolls, flames for this thread too , but i dont care , i'm none to advice you

Bad news for all sgy users

I knew it
Thanks buddy
Be happy

I'm happy with the custom ROM I've got already. I'd like to have CM9 for my Y, but HCFroyd247's ChobitsDigitalisV2.0 is good enough for me
Press 'Thanks' if I helped!
Sent from my GT-S5360 using XDA Premium

ROFLkopter said:
I'm happy with the custom ROM I've got already. I'd like to have CM9 for my Y, but HCFroyd247's ChobitsDigitalisV2.0 is good enough for me
Press 'Thanks' if I helped!
Sent from my GT-S5360 using XDA Premium
Click to expand...
Click to collapse
Same feeling Its the best way to refrain yourself from cm7/9

What I don't get is why is Cyanogenmod 7 smooth on the Galaxy mini then ? That device also hasn't HW Acceraltion ...

GianniDPC said:
What I don't get is why is Cyanogenmod 7 smooth on the Galaxy mini then ? That device also hasn't HW Acceraltion ...
Click to expand...
Click to collapse
u mean doesnt have hw acceleration ? it has adreno 200 in it , and it gives full gpu acceleration even for ics

goutamniwas said:
u mean doesnt have hw acceleration ? it has adreno 200 in it , and it gives full gpu acceleration even for ics
Click to expand...
Click to collapse
Well the Y also has a gpu in it isn't 'Broadcom BCM2763' VideoCore IV LPDDR2 128MB (And if we really can't get CM 7 or 9 on this device I'll throw it out the window )
Sent from my GT-S5360 using xda premium

GianniDPC said:
What I don't get is why is Cyanogenmod 7 smooth on the Galaxy mini then ? That device also hasn't HW Acceraltion ...
Click to expand...
Click to collapse
if someone say sgy don't have hw acceleration then :
a. he/she don't know about hw acceleration, or
b. it's just excuse to make people stop ask him/her to port cynogenmod to sgy
if this device don't have hw acceleration you will get low fps in antutu 2d/3d benchmark. my home-brew animation app also easily reach 60fps. it's not possible if this device don't have graphic hw acceleration.

as far as I know our problem is not related the hw acceleration stuff. we already have a booted cm7. that's a prove that our device has possibility to has cm7. our main problem at this moment is that we don't have a complete source to build cm7 since the one comes from samsung is incomplete. don't ask me when samsung will release the complete source to public. they're getting more unfriendly to anyone who want to mod their product day by day. as you can see, they doesn't even let us replace their boot animation in their newest firmware for our device.

actually the stock rom can have hw acceleration also aosp , but cm7 and cm9 cant have , i'm not making any excuses , and i didnt say it by myself maclaw told this

kurotsugi said:
as far as I know our problem is not related the hw acceleration stuff. we already have a booted cm7. that's a prove that our device has possibility to has cm7. our main problem at this moment is that we don't have a complete source to build cm7 since the one comes from samsung is incomplete. don't ask me when samsung will release the complete source to public. they're getting more unfriendly to anyone who want to mod their product day by day. as you can see, they doesn't even let us replace their boot animation in their newest firmware for our device.
Click to expand...
Click to collapse
one thing , actually vivek has been tryin to make hw acceleration work for the past 3 to 4 builds , cm7 only boots up with sw acceleration with 0 o android , but not with hw acceleration

irfanbagus said:
if someone say sgy don't have hw acceleration then :
a. he/she don't know about hw acceleration, or
b. it's just excuse to make people stop ask him/her to port cynogenmod to sgy
if this device don't have hw acceleration you will get low fps in antutu 2d/3d benchmark. my home-brew animation app also easily reach 60fps. it's not possible if this device don't have graphic hw acceleration.
Click to expand...
Click to collapse
i wasnt so clear in my thread , stock and aosp is definitely havin hw acceleration , but when it comes to cm7 and cm9 this is not the case(due to numerous reasons)
i'm not here to offend u , or break ur hopes , if u people get gud cm7 and cm9 i'm happy with that , and this thread is made from my own experience in trying to make cm9 for sgy and also from the wrds of maclaw(developer-cm9 for mini,fit,ace,gio) and rom maru(developer -cm9 lg pe350)

GianniDPC said:
Well the Y also has a gpu in it isn't 'Broadcom BCM2763' VideoCore IV LPDDR2 128MB (And if we really can't get CM 7 or 9 on this device I'll throw it out the window )
Sent from my GT-S5360 using xda premium
Click to expand...
Click to collapse
every phone has a gpu , but whats it capable of matters

goutamniwas said:
every phone has a gpu , but whats it capable of matters
Click to expand...
Click to collapse
So, the Mini has a better chip than the Y dafuq Well I wish I bought the mini I would buy that device but than I thought the Y has a better cpu and is newer but yeah ... As I see if it's unable to port CM than it makes me :'(

I'm not referring to viveks build. what I mean is the one ported from ace. the phone is succesfully booted up but we don't have gsm, wifi, and bluetooth functionality since we don't have approriate driver for those stuffs.
actually the stock rom can have hw acceleration also aosp , but cm7 and cm9 cant have --- i didnt say it by myself maclaw told this
Click to expand...
Click to collapse
this one prove that hw acceleration stuff is definetely not a problem. if stock rom and aosp could have hw acceleration then cm7 is surely could have it too. maclaw might think that SGY doesn't support hw acceleration since he couldn't find the driver needed to enable hw acceleration in samsung's source code. well...it simply because samsung nor broadcomm doesn't release the code to public. we can try to make a global petition stuff for samsung to release all their newest source code to public but I doubt if they'll give them easily to us.

TRANSLATING : Galaxy Y Have GPU ( 99,9 % of smarths have it) and Support Hw Acceleration But Cant make it Work (At Moment) with CM7/CM9 Roms.
UNDERSTAND

why would we listen to you?
1. You failed to established a good reputation here.
2. because you have not finished a project.
basically, you haven't proved your worth here in our forum. Kept on skipping from one project to another without any known progress.
The fact here is that no one is relying on you to make this project a reality. If i were to expect this statement, i would be satisfied if it came from vivek. But from you?
HELL NO!!
Dont pretend like you care. Just to cover up what you can't achieve.

soraci said:
why would we listen to you?
1. You failed to established a good reputation here.
2. because you have not finished a project.
basically, you haven't proved your worth here in our forum. Kept on skipping from one project to another without any known progress.
The fact here is that no one is relying on you to make this project a reality. If i were to expect this statement, i would be satisfied if it came from vivek. But from you?
HELL NO!!
Dont pretend like you care. Just to cover up what you can't achieve.
Click to expand...
Click to collapse
EXACTLY

soraci said:
why would we listen to you?
1. You failed to established a good reputation here.
2. because you have not finished a project.
basically, you haven't proved your worth here in our forum. Kept on skipping from one project to another without any known progress.
The fact here is that no one is relying on you to make this project a reality. If i were to expect this statement, i would be satisfied if it came from vivek. But from you?
HELL NO!!
Dont pretend like you care. Just to cover up what you can't achieve.
Click to expand...
Click to collapse
Dude don't be so rude he just wanted to help it isn't his fault the samsung galaxy y source code is incomplete :banghead:
Sent from my GT-S5360 using xda premium

Modified libstagefright to use legacy Qualcomm OMX IL libs on ICS for MSM7x27 SoCs

wooo HQ playback on youtube
Ganster41 said:
Hi, low-end devices users! I have good news for you
As you know, Qualcomm has ended support for their SoCs, based on ARMv6 core, and doesn't release OpenMax IL libraries for Android 4.0+. Someone was crying on Qualcomm's forum, someone try to understand, how to extend GB proprietaries to support new Google OMX extensions, but nobody try to modify libstagefright, and disable using new unimplemended functions...
I spent about a few weeks, learning stagefright architecture, and differents between GB and ICS OMX layers...and now I ready to show it to you
I have only ZTE Blade, and can make ROM only for it. You can download it here. In addition to worked hardware-accelerated video playback, and camcorder, it builded with Linaro GCC 4.7.1, and has a little UI speedup(if it not a placebo ). ROM based on KonstaT device tree, thanks him for it.
Oh, my Dropbox temporary blocked to public links. I upload ROM to letitbit too.
Modified framework's sources can be found on my github. Besides it, you need to add one global define to your device's BoardConfig.mk - COMMON_GLOBAL_CFLAGS += -DQCOM_LEGACY_OMX
UPD: I make same changes in CM10 sources tree, but it doesn't working, and I can't try to fix it, because haven't enough disk space to build CM10 ROM. I think, Google changes OMX API again, and it needs more fixes to get it working. You can download sources from here. For now I not interestid in CM10, because now it laggy and has some not good issues.
UPD2: Please, if you want my help with integration problem, attach logcat at the time, when you try to use vide playback/camcorder. I can't help without any information.
UPD3: If you trying to make port for your device, this post can be helpful. Thanks to cougarcougar for it.
UPD4: We still get errors, if trying to play videos from some apps(e.g. Android browser) in not-fullscreen mode. gralloc or mmap returns error, when try to map buffers from NativeWindow. If anybody have ideas how to fix it, please write it here, or to my PM...
Important addition!
Devices based on MSM7x27 chips has two different versions of OMX libs.
"Oldt"(for froyo?) has an unknown padding between color components parts of returning buffer. I have fixed that for most videos, but some strange resolutions are still gets broken colors with green line on top.
"New" version are present in Samsung/LG devices, who has official Gingerbread ROMs. It returns correct buffer in dfferent color format(YV12, instead of NV21), but it laggy on VGA+ videos. Now don't know why. May be it convert resulting buffer to YV12 on CPU... I will try to understand it later.
I think you can use "old" libs from ZTE Blade on any device, because "new" libs work on ZTE Blade too.
PS: If you want to thanks/support my work - you know where you can find button for it.
Click to expand...
Click to collapse

Yes it's Possible but our 3D Still isn't functioning ! So For now It will not work !

hmmm, that is an interesting problem lol,,