On 2/11/2015 2:44 PM, Carsten Haitzler wrote:
On Mon, 02 Nov 2015 14:07:41 +1000
Peter<j...@zeus.net.au> wrote:
On 2/11/2015 12:23 PM, Carsten Haitzler wrote:
On Mon, 02 Nov 2015 11:54:05 +1000
Peter<j...@zeus.net.au> wrote:
On 2/11/2015 11:28 AM, Carsten Haitzler wrote:
On Mon, 02 Nov 2015 11:21:47 +1000
Peter<j...@zeus.net.au> wrote:
On 2/11/2015 9:41 AM, Carsten Haitzler wrote:
On Mon, 02 Nov 2015 09:24:23 +1000
Peter<j...@zeus.net.au> 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?
At this stage - not that I know of. There *SHOULD* be one in the SDK
that checks binary at compile time for this, but no such thing is done
at the moment. the appstore has such a script/tool and will reject
things that don't comply.
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.
At the libc level - yes. beyond that... YMMV
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.
No. actually. :) You'd need it documented. :) I know that there are EFL
APIs you will have in headers that are part of the upstream EFL public
API but Tizen does not allow them/support them. libc though - yes. ou
should be fine.
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.
Sure. Your issues will be things beyond libc that may be needed by the
JRE - like opengl-es/egl and others.
Regards,
Peter.
My current plan is to use a stripped down headless JRE, so at this stage
it will be dependant on the JRE not using non tizen api.
There's a java tool called jnaerator, that generates equivalent Java
wrapper classes, given c headers, there's an alternative tool called
gluegen, which can also generate Java language bindings.
So far I've successfully been able to generate java wrappers for most of
the Tizen API, in fact, it sounds like I've pulled in too many headers
and need to prune it.
Thanks & regards,
Peter.
_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev
