[Dev] EGL OpenGL ES
jini at zeus.net.au
Mon Nov 2 04:07:41 GMT 2015
On 2/11/2015 12:23 PM, Carsten Haitzler wrote:
> On Mon, 02 Nov 2015 11:54:05 +1000
> Peter<jini at zeus.net.au> wrote:
>> On 2/11/2015 11:28 AM, Carsten Haitzler wrote:
>>> On Mon, 02 Nov 2015 11:21:47 +1000
>>> Peter<jini at zeus.net.au> wrote:
>>>> On 2/11/2015 9:41 AM, Carsten Haitzler wrote:
>>>>> On Mon, 02 Nov 2015 09:24:23 +1000
>>>>> Peter<jini at 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.
>>>> Sounds good for creating a new application.
>>>> I was investigating the work required to port an existing
>>>> I noticed the EGL and GLES libraries exist on the tizen platform
>>> 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.
>> 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
>> 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.
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
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.
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.
More information about the Dev