On 2/11/2015 12:23 PM, Carsten Haitzler wrote:
On Mon, 02 Nov 2015 11:54:05 +1000
Peter<[email protected]> wrote:
On 2/11/2015 11:28 AM, Carsten Haitzler wrote:
On Mon, 02 Nov 2015 11:21:47 +1000
Peter<[email protected]> wrote:
On 2/11/2015 9:41 AM, Carsten Haitzler wrote:
On Mon, 02 Nov 2015 09:24:23 +1000
Peter<[email protected]> wrote:
Is there a platform independant way of obtaining a Window and
binding the EGL display to it without using EFL on Tizen?
Is there a possiblity of Tizen supporting OpenKODE from Khronos
in the future?
no. evas_gl replaces egl. it's done this way because there are so
many other things you want to use the widget infrastructure for
like indicator, kbd handling (eg sizing content to move out of
the way of the kbd) etc. and if you use evas_gl you can merge
both ui, widgets gl api.
you simply need to change the egl parts (it's actually less work
using elm_glview than using egl - by far) and ensure your
rendering all happens in the render callback.
Carsten,
Sounds good for creating a new application.
I was investigating the work required to port an existing
application.
I noticed the EGL and GLES libraries exist on the tizen platform
emulator.
yes - but you can't use them if you ever want to ship/distribute
your app. platform components only as they can change to move
display systems.
I was thinking of writing a wrapper library, that implements
GLES2.0 around evas_gl. A Tizen application has it's own lib
directory, if I install the wrapper library into this directory,
will it be resolved instead of the system GLES libraries?
i ... don't know actually. i do know that evas_gl and egl are not an
exact 1:1 match and there are other things like NO swapbuffers so
you structure code differently.
you are best off restructuring the egl code and isolating it in a
porting layer etc.
Thanks,
Peter.
Thank you Carsten,
Ignoring the display layer for a moment, the underlying system is
Linux, I was going to bundle an Embedded JVM with the application
(written in Java) using JOGL - Java Open GL bindings.
Java has JNI which allows it to call C libraries and be invoked by C
code.
It would be nice if Tizen supported Java as well, don't know if there
are any plans in future to do so?
OK time to clarify a few things from a 3rd party developer perspective.
To save you time and ensure we're on the same page:
Tizen is a locked-down sandboxed OS in its reality shipped on actual
commercially available products. It COULD have been like "Linux" (i.e.
GNU/Linux distributions with a regular permission model, display
system, middleware etc.) but has chosen not to be and diverge fairly
significantly (as opposed to Android which just used a Linux kernel and
then built an entirely different OS on top). I quote that "Tizen is to
be as secure or more secure than iOS". Of course that means locking it
down so only the vendor has control.
It has moved further and further away from being Linux over time and
Java is not supported by Tizen. There are currently no plans to do so.
If it's not supported then it's "your job". And it's your job to do it
within the limits set.
So for an app, it's HTML5 with the Tizen web runtime or native with C
APIs (you can use C++ too for your app - your system interface is C
though). You use JUST the C APIs allowed and you cannot use one single
library or function symbol more than that or your app will never be
distributable or installable by anyone else. It'll be nothing more than
a local toy. Apps are checked for libraries linked and symbols accessed
from those libraries and are rejected at the appstore level if they use
any API not documented on tizen.org as a public API.
As a developer you get no root access on any device and devices are
locked down to the point of needing certificate signed by the
manufacturer (e.g. Samsung) to get permission to place applications
(regular ones) on your own device in front of you. That certificate I
think is valid for that device only and no others. Certificates are
manually approved last I knew. So this doesn't get you any extra
permissions other than permission to load app pkgs directly on the
device you have without going through the store to do so.
Oh and bootloaders only allow signed kernels - at least from the z3
onwards. Queue chain of trust spiel here.
So if you've gotten to this point by now being able to finally run
something on the device in front of you, you are limited only to the
APIs above. You must port the entire JVM and it's libraries yourself and
ensure it requires nothing beyond these APIs. Yes - you would have to
ship that JVM embedded with your app after ensuring this. You could
ensure that that layer uses the appropriate GL API sets in Tizen.
If you want to do platform development and build your own Tizen
devices and products, then you can do whatever you like - you have
root and ship software on your device so no one can stop you. I was
assuming for now you are aiming for "3rd party dev" as above on devices
available commercially.
Thanks Carsten,
I've looked into Tizen security and it seems simple enough, from what I
can tell network and other privileges only need to be declared in the
manifest. I'm familiar with protection domain's and least privilege
security models.
Is there a static analysis tool available that allows me to test for
Tizen API compliance?
Despite using a different security model, Tizen still appears to have a
lot of standard C api's that you'd expect to find on a POSIX compliant
unix? There's a lot of header files included in the Tizen IDE that
aren't explicitly documented as part of the API.
Is it safe to conclude that if a header file is available in the tizen
IDE's available header files, then it's part of the Tizen public API?
Apart from header files that aren't supposed be used directly of course.
Example:
#include <sys/socket.h>
Java runs headless on the tizen emulator without privileges, although
I've got more tests to run...
The embedded jvm would bundled with the app and be used as a library
that's invoked from C code.
Regards,
Peter.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
