Re: [Dev] 27000 errors in the Tizen operating system

[Carsten Haitzler]

rove code. Yes, everyone can use a license
> for PVS-Studio, but that's not the point. The main thing is that we
> improve the code.

Actually IMHO the tool is of more value than the service. but I need to
spend some time playing with it first (several months of using the
reports to find and fix issues) and then I'll have an idea of how good
a tool it is. i haven't gotten that far yet. I'd put on my open source
hat and do this on the upstream open source projects and see. I'd want
to do the fixes myself (or withing the development team). Hands dirty.
that's my style. This is open source hat on of course.

I'm open to PVS studio being a good tool. I just haven't tried it yet.

> At the same time we're not saying that you should give up using
> Coverity and other tools. We simply offer to use our analyzer
> additionally. :)
> 
>   
> Best regards,
> Andrey Karpov, Microsoft MVP,
> Ph.D. in Mathematics, CTO
> "Program Verification Systems" Co Ltd.
> URL: www.viva64.com
> E-Mail: kar...@viva64.com
> 
> 
> On 17.07.2017 7:17, Carsten Haitzler wrote:
> > On Fri, 14 Jul 2017 17:19:36 +0300
> > Andrey Karpov <kar...@viva64.com> wrote:
> >
> >> Hello Carsten,
> >>
> >> After publishing my article, several unreasonable news appeared on
> >> the Internet. That's why, I'd like to note that in my article I
> >> didn’t write about the bad/good quality of Tizen code or that
> >> PVS-Studio analyzer is magic, best of the best. I only gave those
> >> numbers that I’d got. I can't talk about the quality of Tizen code,
> >> since I have insufficient data for this purpose. I understand
> >> clearly what you are talking about and agree with you.
> > Indeed that is one reason I ask for numbers that can be compared
> > because when you publish some number, and that number is large (in
> > this case due to the fact that codebase you extrapolated for is
> > large) ... a lot of people don't see the forest from the trees.
> >
> > Don't get me wrong. Code quality is important. Fixing bugs is
> > important. Tools to point out "here is a potential issue" are very
> > useful. But you do need to stand back and see the possibly urgency
> > in light of everything else and that requires comparative numbers.
> >
> >> My objective was to show that despite the already used techniques,
> >> PVS-Studio analyzer can help to make Tizen code better and more
> >> reliable. As I think, I managed to demonstrate this by pointing to
> >> the 900 fragments of code, which, in my opinion, deserve attention,
> >> fixing and refactoring.
> > At this point, for me at least, the jury is out on PVS Studio. We
> > have internal tools and we're using those first at this point on
> > Tizen's codebase. If PVS Studio is better or not than those tools,
> > I'm not going to comment, as I am not in a good position to do so.
> >
> > For the upstream projects tizen depends on that I look after, I'm
> > VERY familiar with Coverity scan and to a lesser extent clang's
> > static analyser. I can say the text reports PVS studio produce pale
> > in comparison to what Coverity provides in the Web UI. It provides
> > code flow analysis (what code path was used to get there) which is
> > very useful in learning the "why", A full browsable view of the
> > code (so I don't keep having to match it back to the source
> > file/line when reading), and a collaborative environment where many
> > deveopers can work together live on the issue list and see what is
> > triaged by who, whenand a log about it, BUT it offers something I
> > have not seen so far in the information you provided for PVS Studio
> > on the blog references here, ... the ability to say "No. False
> > positive. Tool - you're wrong. Here's why". Coverity lets you do
> > this... which lets you move on and not modify code that works fine
> > and is correct.
> >
> > My experience shows that a decent percentage of "fixes for warnings
> > from coverity" lead to ADDING bugs. I've seen it happen many times.
> > It made things WORSE. It went from a "theoretical bug but actually
> > due to environment will never happen" to "I wake up, update code
> > and suddenly app x, y, z are broken in some way and it was a fix
> > for a warning". This is also why I'm wary of having people
> > unfamiliar with code "fix it" based on such warnings. Even people
> > who know the code well mess up.
> >
> >> Unfortunately, the question "Include this as a bugs per 1 k lines
> >> of code or similar metric?" 

Re: [Dev] 27000 errors in the Tizen operating system

[Carsten Haitzler]

.

This is another issue entirely - if the error is "worth worrying about".

> On the other hand, I might highlight not all the errors. I approached
> to the study of the report very carefully, but without bigotry. For 
> example, I was a bit lazy to study the warnings V730 - 
> https://www.viva64.com/en/w/V730/. This is a very time consuming and 
> thankless work, when you work with someone else's code. All the time
> it is unclear, if it is dangerous or not, that some class member has
> been left uninitialized. It is a tedious long labour that needs to be
> done carefully. So, perhaps, with more careful reviewing of the log,
> other errors can be found.

Indeed it is time consuming to examine them all. I think you did a good
job at explaining what errors are there and why in the general sense
these are potential issues.

> About the comparison with the quality of other projects... Difficult 
> question. I ask to understand, that while writing the articles we
> don’t have the aim to compare which code is better or
> worse.Therefore, we usually stop when found enough of quite

The problem is - when you publish numbers like you did, it becomes a
comparison thing. That's how people respond. Headlines like "27000
bugs found in Tizen!" are very much designed to catch attention with
numbers but when there is no context provided... the only thing people
see is a headline.

> interesting bugs for writing an article. Performing the careful
> analysis of all warnings for a large project will take a lot of time.
> I also ask to consider that it is difficult and long to deal with
> unknown code. Therefore, we sometimes mention about density of errors
> only for small projects, since is not very difficult to view the
> whole report. Examples:
> 
>   * Notepad++: we detect about 2 errors per 1000 lines of code.
> https://www.viva64.com/en/b/0511/

WOW. that's a lot. Thanks for the number.

>   * Far Manager for Linux: we detect about 0.464 errors per 1000 lines
> of code. https://www.viva64.com/en/b/0478/

Thanks. your numbers are in line with what coverity indicates too.

>   * Tor project: we do not find anything. Density
> 0.https://www.viva64.com/en/b/0507/
> <https://www.viva64.com/en/b/0507/>

Indeed that is good. I also noted openssl last i checked on coverity
scan had a density of 0 too.

> As we can see, the results are different. However, it seems to me
> they are not worth to concentrate on. Static analyzer is a tool of

They are a tool for prioritization. As I said - bugs are bugs and
should be fixed. Knowing if your bug count is particularly bad or now
compared to "the industry at large" etc. lets you know how much effort
or money or time to spend on these issues.

I have taken a position in upstream projects to just slowly fix the
reported issues over a long period of time. every release - fix some
more so every release has the bug rate go down. So you mix feature
addition and static analysis triage, but focus on the feature
development etc. and less so on triage.

> finding bugs in fresh code. Yes, old mistakes are also worth to be
> fixed, but generally they are not as critical as new ones. Actually,
> if the error is in the code for several years,it means that it rarely
> reveals itself or interferes no one. That’s why it is interesting to
> look to the future rather than the past. Sure, the PVS-Studio
> analyzer can be a good assistant for a programmer.

Indeed I agree there.

> About the percent of false positives. It makes no sense to talk about 
> them without first configuring the analyzer. It's a lot of work,
> which we are ready to engage, if a cooperation begins someday. Can we
> deal with it? Yes, we can:

That sounds like a fair bit of work.

>   *
> https://www.unrealengine.com/en-US/blog/how-pvs-studio-team-improved-unreal-engines-code
>   *
> https://www.unrealengine.com/en-US/blog/static-analysis-as-part-of-the-process
> 
> I think when it comes to projects of such a large size as Tizen, it 
> makes sense to speak not only on product licensing, but also on a
> great support, carried out by our team.
> 
> P.S. On Monday I will demonstrate that the analyzer can be useful not 
> only for finding bugs, but also regarding micro-optimizations. :)

Actually ... that does interest me. That's a new use of static
analysis. I think that this would be generally well received in Tizen
too. If PVS Studio can do this too... it just bumped up in value for
me. I'd like to see what these reports are and what they point out etc.

>   
> Best regards,
> Andrey Karpov, Microsoft MVP,
> Ph.D. in Mathematics, CTO
> "Program Verification Systems" Co Ltd.
> 
> 
> On 14.07.2017 4:35, Carsten Haitzler wrote:
> > On Thu, 13 Jul 2017 14:26:35 +0300
> > Andrey Karpov <

Re: [Dev] 27000 errors in the Tizen operating system

[Carsten Haitzler]

On Thu, 13 Jul 2017 14:26:35 +0300
Andrey Karpov  wrote:

Could you:

1. Include this as a bugs per 1k lines of code or similar metric? Total
bugs is not that useful without knowing total size of code looked at.
At least in the summary.
2. Include metrics calculated similarly for other major projects (Linux
kernel, etc. etc.).

Why? The below is like saying "you're doing 120km/h!!" ... but if
it's on a freeway and the speed limit is 130km/h ... in context it's
very different. This here lacks context.

As I haven't used PVS studio before (it's on a list of things to try
out and see if it's good), but I do know Coverity's scan service very
well, I'll do some back of a napkin numbers:

1. In my experience about ~10-15% of bugs are false positives etc. with
coverity.
2. Coverity says Linux kernel gets 0.48 issues peer 1k lines of code.
applying the above false positive rate, let's call that 0.40. Qt gets
0.72, so lets call that 0.61 adjusting for false positives. Glib gets
0.45, so 0.38 accounting for false positives. So:

With your numbers, Tizen sees 900 issues in 2.4 million lines of code.
that comes out at 0.38.

   Linux kernel = 0.40
   Qt   = 0.61
   Glib = 0.38
   Tizen= 0.38

Yes PVS studio is a different tool to coverity. I'm making an
assumption (much like you do too in many ways) that these two tools are
in the same ballpark and will report similar issues and numbers, but
may be disjoint sets. I'm going with this assumption because you didn't
provide other numbers to go by, and it'd be nice to.

My conclusion is that Tizen code quality is pretty decent in the scheme
of things. It's bug rate is pretty low-ish.

Now on the other side, it';s always great to have tools point out
possible errors. Another tool is another weapon in a war chest to
improve code quality. That's a good thing. Bugs should be looked into
and addressed accordingly based on actual severity and context. just
blindly fixing issues will result in misallocation of time and
resources because it may be an issue in a debug tool that is rarely
used and only for gathering quick information by a developer when
something goes wrong... it may be a seriously exploitable bug in code
that is always able to be triggered remotely. So context is important.
Knowing issues are there and what a tool thinks they are is a great
speedup vs full code review. PVS Studio is indeed such a tool. There
are others too. We have tools of our own we're using more and more.



> Hello All,
> 
> This article will demonstrate that during the development of large 
> projects static analysis is not just a useful, but a completely 
> necessary part of the development process. This article is the first
> one in a series of posts, devoted to the ability to use PVS-Studio
> static analyzer to improve the quality and reliability of the Tizen
> operating system. For a start, I checked a small part of the code of
> the operating system (3.3%) and noted down about 900 warnings
> pointing to real errors. If we extrapolate the results, we will see
> that our team is able to detect and fix about 27000 errors in Tizen.
> Using the results of the conducted study, I made a presentation for
> the demonstration to the Samsung representatives with the offers
> about possible cooperation. The meeting was postponed, that is why I
> decided not to waste time and transform the material of the
> presentation to an article: https://www.viva64.com/en/b/0519/
> 
> 
> Best regards,
> Andrey Karpov, Microsoft MVP,
> Ph.D. in Mathematics, CTO
> "Program Verification Systems" Co Ltd.
> 
> ___
> Dev mailing list
> Dev@lists.tizen.org
> https://lists.tizen.org/listinfo/dev
> 
> 

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Usage of Ofono in Tizen

[Carsten Haitzler]

On Wed, 26 Apr 2017 19:10:43 +0530
Rohit Agrawal  wrote:

Ofono was only used in Tizen IVI. Tizen mobile uses a different telefony
daemon with a library API to it. Tizen IVI has pretty much been
idle for quite a while. No one is taking care of it and with Tizen
v3/v4... Tizen IVI as a profile is also gone (along with other
profiles). The last time any Ofono was touched is over a year ago (Jan
2016). So I would say that it's not really alive in Tizen anymore.

> Hi,
> 
> How is ofono integrated in Tizen IVI ? In the Tizen IVI wiki, ofono is
> mentioned as the Telephony stack.
> https://en.wikipedia.org/wiki/Tizen
> As ofono exposes all its functionality over D-Bus, is there any C/C++
> library (apart from libgofono) which exposes all the APIs and
> internally encapsulate the logic of communicating to ofono in the
> Tizen OS. If so please point us to the library.
> 
> or
> 
> Application developers are supposed to use direct D-Bus API's to get
> modem functionality provided by Ofono.
> 
> -Best Regards,
> Rohit Agrawal

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] A security researcher has found 40 unknown zero-day vulnerabilities in Tizen

[Carsten Haitzler]

On Thu, 6 Apr 2017 08:28:11 -0400
Maxim Khitrov <m...@bhsai.org> wrote:

> On Thu, Apr 6, 2017 at 4:12 AM, Carsten Haitzler
> <c.haitz...@samsung.com> wrote:
> > I wish he'd actually filed bugs on http://bugs.tizen.org 8 months
> > ago. Every platform and software has bugs.  
> 
> Yea, but the other platforms generally try to fix those bugs when they
> are reported. I filed this back in August (not security related, but a
> serious issue nonetheless):
> 
> https://bugs.tizen.org/jira/browse/PTAPI-59

Yes. I remember seeing this. Or something similar...

> You guys definitely take bug reports seriously. When that went
> nowhere, I posted about it on this list in December:
> 
> https://lists.tizen.org/pipermail/dev/2016-December/007243.html

Yes. That's when I saw it ... I responded. :) So did one of the
developers who works on that code.

Although this isn't a security issue, it's an annoying bug nevertheless,
but you did get a response to your mail... :) You did file a bug and
that's a good thing. At least the response to the mail was "It'll be
fixed". :)

> Still zero progress. Each software update for the Gear S2 and S3
> changed how sensor timestamps work, so we had to basically ignore them
> to get our app to work. A new update was just released for the S3, so
> I'm eager to find out what will break this time. This, of course, also
> makes us question whether the sensor data is at all reliable. I didn't
> bother reporting bugs in the Bluetooth framework because what's the
> point? Then there is the problem of inaccurate documentation on
> developer.tizen.org, which I won't even go into.

Now here is where I'll have to explain. Products take Tizen and modify
it and then ship a product and whatever group does that is in charge.
(much like Android etc.) and the platform maintainers have limited
influence or control over this. If it's a platform issue then it can be
fixed on the platform side, but the product groups or companies shipping
the products are in charge of what you end up getting. They are
completely different teams and there is no single coherent "Tizen
leader" who tells everyone what to do with Tizen, how to do it and when.
We can fix bugs in the platform but can't guarantee if an update will
ship for devices or if it will be changed by the time it ships for a
device. That's how all of this is structured. I wish I was able to
change this.

> Anyone who has looked at review.tizen.org/git, and congratulations if
> you actually managed to find what you're looking for there, pretty
> much comes to the same conclusion: Tizen is a mess with really bad
> code all around. I definitely won't touch it again once my current
> project is over. You might want to focus on that first before
> complaining that people aren't filing bug reports.

You are absolutely right. Gerrit is really hard to find what you want.
There are often multiple instances of the same code base and you don't
know which one is active. There generally isn't a nice "README.md" like
front page to tell you what that git repo is for etc. and you need to
dig a lot and have a lot of knowledge. I know that filing a bug
isn't exactly nice - the project list isn't often too useful. There is
a lot to improve. I might have structured it differently. I sure think
that Tizen platform developers need to be more accessible and open to
the public.
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Request-4-Opinion: marking deactivated git repos

[Carsten Haitzler]

On Thu, 29 Dec 2016 05:13:53 +
MyungJoo Ham  wrote:

> >On Thu, 29 Dec 2016 04:51:03 +
> >MyungJoo Ham  wrote:
> >  
> >> > On Thu, 29 Dec 2016 04:29:28 +
> >> > MyungJoo Ham  wrote:
> >> > 
> >> > what we do in enlightenment upstream is we literally rename
> >> > "dead" repositories. we also mark them clearly in description:
> >> > 
> >> > https://git.enlightenment.org/
> >> > 
> >> > look at "Legacy". we do this so code is available if someone
> >> > wants to dig through it, but it:
> >> > 
> >> > 1. is clear by description and/or PATH to git repo that its
> >> > legacy (old/dead).
> >> > 2. it will force good old build scripts to break - thus informing
> >> > whoever runs such tools by way of their build breaking that
> >> > things have moved/changed.
> >> > 
> >> > so i agree that it'd be good to rename and change descriptions
> >> > when a repository is abandoned. we should reduce the number of
> >> > repos perhaps in the process.
> >> 
> >> Renaming may incur problems with build processes targetting old
> >> Tizen versions.
> >> 
> >> I wish we've never renamed any active git repositories; but we've
> >> already committed such sins. Therefore, there are a lot of git
> >> repos that are used by some build projects while not supposed to
> >> get any attention from code writers.
> >> 
> >> Thus, renaming (or moving) git repos might need some aliasing
> >> (e.g., symbolic links) so that developers might be able to
> >> distinguish them quickly while obsolete build systems (for
> >> obsolete projects) may keep access them.  
> >
> >if the code is no longer maintained, worked on, patched, fixed etc...
> >shouldn't it break old builds? shouldn't the people doing the build
> >know that this is now an orphaned repository and no one is going to
> >look after it?  
> 
> For example, can you identify whether it's deactivated or not by
> simply looking at it? (it's dead now.)
> https://review.tizen.org/gerrit/gitweb?p=apps/core/preloaded/quickpanel.git;a=summary
> 
> If app/core/preloaded/quickpanel is renamed as
> DEAD/app/corea/preloaded/quickpanel, I'm happy with it.
> 
> However, the build systems that tries to get Tizen 3.0 or 2.x will be
> broken. That's what I'm concerned with simply renaming/moving dead
> packages. (And that's why I though aliasing/symlinks for them might
> be needed)
> 
> And, I do not want to break old (at least for 3.0) builds. (not
> personal builds, but the builds at build.tizen.org).

ok. well tizen 3 isn't old.. :) i was thinking tizen 2.0 or 1.0 ...

there is also a description that gerrit lists next to the repo when
you list repositories. that description could begin with "LEGACY |" or
"MOVEDTO  |" or "DEAD |" so a quick look at the repo in gerrit would
tell you what you need.

also perhaps add a "DEAD.txt" file in the base of the git repo would
be a clear sign. it could contain information as to what to do (move to
a new repo url, never use this software again as it's obsolete etc.).

if the code in the repo is REALLY dead and going to be ignored from now
on... a move is a good idea. :) if we're just talking about tizen 3
then that's far from legacy at this point :)
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Request-4-Opinion: marking deactivated git repos

[Carsten Haitzler]

On Thu, 29 Dec 2016 04:51:03 +
MyungJoo Ham  wrote:

> > On Thu, 29 Dec 2016 04:29:28 +
> > MyungJoo Ham  wrote:
> > 
> > what we do in enlightenment upstream is we literally rename "dead"
> > repositories. we also mark them clearly in description:
> > 
> > https://git.enlightenment.org/
> > 
> > look at "Legacy". we do this so code is available if someone wants
> > to dig through it, but it:
> > 
> > 1. is clear by description and/or PATH to git repo that its legacy
> > (old/dead).
> > 2. it will force good old build scripts to break - thus informing
> > whoever runs such tools by way of their build breaking that things
> > have moved/changed.
> > 
> > so i agree that it'd be good to rename and change descriptions when
> > a repository is abandoned. we should reduce the number of repos
> > perhaps in the process.  
> 
> Renaming may incur problems with build processes targetting old Tizen
> versions.
> 
> I wish we've never renamed any active git repositories; but we've
> already committed such sins. Therefore, there are a lot of git repos
> that are used by some build projects while not supposed to get any
> attention from code writers.
> 
> Thus, renaming (or moving) git repos might need some aliasing (e.g.,
> symbolic links) so that developers might be able to distinguish them
> quickly while obsolete build systems (for obsolete projects) may keep
> access them.

if the code is no longer maintained, worked on, patched, fixed etc...
shouldn't it break old builds? shouldn't the people doing the build know
that this is now an orphaned repository and no one is going to look
after it?

> > > Dear All Tizen Developers,
> > > 
> > >  
> > > 
> > > When we access a git repo (via gitweb with review.tizen.org or
> > > git-clone), it is hard to know whether
> > > 
> > > the git is used or not.
> > > 
> > >  
> > > 
> > > Determining the activation based on the recent commit date doesn't
> > > work because some repositories
> > > 
> > > are actively used by build system while not getting new commits.
> > > 
> > >  
> > > 
> > > It is possible to determine by carefully looking at the data in
> > > build.tizen.org or download.tizen.org.
> > > 
> > > However, it is not that effective and it is easy to make a
> > > mistake.
> > > 
> > > (Taking several minutes to (unreliably) find out that the git is
> > > there but not used? It's seriously wrong.)
> > > 
> > >  
> > > 
> > > So, wouldn't there be a nice mechanism to let developers
> > > (especially new to that git repo or that part of Tizen)
> > > 
> > > know that a specific git getting their attention is no more used?
> > > (I'm occasionally getting comments on my commits
> > > 
> > > from maintainers that those git are not used anymore...)
> > >   
> >   

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Request-4-Opinion: marking deactivated git repos

[Carsten Haitzler]

On Thu, 29 Dec 2016 04:29:28 +
MyungJoo Ham  wrote:

what we do in enlightenment upstream is we literally rename "dead"
repositories. we also mark them clearly in description:

https://git.enlightenment.org/

look at "Legacy". we do this so code is available if someone wants to
dig through it, but it:

1. is clear by description and/or PATH to git repo that its legacy
(old/dead).
2. it will force good old build scripts to break - thus informing
whoever runs such tools by way of their build breaking that things have
moved/changed.

so i agree that it'd be good to rename and change descriptions when a
repository is abandoned. we should reduce the number of repos perhaps
in the process.

> Dear All Tizen Developers,
> 
>  
> 
> When we access a git repo (via gitweb with review.tizen.org or
> git-clone), it is hard to know whether
> 
> the git is used or not.
> 
>  
> 
> Determining the activation based on the recent commit date doesn't
> work because some repositories
> 
> are actively used by build system while not getting new commits.
> 
>  
> 
> It is possible to determine by carefully looking at the data in
> build.tizen.org or download.tizen.org.
> 
> However, it is not that effective and it is easy to make a mistake.
> 
> (Taking several minutes to (unreliably) find out that the git is
> there but not used? It's seriously wrong.)
> 
>  
> 
> So, wouldn't there be a nice mechanism to let developers (especially
> new to that git repo or that part of Tizen)
> 
> know that a specific git getting their attention is no more used?
> (I'm occasionally getting comments on my commits
> 
> from maintainers that those git are not used anymore...)
> 
>  
> 
> Cheers,
> 
> MyungJoo
> 
> --
> 
> MyungJoo Ham (함명주), Ph.D.
> 
> Developer eXperience Lab, S/W Platform Team, Software R Center
> Samsung Electronics
> Cell: +82-10-6714-2858
> 
>  
> 
>  
> 
>  
> 

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] any API to hide the display of mouse cursor for app Window ?

[Carsten Haitzler]

On Tue, 20 Dec 2016 05:09:28 +
라빈드라 <r.sa...@samsung.com> wrote:

> Hi,
> 
>  
> 
> Thanks for response.
> 
>  
> 
> My app is a virtual machine solution; and the system running on this
> VM has its own cursor for virtual mouse. Therefore, I should not show
> the additional cursor coming from the tizen to the user.
> 
>  
> 
> Thanks for pointing about using elm_win_add() and related APIs. I
> have used  ecore_* APIs since I looked up into tizen support code for
> SDL2 library to find how to work with windows on Tizen, and it was
> using ecore_* APIs.
> 
>  
> 
> I will replace in future ecore_wl_window_new() with elm_win_add()
> calls; however at this time, I guess it will involve lot of work
> since a good amount of EGL and keyboard/mouse input event handler
> code are working with ecore_... APIs. Before starting replacement, I

use callbacks on an object - e.g. look at rage. all kbd shortcuts are
just done as key events on the button object that gets the focus. etc.

> want to know (documentation/sample code to illustrate) how EGL APIs
> (e.g. eglCreateWindowSurface, not Evas GL apis) can work with window
> created using elm_win_*() apis.

you cannot. you MUST use evas_gl api's. the same applies for ecore_evas
windows too. the window content is drawn/managed via evas's canvas in
both scenarios. the fact that it may have worked at all would be by
luck, not by design. you would have gotten lucky that things happened to
render.

evas_gl exists to bind egl OR glx to evas and make things work. the
rules are there in order to ensure that gl rendered content AND canvas
managed content (objects) can work together. e.g. use an evas object as
the pointer and the canvas will draw this on top for you without you
having to draw your own cursor. you can overlay other widgets (buttons,
menus, toolbars and so on) alongside gl content and it works. you can
have as many elm glviews as you like and scroll them around in a
scroller along with list items and buttons and it works. that''s the
point of it all. to have everything work together.

> If there is a way to hide mouse by doing something e.g. in mouse
> event handler passed to ecore_event_handler_add(), please let me
> know. I want to use it temporarily.

see the code i pointed to for rage. :)

> Thanks,
> 
> Ravindra Sande
> 
>  
> 
> - Original Message -
> 
> Sender : Sung-Jin Park <sj76.p...@samsung.com> S5/Senior
> Engineer/Tizen Platform Lab./Samsung Electronics
> 
> Date : 2016-12-20 10:43 (GMT+9)
> 
> Title : RE: Re: [Dev] any API to hide the display of mouse cursor for
> app Window ?
> 
>  
> 
> >realistically though - your app shouldnt have to really do this in
> >general. the compositor itself likely should do this automatically.
> >e.g. if you use a mouse device, show the cursor, then when you go
> >idle for a while, hide it. not the policy you want on a pc, but the
> >kind you'd want on a touch screen device or a tv with a remote that
> >may sometimes have mice attached or used.
> 
>  
> 
> +1
> 
>  
> 
> As a maintainer of Tizen window system input, I strongly agree with
> Carsten Haitzler.
> 
> You can change the cursor image for your application when it's on
> your app window,
> 
> but you shouldn't try to hide it as the cursor is not the asset of an
> application but the system global resource.
> 
>  
> 
> I think it must be controlled by the compositor. The compositor
> controls the cursor visibility under the policy.
> 
> If you try to hide it and suppose it's hidden. I think there will be
> confusion for a user
> 
> as he doesn't understand why the cursor is not visible while the
> mouse is moving around.
> 
>  
> 
> Thanks.
> 
> Sung-Jin Park
> 
>  
> 
> - Original Message -
> 
> Sender : Carsten Haitzler (The Rasterman) <ti...@rasterman.com>
> 
> Date : 2016-12-20 09:58 (GMT+9)
> 
> Title : Re: [Dev] any API to hide the display of mouse cursor for app
> Window ?
> 
>  On Mon, 19 Dec 2016 17:37:12 +0900 Ravindra Sande
> <r.sa...@samsung.com> said:
> 
> > Hi,
> > 
> > I am creating window for my native Tizen application using the
> > ecore_wl_window_new() API.
> > I need to hide the display of mouse cursor within the window.
> 
> first... use elm_win_*add(). ecore_evas is basically a low-level
> internal and lots of things are not taken care of for you that the
> elementary window will do instead. using elm's win means also your
> window is portable and will work in wayland, x11, directly on the
> framebuffer (fbcon or drm/kms) etc. "automatically". (environment
> variables will determine the default d

Re: [Dev] Fix host architecture to x86_64 for building arm target

[Carsten Haitzler]

On Mon, 12 Dec 2016 03:49:25 +
MyungJoo Ham  wrote:

> >On Mon, 12 Dec 2016 02:28:46 +
> >MyungJoo Ham  wrote:
> >  
> >> >On Mon, 12 Dec 2016 01:43:37 +
> >> >MyungJoo Ham  wrote:
> >> >
> >> []  
> >> >> 
> >> >> In order to build dotnet-core runtime (coreclr) armv7l/Linux
> >> >> with crosscompilers, the building environment should be x86-64.
> >> >> x86-32 simply cannot support it because dotnet-core runtime
> >> >> does not support x86-32; you need to run dotnet-core itself to
> >> >> build dotnet-core (to build mscorlib.dll for target arch)
> >> >
> >> >this is what i don't get. MONO (which is what xamarin was actually
> >> >build on top of) runs on armv7. even armv6. it also has run on
> >> >i586 for years and years. dotnetcore if it requires a jit to run
> >> >(a CLR jit) ..then there already is one - MONO has had it for
> >> >years.
> >> 
> >> 
> >> That was about cross-compiling. Even for MONO, crosscompiling MONO
> >> is far-more faster than qemu-native-copmiling MONO. In Tizen
> >> OBS/GBS environment, packages using GCC (including MONO) gets
> >> automatically crosscompiling supports from qemu scripts. Our Tizen
> >> OBS/GBS simply didn't enable that for LLVM, yet.  
> >
> >not talking speed here. just "can it". of course running a qemu arm
> >emulator on x86 to emulate arm binaries is silly (and we've been
> >doing this for a long time for binaries that should have become
> >native to the build host).
> >
> >what worries me is more "if you now built on an arm host or a mips
> >host etc." what would happen? all the distro build systems and
> >setups i have ever worked with would not have issues here. they will
> >work. what i am wondering is if this is going to simply make parts
> >of tizen "only able to be built on x86-64 as a cross-compile and in
> >no other way" and THAT would be a big problem.
> >
> >i understand that some things need awfully huge amounts of ram to
> >build. let's not combine that with an architecture issue.  
> 
> 
> I didn't say you cannot build dotnet-core arm at arm. I was saying why
> they didn't want to build dotnet-core arm at arm. (and x86-32 cannot
> build it)
> 
> 
> The real problem what JY met is that OBS/GBS runs x86-32 for armv7l
> and x86-32 (not armv7l) does not support dotnet-core.
> And if they give up using qemu-accel (or equivalent) for dotnet-core
> (in fact, LLVM/Clang for qemu-accel), there is no issue.
> They can simply build the whole dotnet-core with GBS/OBS, which
> is already done and had been doing so for a while.
> 
> 
> In short, you can build dotnet-core arm at arm, with or without
> GBS/OBS. That's what Tizen dotnet-core folks had been doing for a
> while ago. (I'd been building it in TM1 as well)
> 
> What I suppose JY and collegues trying to do is to avoid building it
> in ARM & x86-32 environment, not because of the RAM size, but because
> of build efficiency with qemu-accel+cross-compiling.

ok. if it's just efficiency then that makes sense. what i was worried
about was that it sounded like it was literally not possible... :)

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Fix host architecture to x86_64 for building arm target

[Carsten Haitzler]

On Mon, 12 Dec 2016 01:43:37 +
MyungJoo Ham  wrote:

> >On Fri, 09 Dec 2016 05:58:22 +
> >윤지영  wrote:
> >  
> >>  
> >>  
> >> - Original Message -
> >> Sender : 하이츨러  Master/S/W
> >> Platform팀(S/W센터)/삼성전자 Date   : 2016-12-09 14:34 (GMT+9)
> >> Title  : Re: [Dev] Fix host architecture to x86_64 for building arm
> >> target 
> >> On Fri, 09 Dec 2016 05:28:19 +
> >> 윤지영  wrote:
> >>
> >> >  
> >> > > - Original Message -
> >> > > Sender : 하이츨러  Master/S/W
> >> > > Platform팀(S/W센터)/삼성전자 Date   : 2016-12-09 12:08 (GMT+9)
> >> > > Title  : Re: [Dev] Fix host architecture to x86_64 for
> >> > > building arm target 
> >> > > On Fri, 09 Dec 2016 03:05:54 +
> >> > > 윤지영  wrote:
> >> > >
> >> > > >  
> >> > > > Dear all,
> >> > > >   
> >> > > > > is it x86-64 that it needs or just a large memory address
> >> > > > > space (like chromium for example)?
> >> > > > 
> >> > > > .NET is a little different.
> >> > > > At present, .NET only provides toolchains for x86-64. To
> >> > > > create arm binaries for .NET runtime and libraries, x86-64
> >> > > > libraries are needed in the GBS arm environment. To do so,
> >> > > > we use the qemu-accel package for x86_64, which installs the
> >> > > > libraries for x86-64 in /emul/ directory on arm GBS
> >> > > > environment and .NET toolchains link them.
> >> > > > 
> >> > > > We have tried to support .NET toolchains for arm. However,
> >> > > > even if we have .NET toolchains for arm, there is a high
> >> > > > possibility of using x86-64 toolchain as usual due to build
> >> > > > speed issue. In the light of our experience, it took more
> >> > > > than 24 hours to build the runtime, but it did not
> >> > > > succeed.  
> >> > >  
> >> > > ok but it isn't something specific like "it uses x86-64
> >> > > assembly and thus only works on x86-64". it's just a question
> >> > > of building the toolchain for arm or i586 or mips or any other
> >> > > architecture - right?  
> >> > 
> >> > More specifically, it does not create a toolchain for arm.
> >> > The toolchain runs on x86_64 called 'dotnet' creates arm
> >> > binaries and C# managed dlls.
> >>
> >> > but can the toolchain be built for arm? can it run on arm? does
> >> > it ONLY run on x86-64 - why only on x86-64 if so?
> >> 
> >> At present, the toolchain for arm is not available and we are
> >> trying to support it as soon as possible. If it is provided, it
> >> can, of course, run on arm. However, even though the toolchain for
> >> arm is provided, we are considering using the toolchain for x86_64
> >> for build acceleration.  
> >
> >ok. so i'm curious... why is it "not provided" what needs to be done
> >to make it work? is this like luajit where it has architecture
> >specific assembly for it's core and so needs to be ported for each
> >architecture?
> >  
> 
> In order to build dotnet-core runtime (coreclr) armv7l/Linux with
> crosscompilers, the building environment should be x86-64. x86-32
> simply cannot support it because dotnet-core runtime does not support
> x86-32; you need to run dotnet-core itself to build dotnet-core (to
> build mscorlib.dll for target arch)

this is what i don't get. MONO (which is what xamarin was actually
build on top of) runs on armv7. even armv6. it also has run on i586 for
years and years. dotnetcore if it requires a jit to run (a CLR
jit) ..then there already is one - MONO has had it for years.

or is this the difference between MONO and microsoft's own dotnet-core
which is far more limited in platform support? this is a specific
limitation of microsft's code? i am unfamiliar with what EXACTLY
dotnet-core is but i suspect it's microsoft's own implementation.

but i DO know MONO has built for and run on a massive range of
architectures for years and years... even back when x86_64 was very new
and shiny and it had to support i586 as that was the vast majority of
the PC market.

> You may try to build dotnet-core armv7l/Linux at ARM(armv7l);
> however, the dotnet toolchain for armv7l is not released officially
> via the official sites (are they releasing ARM/Linux officially these
> days?), which means that you cannot reuse the toolchain release infra
> and the default building scripts, which automatically updates
> dotnet-core toolchains via the Internet. You need to rebuild the
> whole toolchain sets for your toolchain sets. (build dotnet-core
> ARM/Linux to build dotnet-core ARM/Linux for every major updates in
> dotnet-core ARM/Linux). Besides, building dotnet-core ARM/Linux at
> armv7l-qemu at x86-64 takes x10 times of building dotnet-core
> ARM/Linux directly at x86-64 (with crosscompiling toolchains). It's
> 10 min vs 100 min in my desktop.

so why not use MONO? :) it almost sounds like we've chosen a far more
limiting codebase than a far better 

Re: [Dev] Fix host architecture to x86_64 for building arm target

[Carsten Haitzler]

On Fri, 09 Dec 2016 07:08:46 +
윤지영  wrote:

...snip...

> > > More specifically, it does not create a toolchain for arm.
> > > The toolchain runs on x86_64 called 'dotnet' creates arm binaries and
> > > C# managed dlls.    
> >    
> > > but can the toolchain be built for arm? can it run on arm? does it ONLY
> > > run on x86-64 - why only on x86-64 if so?    
> > 
> > At present, the toolchain for arm is not available and we are trying
> > to support it as soon as possible. If it is provided, it can, of
> > course, run on arm. However, even though the toolchain for arm is
> > provided, we are considering using the toolchain for x86_64 for build
> > acceleration.  
>  
> > ok. so i'm curious... why is it "not provided" what needs to be done to
> > make it work? is this like luajit where it has architecture specific
> > assembly for it's core and so needs to be ported for each architecture?  
> 
> We have a plan to release .NET Arm32 runtime and sdk. So we need
> obtain all the release components including runtime, libraries, build
> tools and toolchains. There are a lot of things to be ported for each
> architecture like jit and sdk. Some parts have already been

ok, but there already is a jit for ARM (at least arm32 - how about
arm64?). so this should already work... otherwise the runtime couldn't
work on any phone or similar device as they are all arm.

> completed, but there are still things in progress. We plan to release
> it soon. i586 is also in preparation, and there are many things to
> do. So it will take time.

so i'm still curious what these things are that need to be ported to
make the toolchain work on non x86-64? the toolchain is basically just
a compiler that compile c# src files to c# bytecode and maybe
ahead-of-time compile bytecode to a binary. the rest is portable c# CRL
stuff. right? what specifically needs porting to a new architecture
EXCEPT the jit (and the jit as best i know has already been ported at
least to arm. from what i read xamarin supports arm64 already.
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Fix host architecture to x86_64 for building arm target

[Carsten Haitzler]

On Fri, 09 Dec 2016 05:58:22 +
윤지영  wrote:

>  
>  
> - Original Message -
> Sender : 하이츨러  Master/S/W
> Platform팀(S/W센터)/삼성전자 Date   : 2016-12-09 14:34 (GMT+9)
> Title  : Re: [Dev] Fix host architecture to x86_64 for building arm
> target 
> On Fri, 09 Dec 2016 05:28:19 +
> 윤지영  wrote:
>  
> >    
> > > - Original Message -
> > > Sender : 하이츨러  Master/S/W
> > > Platform팀(S/W센터)/삼성전자 Date   : 2016-12-09 12:08 (GMT+9)
> > > Title  : Re: [Dev] Fix host architecture to x86_64 for building arm
> > > target 
> > > On Fri, 09 Dec 2016 03:05:54 +
> > > 윤지영  wrote:
> > >  
> > > >  
> > > > Dear all,
> > > >     
> > > > > is it x86-64 that it needs or just a large memory address space
> > > > > (like chromium for example)?  
> > > > 
> > > > .NET is a little different.
> > > > At present, .NET only provides toolchains for x86-64. To create arm
> > > > binaries for .NET runtime and libraries, x86-64 libraries are needed
> > > > in the GBS arm environment. To do so, we use the qemu-accel package
> > > > for x86_64, which installs the libraries for x86-64 in /emul/
> > > > directory on arm GBS environment and .NET toolchains link them.
> > > > 
> > > > We have tried to support .NET toolchains for arm. However, even if we
> > > > have .NET toolchains for arm, there is a high possibility of using
> > > > x86-64 toolchain as usual due to build speed issue. In the light of
> > > > our experience, it took more than 24 hours to build the runtime, but
> > > > it did not succeed.    
> > >  
> > > ok but it isn't something specific like "it uses x86-64 assembly and
> > > thus only works on x86-64". it's just a question of building the
> > > toolchain for arm or i586 or mips or any other architecture - right?    
> > 
> > More specifically, it does not create a toolchain for arm.
> > The toolchain runs on x86_64 called 'dotnet' creates arm binaries and
> > C# managed dlls.  
>  
> > but can the toolchain be built for arm? can it run on arm? does it ONLY
> > run on x86-64 - why only on x86-64 if so?  
> 
> At present, the toolchain for arm is not available and we are trying
> to support it as soon as possible. If it is provided, it can, of
> course, run on arm. However, even though the toolchain for arm is
> provided, we are considering using the toolchain for x86_64 for build
> acceleration.

ok. so i'm curious... why is it "not provided" what needs to be done to
make it work? is this like luajit where it has architecture specific
assembly for it's core and so needs to be ported for each architecture?

> > > > Best regards.
> > > > Jiyoung Yun.
> > > >  
> > > >  
> > > > - Original Message -
> > > > Sender :
> > > >
> >하이츨러  Master/S/W Platform팀(S/W센터)/
> >> > 삼성전자 Date   : 2016-12-08 18:28 (GMT+9)
> >>> > Title  : Re: [Dev] Fix host architecture to x86_64 for building arm 
> >>>target 
> > > > On Thu, 08 Dec 2016 18:11:46 +0900
> > > >   wrote:
> > > >  
> > > > > Dear Tizen developers,
> > > > > 
> > > > > Currently we are using two host environments, as you know, i586 and
> > > > > x86_64. But, with i586, there are many kinds of requirements and
> > > > > problems. So I’d like to fix host architecture to x86_64 only.
> > > > > Please note that, it’s for only cross build environment for arm
> > > > > target not i586 and x86_64 target.
> > > > > 
> > > > > This change is applied from Dec 12 to all Tizen:3.0:* and Tizen:*
> > > > > project. Please see the details below.
> > > > > 
> > > > > Changes
> > > > > 
> > > > > 
> > > > > fix host architecture to x86_64 when using qemu / qemu-accel /
> > > > > python-accel for arm target. It affects,
> > > > > - Tizen:3.0:Base and Tizen:3.0:[Mobile/Wearable/Common/IVI/TV]
> > > > > - Tizen:Base and Tizen:[Mobile/Wearable/Common/IVI/TV]
> > > > > 
> > > > > Reasons
> > > > > 
> > > > > 
> > > > > 1. dotnet requirement
> > > > > - They must use x86_64 qemu / accel to build their some packages such
> > > > > as coreclr  
> > > >  
> > > > is it x86-64 that it needs or just a large memory address space (like
> > > > chromium for example)?
> > > >  
> > > > > 2. 64bit target requirement
> > > > > - It is necessary to use x86_64 qemu / accel for 64bit target.
> > > > > 3. Toolchain development
> > > > > - It’s hard to manage memory with i586 qemu / accel because Some
> > > > > toolchain technology such as LTO, Sanitizer family development needs
> > > > > large memory.
> > > > > 4. chromium-efl build failure
> > > > > - Same as 3). because sometimes it needs large memory to build.
> > > > >  
> > > > > Issues & Solutions
> > > > > ===
> > > > >  
> > > > > 1. It doesn’t support i586 host
> > > > > - x86_64 qemu / qemu-accel / python-accel packages are installed to
> > > > > host, and they cannot be executed on 

Re: [Dev] Fix host architecture to x86_64 for building arm target

[Carsten Haitzler]

On Fri, 09 Dec 2016 05:28:19 +
윤지영  wrote:

>  
> > - Original Message -
> > Sender : 하이츨러  Master/S/W
> > Platform팀(S/W센터)/삼성전자 Date   : 2016-12-09 12:08 (GMT+9)
> > Title  : Re: [Dev] Fix host architecture to x86_64 for building arm
> > target 
> > On Fri, 09 Dec 2016 03:05:54 +
> > 윤지영  wrote:
> >    
> > >  
> > > Dear all,
> > >   
> > > > is it x86-64 that it needs or just a large memory address space
> > > > (like chromium for example)?    
> > > 
> > > .NET is a little different.
> > > At present, .NET only provides toolchains for x86-64. To create arm
> > > binaries for .NET runtime and libraries, x86-64 libraries are needed
> > > in the GBS arm environment. To do so, we use the qemu-accel package
> > > for x86_64, which installs the libraries for x86-64 in /emul/
> > > directory on arm GBS environment and .NET toolchains link them.
> > > 
> > > We have tried to support .NET toolchains for arm. However, even if we
> > > have .NET toolchains for arm, there is a high possibility of using
> > > x86-64 toolchain as usual due to build speed issue. In the light of
> > > our experience, it took more than 24 hours to build the runtime, but
> > > it did not succeed.  
> >  
> > ok but it isn't something specific like "it uses x86-64 assembly and
> > thus only works on x86-64". it's just a question of building the
> > toolchain for arm or i586 or mips or any other architecture - right?  
> 
> More specifically, it does not create a toolchain for arm.
> The toolchain runs on x86_64 called 'dotnet' creates arm binaries and
> C# managed dlls.

but can the toolchain be built for arm? can it run on arm? does it ONLY
run on x86-64 - why only on x86-64 if so?
 
> > > Best regards.
> > > Jiyoung Yun.
> > >  
> > >  
> > > - Original Message -
> > > Sender :
> > > 하이츨러  Master/S/W Platform팀(S/W센터)/
> > > 삼성전자 Date   : 2016-12-08 18:28 (GMT+9)
> > > Title  : Re: [Dev] Fix host architecture to x86_64 for building arm 
> > >target 
> > > On Thu, 08 Dec 2016 18:11:46 +0900
> > >   wrote:
> > >    
> > > > Dear Tizen developers,
> > > > 
> > > > Currently we are using two host environments, as you know, i586 and
> > > > x86_64. But, with i586, there are many kinds of requirements and
> > > > problems. So I’d like to fix host architecture to x86_64 only.
> > > > Please note that, it’s for only cross build environment for arm
> > > > target not i586 and x86_64 target.
> > > > 
> > > > This change is applied from Dec 12 to all Tizen:3.0:* and Tizen:*
> > > > project. Please see the details below.
> > > > 
> > > > Changes
> > > > 
> > > > 
> > > > fix host architecture to x86_64 when using qemu / qemu-accel /
> > > > python-accel for arm target. It affects,
> > > > - Tizen:3.0:Base and Tizen:3.0:[Mobile/Wearable/Common/IVI/TV]
> > > > - Tizen:Base and Tizen:[Mobile/Wearable/Common/IVI/TV]
> > > > 
> > > > Reasons
> > > > 
> > > > 
> > > > 1. dotnet requirement
> > > > - They must use x86_64 qemu / accel to build their some packages such
> > > > as coreclr    
> > >  
> > > is it x86-64 that it needs or just a large memory address space (like
> > > chromium for example)?
> > >    
> > > > 2. 64bit target requirement
> > > > - It is necessary to use x86_64 qemu / accel for 64bit target.
> > > > 3. Toolchain development
> > > > - It’s hard to manage memory with i586 qemu / accel because Some
> > > > toolchain technology such as LTO, Sanitizer family development needs
> > > > large memory.
> > > > 4. chromium-efl build failure
> > > > - Same as 3). because sometimes it needs large memory to build.
> > > >  
> > > > Issues & Solutions
> > > > ===
> > > >  
> > > > 1. It doesn’t support i586 host
> > > > - x86_64 qemu / qemu-accel / python-accel packages are installed to
> > > > host, and they cannot be executed on i586 architecture.
> > > > - Strongly recommended reinstalling x86_64 OS
> > > > - For i586 GBS users, there is a guide using x86 qemu / qemu-accel /
> > > > python accel. Please see the below guide
> > > > - For i586 OSC users, I’m sorry I can’t help them. Please reinstall
> > > > x86_64 OS. 
> > > > Change date
> > > > 
> > > > Next week (12/12~)
> > > >  
> > > >  
> > > > GBS build guide for i586 GBS user
> > > > ===
> > > >  
> > > > 1. copy build conf to local directory
> > > > - You can find build conf at the below download server,
> > > >   : e.g., for target-TM1, [hash]-build.conf.gz in
> > > > http://download.tizen.org/snapshots/tizen/mobile/latest/repos/target-
> > > > TM1/packages/repodata/
> > > > - Or you can use below build conf after building once,
> > > >   : /var/tmp/[userid]-gbs/[profile name in .gbs.conf].conf 
> > > >   : [build root in .gbs.conf]/local/BUILD-ROOTS/scratch.*/[profile
> > > > name in .gbs.conf].conf 
> > > > 2. modify build_hostarch like below
> > > 

Re: [Dev] Fix host architecture to x86_64 for building arm target

[Carsten Haitzler]

On Fri, 09 Dec 2016 03:05:54 +
윤지영  wrote:

>  
> Dear all,
> 
> > is it x86-64 that it needs or just a large memory address space
> > (like chromium for example)?  
> 
> .NET is a little different.
> At present, .NET only provides toolchains for x86-64. To create arm
> binaries for .NET runtime and libraries, x86-64 libraries are needed
> in the GBS arm environment. To do so, we use the qemu-accel package
> for x86_64, which installs the libraries for x86-64 in /emul/
> directory on arm GBS environment and .NET toolchains link them.
> 
> We have tried to support .NET toolchains for arm. However, even if we
> have .NET toolchains for arm, there is a high possibility of using
> x86-64 toolchain as usual due to build speed issue. In the light of
> our experience, it took more than 24 hours to build the runtime, but
> it did not succeed.

ok but it isn't something specific like "it uses x86-64 assembly and
thus only works on x86-64". it's just a question of building the
toolchain for arm or i586 or mips or any other architecture - right?

> Best regards.
> Jiyoung Yun.
>  
>  
> - Original Message -
> Sender :
> 하이츨러  Master/S/W Platform팀(S/W센터)/
> 삼성전자 Date   : 2016-12-08 18:28 (GMT+9)
> Title  : Re: [Dev] Fix host architecture to x86_64 for building arm target 
> On Thu, 08 Dec 2016 18:11:46 +0900
>   wrote:
>  
> > Dear Tizen developers,
> > 
> > Currently we are using two host environments, as you know, i586 and
> > x86_64. But, with i586, there are many kinds of requirements and
> > problems. So I’d like to fix host architecture to x86_64 only.
> > Please note that, it’s for only cross build environment for arm
> > target not i586 and x86_64 target.
> > 
> > This change is applied from Dec 12 to all Tizen:3.0:* and Tizen:*
> > project. Please see the details below.
> > 
> > Changes
> > 
> > 
> > fix host architecture to x86_64 when using qemu / qemu-accel /
> > python-accel for arm target. It affects,
> > - Tizen:3.0:Base and Tizen:3.0:[Mobile/Wearable/Common/IVI/TV]
> > - Tizen:Base and Tizen:[Mobile/Wearable/Common/IVI/TV]
> > 
> > Reasons
> > 
> > 
> > 1. dotnet requirement
> > - They must use x86_64 qemu / accel to build their some packages such
> > as coreclr  
>  
> is it x86-64 that it needs or just a large memory address space (like
> chromium for example)?
>  
> > 2. 64bit target requirement
> > - It is necessary to use x86_64 qemu / accel for 64bit target.
> > 3. Toolchain development
> > - It’s hard to manage memory with i586 qemu / accel because Some
> > toolchain technology such as LTO, Sanitizer family development needs
> > large memory.
> > 4. chromium-efl build failure
> > - Same as 3). because sometimes it needs large memory to build.
> >  
> > Issues & Solutions
> > ===
> >  
> > 1. It doesn’t support i586 host
> > - x86_64 qemu / qemu-accel / python-accel packages are installed to
> > host, and they cannot be executed on i586 architecture.
> > - Strongly recommended reinstalling x86_64 OS
> > - For i586 GBS users, there is a guide using x86 qemu / qemu-accel /
> > python accel. Please see the below guide
> > - For i586 OSC users, I’m sorry I can’t help them. Please reinstall
> > x86_64 OS. 
> > Change date
> > 
> > Next week (12/12~)
> >  
> >  
> > GBS build guide for i586 GBS user
> > ===
> >  
> > 1. copy build conf to local directory
> > - You can find build conf at the below download server,
> >   : e.g., for target-TM1, [hash]-build.conf.gz in
> > http://download.tizen.org/snapshots/tizen/mobile/latest/repos/target-
> > TM1/packages/repodata/
> > - Or you can use below build conf after building once,
> >   : /var/tmp/[userid]-gbs/[profile name in .gbs.conf].conf 
> >   : [build root in .gbs.conf]/local/BUILD-ROOTS/scratch.*/[profile
> > name in .gbs.conf].conf 
> > 2. modify build_hostarch like below
> > 
> > …
> > - %define build_hostarch x86_64
> > + %define build_hostarch x86
> > Macros:
> > - %build_hostarch x86_64
> > + %build_hostarch x86
> > :Macros
> > …
> > 
> > 
> > 3. gbs build with local build conf
> > 
> > $ gbs build -A [arch] -D [build conf path/name]
> > 
> > 
> > - e.g., 
> >  
> > $ gbs build -A armv7l -D ./public_3.0_mobile_tm1.conf
> > 
> > 
> > - Or you can add ‘buildconf’ in .gbs.conf like,
> > 
> > [profile.profile name]
> > + buildconf = [build conf path/name] 
> > 
> > 
> > Thanks,
> > Chan Lee
> > 
> > 
> > ___
> > Dev mailing list
> > Dev@lists.tizen.org
> > 

Re: [Dev] Fix host architecture to x86_64 for building arm target

[Carsten Haitzler]

On Thu, 08 Dec 2016 18:11:46 +0900
  wrote:

> Dear Tizen developers,
> 
> Currently we are using two host environments, as you know, i586 and
> x86_64. But, with i586, there are many kinds of requirements and
> problems. So I’d like to fix host architecture to x86_64 only.
> Please note that, it’s for only cross build environment for arm
> target not i586 and x86_64 target.
> 
> This change is applied from Dec 12 to all Tizen:3.0:* and Tizen:*
> project. Please see the details below.
> 
> Changes
> 
> 
> fix host architecture to x86_64 when using qemu / qemu-accel /
> python-accel for arm target. It affects,
> - Tizen:3.0:Base and Tizen:3.0:[Mobile/Wearable/Common/IVI/TV]
> - Tizen:Base and Tizen:[Mobile/Wearable/Common/IVI/TV]
> 
> Reasons
> 
> 
> 1. dotnet requirement
> - They must use x86_64 qemu / accel to build their some packages such
> as coreclr

is it x86-64 that it needs or just a large memory address space (like
chromium for example)?

> 2. 64bit target requirement
> - It is necessary to use x86_64 qemu / accel for 64bit target.
> 3. Toolchain development
> - It’s hard to manage memory with i586 qemu / accel because Some
> toolchain technology such as LTO, Sanitizer family development needs
> large memory.
> 4. chromium-efl build failure
> - Same as 3). because sometimes it needs large memory to build.
>  
> Issues & Solutions
> ===
>  
> 1. It doesn’t support i586 host
> - x86_64 qemu / qemu-accel / python-accel packages are installed to
> host, and they cannot be executed on i586 architecture.
> - Strongly recommended reinstalling x86_64 OS
> - For i586 GBS users, there is a guide using x86 qemu / qemu-accel /
> python accel. Please see the below guide
> - For i586 OSC users, I’m sorry I can’t help them. Please reinstall
> x86_64 OS. 
> Change date
> 
> Next week (12/12~)
>  
>  
> GBS build guide for i586 GBS user
> ===
>  
> 1. copy build conf to local directory
> - You can find build conf at the below download server,
>   : e.g., for target-TM1, [hash]-build.conf.gz in
> http://download.tizen.org/snapshots/tizen/mobile/latest/repos/target-
> TM1/packages/repodata/
> - Or you can use below build conf after building once,
>   : /var/tmp/[userid]-gbs/[profile name in .gbs.conf].conf 
>   : [build root in .gbs.conf]/local/BUILD-ROOTS/scratch.*/[profile
> name in .gbs.conf].conf 
> 2. modify build_hostarch like below
> 
> …
> - %define build_hostarch x86_64
> + %define build_hostarch x86
> Macros:
> - %build_hostarch x86_64
> + %build_hostarch x86
> :Macros
> …
> 
> 
> 3. gbs build with local build conf
> 
> $ gbs build -A [arch] -D [build conf path/name]
> 
> 
> - e.g., 
>  
> $ gbs build -A armv7l -D ./public_3.0_mobile_tm1.conf
> 
> 
> - Or you can add ‘buildconf’ in .gbs.conf like,
> 
> [profile.profile name]
> + buildconf = [build conf path/name] 
> 
> 
> Thanks,
> Chan Lee
> 
> 
> ___
> Dev mailing list
> Dev@lists.tizen.org
> https://lists.tizen.org/listinfo/dev

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] About Installation of the Tizen Studio 1.0

[Carsten Haitzler]

On Wed, 02 Nov 2016 10:46:12 +0900
nicesj  wrote:

> Dear Developers,.
> 
> I have two questions about Tizen Studio.
> 
> 1. Text is not displayed properly while installing it.
> 2. Are there any way to choose the Tizen 3.0 package repository?
> 
> 1. Text issue
> 
> I'm not sure that this mailing list is proper for asking about
> Tizen Studio.
> 
> I'm trying to install the Tizen Studio 1.0,.
> I would like to select (or change) the package repository,. So I
> opened Package Manager Configuration Window.
> But,. I cannot read text in that window.. Just I only can assume
> what it is...
> 
> Are there any options to see the text in a window properly or
> resize the windows?
> 
> Here is a link of captured image.
> (I don't want to fill your email box with my attachment, so I
> leave its link. Sorry for inconvenience.)
> 
> http://nicesj.com/tmp/tizenstudio-window.png
> 
> I'm using the MS Surface Pro 3.
> And the screen resolution is 2160 x 1440.
> OS is Windows 10.
> 
> Please let me know if you need any further information.
> 
> 2. Tizen 3.0 package repository.
> 
>Is it possible to access Tizen 3.0 Package repository of Tizen
> Studio to create a new project based on Tizen 3.0?

oh ... that screenshot looks like the classic "scaling ui and i refuse
to design my ui to scale" issue.

let me expand. this issue exists on tizen itself too and people
avoid/refuse to use widgets properly in order to make ui's resizable
and scaleable. i spent a lot of time trying to tell one guy to stop
using elm_grid. this is why i fought against such a thing but the people
doing the ui designer want a simple layout to just drag and drop and
place/size manually. the problem is this mentality of "must have
simple" leads to the EXACT kind of problem above. i gave up, made
elm_grid, and let the shooting of the feet begin. i guess the only way
to learn is by the path of pain.

so... the above i can just SMELL is a similar issue. your fonts and
bigger. likely a higher dpi screen. windows (it seems) is making
everything bigger. the problem is a lot of the ui seems to have been
manually placed/laid out by someone with a lower resolution screen thus
smaller (in pixels) widgets. when yours have gotten bigger, some parts
seem to lay out ok, others not. i suspect a box/table with proper
minimum size handling has been used for some parts but others have not
been given that level of thought and thus have been made a fixed size
in pixels and placed at a fixed place... and BOOM. your problem above.

the solution of course is to fix this by using proper layout/container
widgets that lay things out based on the sizing of their children and
thus account for minimum sizes as they expand on higher dpi screens
(the button, label etc. gets bigger due to font getting bigger or
padding/spacing getting bigger).

:) until that is fixed you probably are going to have issues dealing
with the ui.

i just thought this was a good time to say "see - this is what i keep
talking about and WHY doing a good toolkit is hard and WHY we cant make
things simple for you because we have to handle these scenarios and
just because the scenario doesn't happen now?today, does not mean it
wont happen next year". everyone who builds a ui should worry about
this and ensure their ui layout works with resizing and scaling up and
down of the ui within a reasonable range.
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] [Tizen] gbs build error - Connection reset by peer

[Carsten Haitzler]

On Mon, 31 Oct 2016 01:18:51 +
PINTU AGARWAL  wrote:

> Hi,
> 
> I am trying to build a Tizen package (any package) using gbs.
> 
> # gbs build -A armv7l --include-all --clean
> 
>  
> 
> But, it downloads some packages and then I get the following error
> always:
> 
> [3s] read failed: Connection reset by peer
> at /usr/share/perl5/LWP/Protocol/http.pm line 414.
> at /usr/share/perl5/LWP/UserAgent.pm line 890. warning: build failed,
> Leaving the logs
> in 
> /home/pintu/GBS-ROOT/local/repos/slp/armv7l/logs/fail/resourced-0.2.90-0/log.txt

did you... read that log.txt file?

> Can somebody explain the meaning of this error and how to correct it ?
> 
>  
> 
> Note that, when I was at different location, I were able to build the
> packages using gbs.
> 
> Now, I moved to different location (for sometime) and my IP address
> got changed (static IP).
> 
>  
> 
>  
> 
>  
> 
> Thank You!
> With Regards,
> Pintu Kumar
> 
>  
> 

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] WG: RE: Antwort: Re: Privilege Platform

[Carsten Haitzler]

On Thu, 27 Oct 2016 09:18:35 +
김보곤  wrote:

> Samsung Enterprise Portal mySingle
> 
> Two points I would like to insist is
> 
>  
> 
> 1.
> 
> I believe blocking sideloading is very good way to protect to snick
> out paid-application to the public which is asset of developers.
> 
> As you can see, I'm a member of gear watchface designer which provide
> designer tools to create gear watchface.
> 
> We did lot's of effort so now designer needs only minites to get the
> certificaiton information not like ios does.
> 
> This also contributed to Tizen Studio.
> 
> As a result, lots of designers can join to tizen eco system with very
> quality watchface application.
> 
> And this is one of reasons people like gear watch series.
> 
> When we want to get trust by designers and developers for high
> quality application , we need this mechanism.

And what has certificates got to do with this? If I wish to "steal" a
watch face I can find the files and copy them off device. If
SMACK/kernel permissions don't stop me from reading them, I can
duplicate them somewhere else. The kernel should be keeping them
unreadable from a regular shell user. I can use such files to make an
Android wear app. I could make and submit a new Tizen app to the app
store and violate copyright. I could use them to make an apple watch
app. The vast majority of normal users will never use sdb or any shell
and jump through several commands to install something. To get the TPK
to begin with I would have to buy it (unless the store protocol is
very broken).

Do you want me to make a proof of concept tool that will actually
automatically request a new signed certificate just like the SDK and
then install a TPK? Perfectly possible. If the Tizen SDK can request
signed certificates for a device I have next to me, then it can be done
in large volume for everyone wanting to pirate a TPK. If you then want
to make this harder and more painful the "look how easy it is" goes
away and things become even more incredibly painful.

Let me give you an example for developers who have actually done this
and had to deal with the pain. They have a phone, develop on PC #1.
then take it to their SDK install on laptop #2... phone refuses to
install apps because its a different certificate. They have to issue a
new certificate. Every time they go from desk to couch and back doing
their work they have to re-issue a certificate. Not very friendly.

> 2.
> 
> "sdb install"
> 
> Please do not assume sdb can be used only USB is connected.

I do not assume this.

> Gear series has no USB, can connect sdb through wifi.
> 
> As a result, gear has more flexible design point without usb port.

I know this. Why do you think I suggest we should bring back usbnet.
Use SSH. It's a far more solid, well tested and featureful solution for
"shell access and command controls" to a device. It's far better tested
than the "wifi support" added to sdb. There's even sshfs. It has full
user authentication. Allows for passwords or public key auth. Can be
done locally (usbnet) or over wifi, over btnet. Any IP connection. It
would instantly disallow anyone from messing with your device just
because you plug it in to some PC to charge as it will deny access to
anyone but the user(s) authorized. And it has been hardened by decades
of being attacked on the internet. Sdb does not.

> "sdb install" in reference phone.
> 
> reference phone, you can install application with "sdb install".

No one can buy a reference phone. They are unavailable. Unless you got
incredibly lucky to be given one at a TDS or TDC... and even then most
of these devices given out now are no longer supported. Go find a
reference watch. A reference TV. They do not exist. Not that someone
can get by simply purchasing one.

Have these and we begin to have a different story. But then people use
reference devices to "steal watch faces or apps", so you by logic
should argue against such things are developer/reference devices... or
such devices can NEVER install anything from the tizen app store which
makes them pretty useless.

> We need reference phone for the developers convinience not freeing
> sideloading.

And no such thing exists. Until then disallowing side-loading is a very
very very poor idea because it drives developers away.

:(

> BRs
> 
> - Original Message -
> 
> Sender : 하이츨러  Master/S/W
> Platform팀(S/W센터)/삼성전자
> 
> Date : 2016-10-27 17:53 (GMT+9)
> 
> Title : Re: [Dev] WG: RE: Antwort: Re: Privilege Platform
> 
>  On Thu, 27 Oct 2016 08:32:58 +
> 김보곤  wrote:
> 
> > Samsung Enterprise Portal mySingle
> > 
> > What you explained is what android does.
> 
> I know that.
> 
> > What we do is what ios does.
> 
> I know that.
> 
> And all the effort of "Tizen is Open Source" falls flat on its face
> the moment we do this. The simple answer is "Android is a far more
> Open Os that Tizen is and that is my honest advice to anyone. 

Re: [Dev] WG: RE: Antwort: Re: Privilege Platform

[Carsten Haitzler]

On Thu, 27 Oct 2016 08:32:58 +
김보곤  wrote:

> Samsung Enterprise Portal mySingle
> 
> What you explained is what android does.

I know that.

> What we do is what ios does.

I know that.

And all the effort of "Tizen is Open Source" falls flat on its face the
moment we do this. The simple answer is "Android is a far more Open Os
that Tizen is and that is my honest advice to anyone. This is a shame
but it is the truth." and this is the actual response from people who
run into this certificate "I need permission to buy my own furniture"
thing.

If you actually read feedback from developers you'll find it's one of
*THE* most painful thing about dealing with Apple and that development
environment.

"Why I hate iOS as a developer"

https://medium.com/@Pier/why-i-hate-ios-as-a-developer-459c182e8a72#.abqom74n7

Read "Certificates and provisioning profiles"

If you wish to invoke the way Apple do things... then I shall invoke
the response from developers like above. And this response is far from
unique. I can find a lot of pain people go through.

But even worse, why don't you spend some time speaking with open source
developers you will give you an earful on just how insulting such
treatment of developers is. I do this. You should. This is a great way
to send developers away, not attract them. And people wonder why
developers are not flocking to write apps for Tizen.

> And tizen has decided ios way from very beging of tizen.

Actually that is COMPLETELY wrong. From the very beginning Intel pushed
very heavily for side-loading WITHOUT restrictions. I was there.
Samsung pushed for not even allowing it at all. In the end we kind of
got our way with this "You can side-load but only if we give you
permission" method.

> Both way has pros and cons and deciding which way is just platform
> policy without exact answer.

And I'm saying that we chose the worst possible way. It goes against
everything Open Source is about. I've been in the Open Source world
for over 20 years. I have a good idea of what it really means. This
kind of certificate thing is anti Open Source.

> In my personal opinion, easy install means easy install malware
> application as well, and it took many years in android to prevent
> installing malware for instance adding such logics to check "allow
> untrusted installs" after people were damanged to install malware
> application through text or something.

If someone like a developer CHOOSES to install something, that is THEIR
CHOICE. They do the install. If you require it be installed on
command-line then fine. Developers will. But disallowing it entirely is
purely insulting. It says "we do not respect YOUR freedom nor YOUR
ability to decide anything for yourself, so we'll just block you
instead."

> So I think deciding blocking sideloading as a platform policy was not
> a bad idea.

It's a horrible idea.

> I just intented to inform him current situation because I think every
> members in here who know about it to share with others.

Correct. But do not expect such a situation to go un-challenged. I have
personally spoken with developers who have sworn at this policy and
instantly given up on Tizen right on the spot. I've seen the results on
driving developers way. Unlike those people who just silently left and
disappeared, I'm standing up for them and am making a point. We have
ACTIVELY tried to drive them off by doing this.

If you had to install using sdb (or even better we should bring back
usbnet support and openssh so you have to set up a user AND password or
ssh public key auth to enable this for your device and then have to
scp/sdb push then locally do "tpk install xxx") then you'll find the
people who need this feature (developers) have it without barriers that
they are not familiar with anyway, and regular people will not
accidentally install things that could be harmful.

> BRs
> 
> - Original Message -
> 
> Sender : 하이츨러  Master/S/W
> Platform팀(S/W센터)/삼성전자
> 
> Date : 2016-10-27 16:54 (GMT+9)
> 
> Title : Re: [Dev] WG: RE: Antwort: Re: Privilege Platform
> 
>  On Thu, 27 Oct 2016 07:19:28 +
> 김보곤  wrote:
> 
> > Samsung Enterprise Portal mySingle
> > 
> > Hello,
> > 
> >  
> > 
> > Sideloading, (https://en.wikipedia.org/wiki/Sideloading) which means
> > to install packages not comming from tizen store is not allowed
> > because of security reason.
> > 
> > So there is no such way to do it.
> 
> "security reason". A very poor excuse. I'm sorry but this policy is an
> excuse to just make life HARD for developers. Just because some
> organizations love to retain total control over their products even
> after sale, does not make it a good or nice thing to do.
> 
> The real issue here is to retain total control. Anything else is an
> excuse. I'm being realistic. Someone has to stand up for users and
> developers and their freedoms and rights, and in my experience almost
> no one does. Even if 

Re: [Dev] WG: RE: Antwort: Re: Privilege Platform

[Carsten Haitzler]

On Thu, 27 Oct 2016 07:19:28 +
김보곤  wrote:

> Samsung Enterprise Portal mySingle
> 
> Hello,
> 
>  
> 
> Sideloading, (https://en.wikipedia.org/wiki/Sideloading) which means
> to install packages not comming from tizen store is not allowed
> because of security reason.
> 
> So there is no such way to do it.

"security reason". A very poor excuse. I'm sorry but this policy is an
excuse to just make life HARD for developers. Just because some
organizations love to retain total control over their products even
after sale, does not make it a good or nice thing to do.

The real issue here is to retain total control. Anything else is an
excuse. I'm being realistic. Someone has to stand up for users and
developers and their freedoms and rights, and in my experience almost no
one does. Even if anyone does, it's always fobbed off as a "security
issue".

A message to users: You need to make your voices heard. No one will
change anything at all unless you stand up and effectively revolt and
protest. The mindset is one of "But this is for your own good!
Security! We are being so nice to you!". Unless you all love things
this way... you need to say something very loudly and clearly because
the very few who will stick up for you will not be listened to.

If someone enables "allow untrusted installs" or similar, then goes and
installs something ... this is not a security issue. They are WILLINGLY
and KNOWINGLY installing software on THEIR device THEY own and THEY
bought. They are not accidentally clicking a link on a a website and
then suddenly having an app installed they didn't know would be.

Imagine this. You buy a house or an apartment. You spend a large amount
of money on it. You then want to move in. The person/company you bought
the apartment or house from, or the bank you borrowed money from says
"Oh no. You can ONLY buy furniture from OUR company store because of
security reasons. You can't move your existing furniture in, or buy
used furniture from your friend. It's a security reason!"

What would your response be? That is EXACTLY what we are doing here.
Treating users as a liability even if they have chosen a path of
possible risk. How DARE someone have the freedom to buy ANY furniture
they like and place it in the home THEY bought and paid for? It could
be a security issue! The furniture may be bugged and listen to
conversations! It may accidentally catch fire on its own! We must
protect those innocent customers from their own bad decisions!It's true
that a lot of people will do bad and risky things, but punishing
EVERYONE is pretty arrogant. Yes, I know you can get permission with a
personal certificate so just YOU can install signed apps that YOU sign
on YOUR device. Imagine you needed permission from the people you
bought your house from to get a special sticker that allowed to you
bring furniture into your own home you already paid for? It's
insulting.

Think about it. Put yourself in someone else's shoes. Imagine you
actually had to use Tizen every day and you were developing software
for it and were asking friends and family to try it out before
uploading to a store? Imagine you just wanted to share it with your
colleagues and never publish it? ... Think about it.

> BRs.
> 
> - Original Message -
> 
> Sender : Robin Wertz 
> 
> Date : 2016-10-21 19:58 (GMT+9)
> 
> Title : [Dev] WG: RE: Antwort: Re: Privilege Platform
> 
>  Hello thanks for your Help,
> 
> so my problem is, we write an application for the samsung gear 2. We
> will install this application on 80 smartwatches. We have dont
> internet on this location. We dont will update all smartwatches over
> connection with tizen. How can i do that ?
> 
> the idea was that we write a second application an "Updater". This
> Updater downloaded the new wgt file from us server and
> uinstalled/installed this. Have anywho a good idea how to implemented
> this ?
> 
> thanks Robin
> 
> 
> 
> 
> Von:이동선 
> An:Robin Wertz , Philippe Coval
>  Kopie:dev@lists.tizen.org
>  Datum:21.10.2016 02:17
> Betreff:RE: [Dev] Antwort: Re:  Privilege Platform
> 
> 
> 
> 
> Hi,
>  
> There are 3 privilege levels(public, partner, platform) in tizen api.
> The platform privilege level is only for developers of device
> manufacturers. So I don't think you can get a platform privilege
> level. If you have an accout of tizen wiki, you can get detailed
> information with the following URL.
> -
> https://wiki.tizen.org/wiki/Security/Tizen_3.X_Overview#Application_Singing_and_Certificates
>  
> BR,
>  
> - Original Message -
> Sender : Robin Wertz 
> Date : 2016-10-20 20:17 (GMT+9)
> Title : [Dev] Antwort: Re: Privilege Platform
>  
> 
> Hi,
> i have a certificate as partner, but i cant use 

[Dev] seriously ...

[Carsten Haitzler]

I could do this quietly... but I'm choosing not to for maximum effect:

Seriosuly:

https://review.tizen.org/gerrit/#/c/61462/11

"Let's remove 700,000 lines of code or so just because we like to". So
this is a git repo based on an upstream project. I have worked on Tizen
and SLP before that and X1 before that... and I have watched for years
as people just do not understand the cost of forking and technical
debt, and then watched the incredible pain as 1, 2 or 3 years later that
wall of pain is hit... and here I see it again.

That has to be one of the WORST commit log mesages I have ever seen. A
commit that removes 700k of code and just has a log of:

"Clean up the enlightenment wayland display server"

What on earth? That is the entire commit log with a change that big?
Where is the reasoning. Justification? Measurements? Some log detailing
the weighing up of pros and cons and the discussion related to that?
Nothing there.

Seriously. This is not just a bad idea, but it's unprofessional in the
extreme in the way this has been done.

... But as there is no log reasoning as to why, I'll just launch into
speculation instead, because hey, the door has been opened so give no
information, let people make up whatever they like instead. It's much
more fun this way.

The above commit smells to me of "Oh well we just couldn't care less
about technical debt and the price we have to pay in future, so we have
zero interest in working with upstream, and will just fork off into our
own world because that's all we know". You never intend to sync with
upstream code ever again do you? That's exactly what this commit screams
to me. You just want to make your own world? Open source community be
damned. In fact your own cost of being able to merge in fixes or
changes or improvements just skyrocketed through the roof. You do not
care about the technical debt you just created because of a "clean up
of 700k lines". That is what this commit screams to me just at a glance.

I actually know what the vast majority of those 700k lines of change do.
Do you? Do you know the value you just threw out and the costs you
created? What is the value in removing code that doesn't even get
compiled (optional modules)? All it does is create more conflicts when
merging. Not to mention, what is the value of removing all the code that
makes Tizen a working desktop UI? Just because you don't use it right
now does not mean it will not be used? You do know we had a Tizen
PC profile before? How short sighted does such a commit really need to
be? What do you do when someone wants to make thin clients with Tizen?
Netbooks? You just threw out the code. You just made it nigh impossible
to sync code with upstream... for what gain or value? Save some RAM?
How much? Did you even measure or benchmark? I see nothnig in a
commit log to justify this. Likely not that much is saved as unused code
wont be executed thus loaded into RAM and most of it isn't even
compiled or packaged and installed. What was saved? A few hundred Kb
total on a whole system? Save some disk space? How much? Is it worth
it? There is (mostly) no such thing as a free lunch. Every "saving"
often comes at a cost. What cost? is it worth it? Nothing here to
explain, justify etc. nor any discussion about this anywhere.

I can go on, but this has to be one of the single poorest commit
messages I have ever seen when combined with the sheer amount of code
it touched (either modified or removed).
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] ??SDL?support?on?Tizen (Carsten Haitzler (The Rasterman))

[Carsten Haitzler]

On Fri, 08 Jul 2016 10:52:50 +0900
sidein <sid...@samsung.com> wrote:

> Hi Raster, 
> 
> The rotation's event is sent by Application framework.

well first this is poor design. rotation is not an application global
thing. its per screen. imagine your desktop with rotatable monitors and
you have 2 of them? tizen by design here is broken. you can never do
that using appframework.

anyway what i did mean is the rotation negotiation with the compositor.
e.g. say "i'm ready to rotate". "i can handle these rotation angles"
and "i'm done drawing the newly rotated buffer" etc.

> SDL Application just know current orientation.
> So, it does not have the client-side rotation.
> I know that SDL GL application render and composite to surface by
> himself. I think that client-side rotation is not needed in SDL.
> I wonder why you think that. Would you explain?

^^^ as above. at least efl does this rotation transparently for apps
hand then handles translating input coordinates etc. so app simply
handles a resize like any window can resize. it would be simpler for
sdl apps this way.

> About indicator, I'm implementing the prototype in tizen backend.
> Maybe he uses ecore_ipc and the other tizen services.
> I concern this control is only for Tizen.

yes and no. for wayland, decorations (border, title etc.) are meant to
be done client-side. this is something sdl has to handle conceptually
anyway if it wants a windowed mode in wayland. doing indicator is
simply using the indicator as a titlebar basically. :)

> If most of SDL GL applications work fine in Tizen Device, I will
> upstream. :)
> 
> Thank you,
> Wonsik
> 
> -Original Message-
> From: Carsten Haitzler [mailto:c.haitz...@samsung.com] 
> Sent: Friday, July 08, 2016 10:28 AM
> To: sidein
> Cc: dev@lists.tizen.org
> Subject: Re: [Dev] ??SDL?support?on?Tizen (Carsten Haitzler (The
> Rasterman))
> 
> On Fri, 08 Jul 2016 10:24:20 +0900
> sidein <sid...@samsung.com> wrote:
> 
> > Hi All,
> > 
> >  
> > 
> >  I 'm preparing  to support SDL on Tizen.
> > 
> > For that, we make tizen backend in SDL 2.
> > 
> > It is similar to the other platforms as windows, iOS.
> > 
> > Current status is the below.
> > 
> > 1. Work with tizen Application framework
> > 
> > 2. Support Tizen ISF, dlog and rotation
> > 
> >  
> > 
> > To support Tizen specific functions, Tizen backend uses some Tizen 
> > APIs as a eocre_wl.  
> 
> is this for things like client-side rotation, rotation protocols,
> indicator stuff etc.?
> 
> > If you want to see current source code, check the below that, plz.
> > 
> > https://review.tizen.org/gerrit/gitweb?p=platform/upstream/SDL.git;a=t
> > ree;h=
> > refs/heads/tizen;hb=refs/heads/tizen  
> 
> oh cool.
> 
> btw. thanks for the mail shout out. i wish more people would do this.
> 
> > Thank you
> > 
> > Wonsik
> > 
> > --- Original Message ---
> > 
> > Sender : huanhuan zhu<huanhuan@samsung.com> Senior 
> > Engineer/SRC-Nanjing-Advanced 2 Lab/Samsung Electronics
> > 
> > Date : Jun 03, 2016 11:41 (GMT+08:00)
> > 
> > Title : Re: Dev Digest, Vol 33, Issue 19
> > 
> >  
> > 
> > Hi All
> > 
> > This is Zhu huanhuan who worked NDK project in TV before.
> > 
> > Let me give my personal opinion,
> > 
> > A. Why we need NDK ?
> > 
> > It is not used for application development directly, it is used for 
> > game engine porting their module over Tizen.
> > 
> > So we do not need to care about UI/FW or language, 3rd developers
> > do not care.
> > 
> >  
> > 
> > B. Why NDK need SDL ?
> > 
> > 1. Not exactly, we can also refer Android to supply Surface and EGL 
> > init & OpenGLES call directly ( I think it is also good)
> > 
> >  
> > 
> > C. Analysis SDL.
> > 
> > 1. SDL similar as windows application, application side hold
> > main-loop itself.
> > 
> > SDL does not care how to integrate platform's appframework who is 
> > incharge of lifecycle management.
> > 
> > For example all application in windows need a X button and close 
> > itself. TaskManager just do kill one process works.
> > 
> > main() is the entrance of application directly.
> > 
> > 2. Android / Tizen which has internal glib's g_main_loop to handle
> > the main-loop.
> > 
> > The AppManager want to handle to launch and terminate works by OS 
> > directly and front-ground/back-ground case.
> > 
> > So ap

Re: [Dev] ??SDL?support?on?Tizen (Carsten Haitzler (The Rasterman))

[Carsten Haitzler]

On Fri, 08 Jul 2016 10:24:20 +0900
sidein <sid...@samsung.com> wrote:

> Hi All,
> 
>  
> 
>  I 'm preparing  to support SDL on Tizen.
> 
> For that, we make tizen backend in SDL 2.
> 
> It is similar to the other platforms as windows, iOS.
> 
> Current status is the below.
> 
> 1. Work with tizen Application framework
> 
> 2. Support Tizen ISF, dlog and rotation
> 
>  
> 
> To support Tizen specific functions, Tizen backend uses some Tizen
> APIs as a eocre_wl.

is this for things like client-side rotation, rotation protocols,
indicator stuff etc.?

> If you want to see current source code, check the below that, plz.
> 
> https://review.tizen.org/gerrit/gitweb?p=platform/upstream/SDL.git;a=tree;h=
> refs/heads/tizen;hb=refs/heads/tizen

oh cool.

btw. thanks for the mail shout out. i wish more people would do this.

> Thank you
> 
> Wonsik
> 
> --- Original Message ---
> 
> Sender : huanhuan zhu<huanhuan@samsung.com> Senior
> Engineer/SRC-Nanjing-Advanced 2 Lab/Samsung Electronics
> 
> Date : Jun 03, 2016 11:41 (GMT+08:00)
> 
> Title : Re: Dev Digest, Vol 33, Issue 19
> 
>  
> 
> Hi All
> 
> This is Zhu huanhuan who worked NDK project in TV before.
> 
> Let me give my personal opinion,
> 
> A. Why we need NDK ?
> 
> It is not used for application development directly, it is used for
> game engine porting their module over Tizen.
> 
> So we do not need to care about UI/FW or language, 3rd developers do
> not care.
> 
>  
> 
> B. Why NDK need SDL ?
> 
> 1. Not exactly, we can also refer Android to supply Surface and EGL
> init & OpenGLES call directly ( I think it is also good)
> 
>  
> 
> C. Analysis SDL.
> 
> 1. SDL similar as windows application, application side hold main-loop
> itself.
> 
> SDL does not care how to integrate platform's appframework who is
> incharge of lifecycle management.
> 
> For example all application in windows need a X button and close
> itself. TaskManager just do kill one process works.
> 
> main() is the entrance of application directly.
> 
> 2. Android / Tizen which has internal glib's g_main_loop to handle the
> main-loop.
> 
> The AppManager want to handle to launch and terminate works by OS
> directly and front-ground/back-ground case.
> 
> So application need register render callback based main-loop and app
> manager is handled in OnXXX callback.
> 
>  
> 
> For android case, it use one thread to handle lifecycle and render.
> 
> For EFL case, it is same but it has a problem of integrate EGL
> inside.(which is a issue I will talk latter)
> 
> For Dali case, it divides two thread for lifecycle and render , which
> I think is a waster of performance.
> 
>  
> 
> So SDL has issue now in Tizen.
> 
> 1. How to integrate to AppFW if main-loop conflict exist.
> 
> Let's see how android do for SDL, it create similar structure as
> dali, event thread(main thread) for applifecycle and inputs, render
> thread for SDL to handle SDL main-loop. So two thread is needed
> ( Somehow a waste) One is for Ecore, another is for SDL main
> 
>  
> 
>  
> 
> Is there other solution ?
> 
> Yes, we can refer Android NDK case directly,  but issue exist that
> evasGL is conflict pure EGL
> 
> that we can not use EFL window, so it will be look like that:
> 
> Ecore+ EcoreX/EcoreWayland window create
> 
> Get surface and pass to user,
> 
> User do EGL init and call OpenGLES api directly
> 
> Handle inputs from XInput or Wayland inputs.
> 
>  
> 
> BR
> 
> Zhu huanhuan
> 
>  
> 
>  
> 
>  
> 
> --- Original Message ---
> 
> Sender : dev-requ...@lists.tizen.org
> <mailto:dev-requ...@lists.tizen.org%3cdev-requ...@lists.tizen.org>
> <dev-requ...@lists.tizen.org>
> 
> Date : May 30, 2016 20:00 (GMT+08:00)
> 
> Title : Dev Digest, Vol 33, Issue 19
> 
>  
> 
> Send Dev mailing list submissions to
> dev@lists.tizen.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.tizen.org/listinfo/dev
> or, via email, send a message with subject or body 'help' to
> dev-requ...@lists.tizen.org
> 
> You can reach the person managing the list at
> dev-ow...@lists.tizen.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Dev digest..."
> 
> 
> Today's Topics:
> 
>1. Re:  ??SDL?support?on?Tizen (Carsten Haitzler (The Rasterman))
>2. Re:  ??SDL?support?on?Tizen (Peter)
> 
> 
> --
> 
> Message: 1
&g

[Dev] Test...

[Carsten Haitzler]

testing... does this work?
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Samsung z3 connect as root

[Carsten Haitzler]

On Mon, 02 May 2016 11:34:04 +
joachim rodrigues  wrote:

> Hi 
> is it possible to open a shell as root on samsung Z3 
> because none of the following commands work : su -> command not
> found /bin/su -> command not found /sbin/su -> command not found
> indeed when connected via a shell to my Z3 i'm connected as
> deelopper.And if i enter : 

if you enter what?

anyway - no. no root for you. you are banned from root on tizen.
security. that's the policy.
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] How can I make Native Application on Tizen TV?

[Carsten Haitzler]

On Thu, 24 Mar 2016 02:31:42 +0900
Baek Seung Hoon  wrote:

> Hi, Everyone.
> 
> I want to make native application on Tizen TV, version 2.4.
> I'm working on a making transition screen using GLES with image
> textures, and in order to show transition effects, used Shader codes.
> 
> As you know that Tizen TV SDK couldn't support any native
> application, only support web.
> However I think that If I use RPM manager and following "packaing
> rules" for Tizen app, It may possible create native application.
> 
> Those are just my assumption, is it possible.. ?
>  or How can I make native app on Tizen TV..?
> 
> Thank you for your attention
> Seunghoon, Baek

no - you cant make native apps for tizen tv's. web only. only oem can
make native apps (and any partners they allow).
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] H/W acceleration and OpenGL related changes

[Carsten Haitzler]

On Mon, 04 Jan 2016 19:07:56 +0530 (IST)
Shahul Ahamed Shaik  wrote:

> Hi,
> 
> I was trying to enable H/W acceleration on a custom board. I have the
> S/W based version up and running and now I am trying to understand
> the changes required for H/W acceleration. Can you please let me know
> the answers to the following question or any links/documents that
> would help me with this task.
> 
> 1. Is DRM compulsory to enable HW acceleration or can we use
> framebuffer?

no, but you will have to support tbm. if by framebuffer you mean fbdev
(/dev/fb) then you are going to have exceedingly poor acceleration as
you dont have vsync support there without kms+drm etc.

> 2. How does EVAS determine weather to use S/W rendering
> or H/W rendering?

evas is asked which engine to use explicitly. there are a range of
engines, buffer (rendering using cpu into in-memory buffers),
software-x11 (use cpu - target x11 display), opengl-x11 (opengl/es +
x11 target) wayland_shm (wayland target, using cpu and shm buffers),
wayland_egl (wayland target, opengl(es) rendering), drm (direct to
drm+kms hw fb devices)...

whoever uses evas decides. the compositor (enlightenment) chooses based
on its config - if its a wayland compositor or an x11 compositor.

apps will decide partly by elementary choosing based on its
configuration and environment variables, as well as apps being able to
explicitly request an accelerated (opengl) engine.

> 3. Is there a refrence code for OpenGL's H/W
> specific code for ARM or emulator?

you need to figure this out depending on your gpu target. as such
opengl libraries (libegfl, libgles etc.) are in whole provided as
binary blobs by most gpu vendors and oems. you need to talk to your
gpu vendor of choice about this. some gpus are supported by the open
source mesa project. this is an open source opengl library set with
support for a range of gpus. support may vary in quality depending on
the gpu in question. intel gpus tend to be some of the best supported.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] tizen public api - java

[Carsten Haitzler]

On Mon, 16 Nov 2015 07:43:48 -0700
Mats Wichmann  wrote:

> On 11/14/2015 05:44 PM, Peter wrote:
> > The libraries used by the jvm are:
> > 
> > linux-gate.so.1
> > libdl.so2
> > libc.so.6
> > libm.so.6
> > libpthread.so.0
> > ld-linux.so.2
> > 
> > With my investigation so far it's quite easy to embed the jvm in a
> > tizen ui application.  
> > 
> > The Elementary and app libraries are easy to work with using java
> > and c.
> > 
> > The question now is, would an application that uses the above
> > libraries be accepted into the tizen store?  
> 
> that list at least looks harmless, it's just "libc" plus linux-gate is
> the virtual shared object from the kernel that appears in some
> implementations (I think some show it as linux-vdso, and not sure what
> tizen does here).
> 
> unfortunately none of us can predict with high accuracy what's in the
> list of allowed interfaces.  there are some things you should not do
> that libc on the surface allows you to do (like launching another
> process via exec, you need to use the tizen app launching system
> instead) - so it might be a question what your jvm does internally.

this is currently an ongoing discussion that policies of tizen appstore
and sdk are counter-productive to developers. api's are locked down now
(literally apps banned if they use anything outside of it) and this is
causing a series of issues i am now seeing.

reality is though... any locking down of apis can be gotten past with
dlsym() and if that were to be banned.. compile into your binary your
own efl parser + linker to replace dl*(). tizen'd have to ban open and
mmap to stop this. even then you can do your own syscallls... so
syscalls would need to be banned directly... and well then... you may
as well not have apps then. :)

so right now my general advice to any development on tizen is - use
dlsym() to work around api issues. you at LEAST have to also handle the
failure case (it returns null). :)

the proper solution is to not be so developer-hostile to begin with.
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Tizen api

[Carsten Haitzler]

On Mon, 09 Nov 2015 09:09:48 +1000 (AEST)
Peter  wrote:

> Any thoughts on using a macro to identify Tizen native api for
> developers?
> 
> Presently developer's have to submit an application to the store to
> determine if the api used by their application is acceptable. 
> 
> Regards,
> 
> Peter. 
> Sent from my Samsung device.

that's a LOT of headers to modify.

what is probably best is if there simply is a verification tool that
runs on a binary that tells you what is "invalid". it's a shame that it
isnt a standard part of sdk build process etc. by now. :(
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] EGL OpenGL ES

[Carsten Haitzler]

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 t

Re: [Dev] EGL OpenGL ES

[Carsten Haitzler]

On Sun, 01 Nov 2015 18:32:11 -0800
Bob Summerwill <b...@summerwill.net> wrote:

> I was my first on-device development on Gear S2 today and had to go
> through that painful certification process.
> 
> I can confirm, though, that the e-mails for the certificates are
> automated and come back almost instantly.   That's the one nice thing
> I have to say about the process from a developer PoV.   That part was
> not too painful in a practical sense.

oh.. so it is automated now. ok. one improvement.

> Provisioning on iOS used to be even worse than that.  I hear iOS
> provisioning might have been streamlined recently, because every
> single developer wasted hours very frequently on this nonsense, and
> all iOS devs dreaded new SDK releases and possibly having to get a
> new xcode, re-build and re-sign everything and kiss goodbye to a day
> or two. On Nov 1, 2015 6:23 PM, "Carsten Haitzler"
> <c.haitz...@samsung.com> 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 ha

Re: [Dev] EGL OpenGL ES

[Carsten Haitzler]

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 f

Re: [Dev] EGL OpenGL ES

[Carsten Haitzler]

On Sun, 01 Nov 2015 17:27:16 -0700
Mats Wichmann  wrote:

> On 11/01/2015 04:24 PM, Peter 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?
> 
> getting at egl other than through efl is discouraged at this time.  as
> to future, not even sure how requests like this get tracked... we'll
> see if there are further comments here.

to use egl you need a native display handle AND a native window. that
requires access directly to x11 display pointer and x11 window id (or
wayland equivalents). since we are moving from one to the other there
is no way we will ant time soon or likely even in the future, allow
this as it totally violates the portability between display systems
(let alone how events are handled etc. not even starting there). this
is how egl was designed and it simply goes directly up against a move
in display systems.

in future with vulkan things might look very different as it has no egl
layer. :) but egl/gles - likely not.
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] EGL OpenGL ES

[Carsten Haitzler]

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.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] EGL OpenGL ES

[Carsten Haitzler]

On Mon, 02 Nov 2015 09:24:23 +1000
Peter  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.
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

[Dev] TDC Presentation

[Carsten Haitzler]

I've uploaded mine here:

https://devs.enlightenment.org/~raster/tdc-2015-presentation.odp

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] [Crosswalk-dev] Tizen - App_launcher and xwalk Landscape issue

[Carsten Haitzler]

crosswalk is doing its own rotationn itself most likely (efl can do this
too for example). you CAn have weston do the rotation instead though -
it may cost a little performance depending on how the app would do
rotation itself.

On 07/17/2015 12:41 AM, Smith, Kenneth wrote:
 Also, wayland/weston don't seem to have any problem with portrait or
 landscape display. It's only the apps running through crosswalk that
 seem to be affected by the VGA connection. Doesn't make any sense, but
 that's the behavior we're seeing.


 On 16 July 2015 at 07:50, McGee, Art amcg...@jaguarlandrover.com
 mailto:amcg...@jaguarlandrover.com wrote:

 Carsten,

 Thank you for your help.   The problem is the quality of the VGA
 port is not what we are looking for.  We need the HDMI or I should
 say Display Port converted to HDMI.  We what the digital HD
 signal.  I am not saying the problem is for sure crosswalk.  I'm
 looking for an explanation.  The only error I have found are in
 crosswalk.  I have looked at wayland to find solutions as well. 
 The fact that this all works in portrait and not landscape has me
 baffled and I'm happy to look into any detailed technical info. 
 I've been over both code and without knowing more specifics I'm
 shooting in the dark.  Although the problem may or may not be
 crosswalk I still need to understand the errors as the VGA display
 being connected shouldn't matter the DP to HDMI should still work
 the same regardless if it is rotated 90 degrees or not.  I do
 agree that it shouldn't matter to crosswalk what screen it's on
 but this is the source of the error messages.

 Thanks

 *Art McGee*
 Infotainment Engineer



 Jaguar Land Rover North America, LLC
 1419 NW 14th Ave, Portland, Oregon, 97209
 Jaguar.com http://jaguar.com  |  LandRover.com
 http://landrover.com


 On 15 July 2015 at 16:45, Carsten Haitzler ti...@rasterman.com
 mailto:ti...@rasterman.com wrote:

 On Wed, 15 Jul 2015 09:22:44 -0700 McGee, Art
 amcg...@jaguarlandrover.com mailto:amcg...@jaguarlandrover.com
 said:

  All,
 
  I have some new testing information.   I've been using the
 VTC1010 for
  testing.  My primary choice for display output is HDMI.  I
 have noticed
  that crosswalk isn't developed for multi-screen yet and I
 wonder if this
  could be part of the problem.  I have been able to get the
 Landscape to
  work on VGA and this can help us move forward but our target
 is HDMI.  I
  have also been able to get Landscape to work on HDMI but
 only under the
  right conditions. When the VGA is connected the apps will
 lauch on the VGA
  screen from the start.  Once the VGA is disconnected apps
 will fail with
  the same error message.  After reconnecting the VGA screen
 the apps will
  launch on the HDMI port.  It appears the VGA must remain
 connected.  If you
  boot the box without VGA and just HDMI the apps won't start
 on boot.  You
  cannot launch the apps by hand. You then connect the VGA
 display and the
  apps will launch on the HDMI display.  I have found if you
 disconnect the
  VGA display the app will shutdown.  This is some kind of
 hard depenancy on
  the VGA display for the VTC1010.  I will post this to the
 JIRA but first
  wanted to see what I get from the mailing list.

 ummm wait a sec... how does this have anything to do with
 crosswalk? crosswalk
 is - at least for you on ivi, a wayland client app. it doesn't
 dneed to know or
 care about hdmi vs vga vs dp vs cga ... all it does is create
 a surface. it can
 query what screens exist but last i knew in wayland, there is
 no protocol
 extension to specifically say i must be on screen x/y/z -
 compositor decides
 where you go. compositor can also even handle rotation for
 clients as well so
 portrait/landscape can be hidden from the client.

 so perhaps you want to bark up a different tree? not
 crosswalk, but your
 compositor (weston i think is what you are using).

 also if you want the wayland client to hint at what output it
 wants, then you
 are in the land of extending protocol (and thus having to
 generate new wayland
 client libs and depend on them). be careful here in simply
 allowing clients to
 specify their screen. you really want to figure this out
 without the client
 voluntarily requesting things - if your multiple screens
 belong to different
 users/people. if it's the same user looking at different
 screens (eg multiple

[Dev] forums - can we please get an email back-end?

[Carsten Haitzler]

hi everyone!

this is directed at the infra team handling tizen.org.

i've been trying to reply to forum posts lately and to be honest, the
web ui isn't friendly to this. it doesn't track what i have and have not
read. it's rather painful. i also have to go to the page every day to
look. if i get busy and forget to go, i miss out.

can we PLEASE get an email back-end. if needed change the forum engine.

https://www.drupal.org/project/femail

for example. i am sure with a little effort you can find many more. if
we had an email interface we'd likely have more traffic and better
support. :)

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] OT: mailing list woes

[Carsten Haitzler]

how did this happen? i mean.. what would trigger someone to report
lists.tizen.org to spamhaus?

On 06/11/2015 03:31 AM, Mats Wichmann wrote:
 Folks,

 FYI, we had a round of problems the last few days. Apparently, this host
 (lists.tizen.org) made it on to one or more spam lists (SpamHaus I know
 for sure).  This caused mailing list mail to be rejected by various mail
 servers, which in turn caused the tizen mailing lists to start counting
 bounces.  Eventually, a whole bunch of people got auto-unsubscribed due
 to excessive bounces.  Obviously it's not very effective to send mail
 through a list and expect it to reach people who can't receive mail from
 the list either because they didn't get resubscribed yet, or in case
 there are lingering problems, but at least more than just a few of you
 will now know there were issues and they're known ones.  Thiago says the
 blocklist problem was taken care of already, so hopefully there won't be
 further issues.

 sorry for the hiccup!

 -- mats
 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev


-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Common QA for Tizen on Yocto

[Carsten Haitzler]

On 06/05/2015 04:14 PM, Dominig ar Foll (Intel OTC) wrote:
 Centre Intel SSG
 Le 05/06/2015 01:59, Carsten Haitzler (The Rasterman) a écrit :
 On Thu, 04 Jun 2015 14:09:03 +0300 Leon Anavi
 leon.an...@konsulko.com said:


 good q. is zypper an integral part of tizen? from the view of
 someonme on a
 tizen system who wants to add a package - eg a debugger to get work
 done... it
 is.
 Zypper is not part of Tizen compliance and as Yocto does not use
 Zypper is quite logical not to have it.
 Model with Yoco is that you do an image for what you need, not a base
 image where you add later Package from a repo.
 While it could be done, its certainly not coming by default.

my question is more one of maybe it should be there by default as a
core part of tizen? as it has key value to tizen as an OS. it makes
tizen useful. it differentiates tizen. it makes an installed tizen
device EASY to extend as a developer of that device or as someone
interested in augmmenting it.


 also - is smack a required thing in tizen. sure- adds security, but
 is it a
 hard dep - no smack, then it's not tizen?
 I can confirm that pint, no Smack, no Tizen.
 My advise is to reactivate Smack ASAP as making it at the end of the
 project would be more than a serious pain.
 Believe me, we tried :-(

so saying.. smack - pain. ? :) /me looks around for casey...

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Misalignment of Tizen profiles on Tizen:Common

[Carsten Haitzler]

On 05/20/2015 09:07 AM, Mats Wichmann wrote:
 On 05/19/15 15:34, Carsten Haitzler wrote:
 On Tue, 19 May 2015 12:49:51 +0200 Tomasz Swierczek t.swierc...@samsung.com
 said:

 Apart from being a common part of all profiles, this *really is* the base 
 for
 work of Tizen security team.

 Without Common we will have a big problem in keeping all our work properly
 tested  released - and we may quickly end up with 3 separate Tizen's on
 each profile.


 Like Stephane wrote, Common's status *needs to be clarified*. Unfortunately,
 I'm  not the person with authority to do this. 
 the status is the same. the problem is - people don't really care. they are
 tasked to work on tizen tv or tizen mobile, so that's what they work on.
 everything else is irrelevant. they are not interested in common or any other
 profile. it's the reality.

 our core problem is that we HAVE PROFILES (as in separate tizen stacks). this
 should cease imho. there should be just tizen. a tizen MOBILE device may
 add/include some extra daemons or packages (or remove some). same for tv or 
 ivi
 etc. etc. - a profile should be nothing more than a list of guaranteed 
 minimum
 libraries, services and ui style.

 so we don't have a chance of having maintainers reject patches because
 this belongs in Common?

there shouldn't even be a place to put changes/patches per profile. if
a profile needs a different change (a fork) then it's already 99.9%
chance of it being wrong and someone simply not taking the time to do
it right.

we are set up to ENCOURAGE this kind of forking behavior where
different profiles just have their own forked stream of development and
ignore the others.

but right now we mix development, packaging and tizen adaption across a
bunch of forked git repos. we should have a single repo for a project -
not one per profile. we actually shouldn't do development in our tizen
git repos but as separated upstream projects. tizen should simply point
to the upstream and at worst overlay some bugfix patches and have packaging.

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] About multi-app packaging directory policy

[Carsten Haitzler]

i kind of think that it's not worth chasing. 1 app == 1 package. that is
all upgraded/installed/uninstalled together. it CAN indstall multiple
binaries (multiple executables and thus icons to launch - this one
package. it could also installl just data files or shared libs or
something else with no binaries at all).

as long as:

1. apps can be installed in $HOME as a user id by that user id with no
special root permissions we're fine.
2. apps live entirely within their directory - any symlinks to data
outside an app dir is managed by tools outside of the app itself (catch
- i might point at freedesktop.org for where to put cache and config
files like ~/.cache and ~/.config - but a bit late for that now - i'd
also have just suggested we have .desktop files... but anyway - ignore
this).
3. app install dirs can be moved anywhere in the filesystem and the app
must continue to work (if launched again there).

i think this should be sufficient. for now at least. hybrid aps will
just have to update both ends at the same time.

On 05/06/2015 03:19 PM, sangyoon jang wrote:

 Hi,

  

 I want to talk about old discussion about tizen application directory
 layout.

 As we said, the current (Tizen 3.0) directory layout is different with
 Tizen 2.x.

 (And I found that the app-installer cannot install multi-app package
 as well)

 Since we are not prepared to change directory layout, I think we
 should follow Tizen 2.x 's, for now.

 (for the compatibility also)

  

 Now the many things are changed (security policy, the installer, ...
 etc) and the 3.0 SDK is not release yet(packages are generated by SDK),

 so i think we need to discuss and clarify whether to change the
 application package directory layout policy.

  

  

 Regards,

 Sangyoon Jang

  

  

 --- *Original Message* ---

 *Sender* : Rafal Krypar.kr...@samsung.com Senior Software
 Engineer/SRPOL-Security (TP)/삼성전자

 *Date* : 2015-04-09 20:28 (GMT+09:00)

 *Title* : Re: About multi-app packaging directory policy

  

 On 2015-04-08 05:59, sangyoon jang wrote:
 Dear folks,

 It seems that the multi-app packaging directory policy is different with 
 Tizen 2.3
 According to 2.3 SDK, a sample multi-app package's directory hirearchy is 
 like this:

 .
 ├── author-signature.xml
 ├── bin
 │   └── mainapp
 │   └── subapp
 ├── lib
 ├── res
 ├── setting
 ├── shared
 │   ├── data
 │   ├── res
 │   │   └── mainapp.png
 │   │   └── subapp.png
 │   └── trusted
 ├── signature1.xml
 └── tizen-manifest.xml
 (pkgid:org.tizen.mainapp, main appid:org.tizen.mainapp, sub 
 appid:org.tizen.subapp)
 Two applications are packaged in same root directory.

 When designing application path structures for Tizen 3.0, we couldn't
 find any documents on that issue for Tizen 2.x. Is the above layout
 documented somewhere or is it just common practice in 2.3?

 But currently, app-installer(also security-manager treat as same)
 will install this package at: $HOME/apps_rw/pkgid/appid/...
 $HOME/apps_rw/org.tizen.mainapp/org.tizen.mainapp/bin/mainapp
 $HOME/apps_rw/org.tizen.mainapp/org.tizen.mainapp/bin/subapp

 The above path layout was introduced to support the following features:

  1. Allow apps inside a package to be installed, uninstalled and
 upgraded separately. The desire to do that was actually based on
 how hybrid applications worked in Tizen 2.x with WRT+OSP (two
 separate apps with the same pkgId, installed by separate installers).
  2. Isolate packages between each other by different Smack labels
 (directory TZ_USER_APP/PKG_ID has distinct Smack label assigned to
 package)
  3. Give applications sharing the package a place to share data
 (applications have full access to package label and can write to
 TZ_USER_APP/PKG_ID)


 Features 2 and 3 can be easily supported by both directory layouts
 (the 2.3 one you mentioned and the 3.0 layout). However one may expect
 issues with feature 1 in the 2.3 layout model. For example what should
 happen if two applications in a package provide the same file?

 Does anybody know whether the application directory policy is changed?
 I think that the application directory policy is not consistent now.

 The path layout for Tizen 3 was designed without knowing requirements
 from Tizen 2.3. We should reconsider it now if there is anything in
 Tizen 2.3 that relies on the old path layout.
 But it would be very beneficial to have understanding of how multi-app
 packages are going to look like. What will be their life-cycle
 (development, installation, upgrade). And whether or not wewant to
 support appliactions that are installed separately, but come with the
 same package id.

  



 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law

Re: [Dev] at-spi2-core and at-spi2-atk repos fixing and upgrading

[Carsten Haitzler]

i would agree

On 03/09/2015 11:47 PM, Patryk Kaczmarek wrote:
 Hi all,

 I want to start disscution about fixing and upgrading at-spi2-core and
 at-spi2-atk.

 Those libs which are right now in platform/core/uifw/ and do not have
 correct upstream branch.

 Those projects are fully developed and maintained outside tizen,
 that's why I think it is good idea to create new repos inside
 platform/upstream/ and deleted previous ones.

 Right now Assistive Technology people want to develop those project
 for tizen purpose so we want to clean up mess with those repos.

 I had created task on Jira for at-spi2-core
 (https://bugs.tizen.org/jira/browse/TINF-840), but still I do not know
 if it is a proper way for that.

 Regards,

 Patrick


 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] 2.3 API creeping in Tizen 3 requires coordination

[Carsten Haitzler]

On 01/09/2015 02:26 AM, Thiago Macieira wrote:
 On Thursday 08 January 2015 11:32:48 Carsten Haitzler wrote:
 What is unacceptable is not being allowed to review.

 There were multiple offers for review at the time when the APIs were being
 designed, but no opportunity for that was given. Not even to ensure
 compatibility with 3.0 needs, such as multiuser or 3-domain SMACK.

 Therefore, we still reserve the right to review. If a feature is found to
 be incompatible with a major Tizen 3 goal, it can and will be modified
 (or even removed), regardless of whether 3rd parties may be using it.
 wait a sec. you write that as if you (intel) are the sole owners of
 tizen as of 3.0 onwards - the needs of let's say tizen mobile or
 anything else that is being worked on in tizen 2 land still are
 irrelevant in your view of tizen if those needs were to clash with for
 example ivi needs.
 Hi Carsten

 This comes from the simple fact that all changes to Tizen need to be 
 reviewed. 
 Since the review was skipped in the 2.3 development process, it needs to 
 happen now. Every developer is allowed this right and the governance requires 
 it to happen.

 Compatibility with 2.3 cannot be used as a reason for accepting a broken 
 change that wasn't reviewed before. It could have been if the change had been 
 reviewed -- that would have been our collective mistake.

 That said, I don't expect this to be a big deal. Since the 2.3 development 
 process could not accept the offer of review, I expect that the development 
 redoubled its efforts to review to compensate from the lack of feedback. 
 Besides, the goals for 3.0 were known at the time (and much of it already 
 implemented!), so it's reasonable to expect that those goals were taken into 
 account in developing the 2.3 goals.

 you might want to realize that there are more people involved in tizen
 than just intel and the needs of others matter too. what you are saying
 is that, for example, multiuser needs of ivi trump the needs of mobile
 and you will use the tizen review process to enforce that. that is the
 tone of your email.
 No, that's not what I am saying at all. I was specifically saying that Mobile 
 needs *don't* trump IVI needs. I was fearing that 2.3 compatibility would 
 be 
 used as an excuse to break what has been done.

but you were saying that ivi needs DO trump mobile (for example). that
multiuser as a feature (a requirement for ivi), is reason enough to
break compatibility for 3rd party mobile developers. that an api can be
removed (thus breaking compat) if it were to make ivi multiuser
break/have problems etc.

 In fact, I am saying that multiuser needs of IVI deserves the *exact* same 
 respect and attention as the mobile needs. The multiuser support was reviewed 
 and discussed before being accepted. Therefore, all other changes to Tizen 
 Mobile 3.0 need the same.

 So this is simply what Dominique was asking for: visibility of the changes so 
 that they can be properly reviewed by anyone interested.

but that is not what your prior email said. what you say now makes
sense, but it comes with a gotcha. changing apis (removing, modifying
names, arguments or functionality that would break what they are
documented to do that developers rely on), is not something you can just
decide to do arbitrarily because it may break another feature. you did
say it WILL be broken (modified or even removed) if a conflict is found,
and that is making a statement of decision already that compatibility is
irrelevant to you when it comes to tizen development vs goals.

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] 2.3 API creeping in Tizen 3 requires coordination

[Carsten Haitzler]

On 01/07/2015 05:31 PM, Dominig ar Foll (Intel OTC) wrote:
 Suchan,

 I will take the Yocto alignment as an example as it's very close to
 your need.

 If you log in Tizen jira (your ID and passwd are your default Tizen
 ID). You will be able to use the filter bellow.
https://bugs.tizen.org/jira/issues/?filter=14499

 That filter simply list all the tasks and issues entered in Jira with
 label Yocto.
 Label, in jira are free text which ease grouping of activities. It's
 not required but makes life easier.

 If I take TC-2239 as example (makedepend: bump to version 1.0.5). You
 will notice that it is listed as a feature rather than a bug. To be
 honest that is a details but it help to keep our stats and the process
 clean
 I see in the description which is was blocking the generic feature
 TC-1964 (Yocto Build of Tizen). This is case for all the tasks related
 to the alignment of Tizen and Yocto.

 It allows, when you look at the generic feature TC-1964 to see what is
 the progress of all sub tasks. In short, it creates an automatic
 Dashboard.
   https://bugs.tizen.org/jira/browse/TC-1964
 Status usage is pretty simple :
   - New  No one is yet assign as has looked  to it.
   - Accepted  We have assigned someone and we should have an
 estimated date for completion entered (not always the case).
   - Resolved  The developer has done the work and Git/Gerrit Tag
 given in the comments allows to locate the work.
   - Released  The RE has integrated the work in the image and
 tests are OK.
 For more details on the feature work flow (a bit different of the
 issue/bug workflow) get a look at :
 https://bugs.tizen.org/jira/plugins/servlet/workflow/thumbnail/getThumbnail?workflowName=TizenTaskWorkflowSimple1stepId=3width=fullheight=full


 So in your situation, you need to create a generic Tasks which
 describe what and why you need to back port 2.3 API. Ideally you want
 to list an email in the public mailing list toward a discussion which
 has accepted the new feature (remember a No comment on a proposition
 is equivalent to a Yes: Consent is by default).
 Please note that the communication on the Dev mailing list on the What
 and Why has not been done yet and is urgently needed.

by now it's a bit late - the api's are set in stone and the commits
related to this thread are simply mechanically pushing them in.

any review/discussion should be happening at the stage when new api's
are designed/decided. imho tizen is not the forum for that. each of
these tizen native/core libraries is basically an upstream project of
its own - it just so happens that right now that project lives in the
tizen 2.3 branches/repos/trees.

we really should treat each unit of tizen as a project - be it systemd,
xorg, wayland, kernel, efl, core api libs, buxton or anything else.

relevant people from tizen core should be involved in the relevant
projects based on their domain experience/interests etc. reviews,
debates and approval of changes like apis or features should be done
long before it comes into tizen.

 Then you create a (sub) task for each package which needs work to
 implement your global task and you mark each of them as a blocker for
 your generic Task (yes that part is a bit of a pain).
 Then you follow the work flow for each sub tasks putting comment when
 needed (in particular Gerrit commit ID) and change the status when
 applicable.

 Any one can follow your progress status by looking at the generic
 feature. Once all done, mark the generic feature as Released.

 If you need more help or info, please let us know.

 Regards

 Dominig ar Foll
 Senior Software Architect
 Open Source Technology Centre
 Intel SSG

 Le 07/01/2015 06:57, 우수창 a écrit :
 Dear Dominig,

 As you've been noticed, we are merging Tizen 2.3 codes to 3.0 git
 repositories to provide v2.3 APIs.
 We are not familiar with the process of an open source Tizen
 development.
 So, could you let me know the details? Are there any documents which
 we can refer to?

 You mentioned that we have to open a Jira ticket for each change.
 Is a Jira ticket an issue which has a Task type in bugs.tizen.org?
 There are many projects in bugs.tizen.org. Which project do we create
 a Jira ticket on?

 Regarding the test cases which you mentioned,
 Could you give me an specific example? I tried to find an example but
 I can't.
 If we know how QA test modules, we can provide the test cases.

 Thanks,
 Suchang.

 --- Original Message ---
 Sender : Dominig ar Foll (Intel OTC)dominig.arf...@fridu.net
 Date   : 2015-01-06 20:30 (GMT+09:00)
 Title  : [Dev] 2.3 API creeping in Tizen 3 requires coordination

 Hello,

 we noticed that several new reviews are about to get in Tizen 3 relative
 to 2.3 API.
 see as example (not a complete list) ;
  https://review.tizen.org/gerrit/33153
  https://review.tizen.org/gerrit/33151
  https://review.tizen.org/gerrit/33150
  https://review.tizen.org/gerrit/33111
  

Re: [Dev] Question about sdb root on failed with permisson denied when connectiong to Gear S

[Carsten Haitzler]

On 12/24/2014 01:37 AM, Schaufler, Casey wrote:
 -Original Message-
 From: Dev [mailto:dev-boun...@lists.tizen.org] On Behalf Of Carsten
 Haitzler
 Sent: Tuesday, December 23, 2014 5:45 AM
 To: Li, Hao H
 Cc: dev@lists.tizen.org
 Subject: Re: [Dev] Question about sdb root on failed with permisson denied
 when connectiong to Gear S

 On Mon, 22 Dec 2014 03:17:46 + Li, Hao H hao.h...@intel.com said:

 Could you help to list your ps aux and let me know the process of home UI
 Can you make that ps auxZ please?

too late. going to have to wait until next year. there is no way i'll
have time tonight or until next year.
 in
 your Gear2?
 http://sprunge.us/FRBK

 From: Carsten Haitzler [mailto:c.haitz...@samsung.com]
 Sent: Monday, December 22, 2014 11:16 AM
 To: Li, Hao H; dev@lists.tizen.org
 Subject: Re: [Dev] Question about sdb root on failed with permisson
 denied
 when connectiong to Gear S

 i don't know - i don't have a gear s, but on my gear 2 - i have a rooted os
 image... and it works. :) (sdb root is on...) On 12/22/2014 12:11 PM, Li, 
 Hao
 H wrote: So is there any way to see the running process like home UI or
 weather etc in Gear S? After running some apps like weather, setting etc, I
 just sdb -d shell and then ps aux but I don't find the relate process. Do 
 you
 know how I can see it?

 Thanks!

 From: Dev [mailto:dev-boun...@lists.tizen.org] On Behalf Of Carsten
 Haitzler
 Sent: Monday, December 22, 2014 11:09 AM
 To: dev@lists.tizen.orgmailto:dev@lists.tizen.org
 Subject: Re: [Dev] Question about sdb root on failed with permisson
 denied
 when connectiong to Gear S

 like android devices - no root for you on tizen. there is no eay to resolve
 it. thats how production devices come.

 unless you root your device. ie hack around security and find an exploit to
 do it with... or hack up your own tizn image with sdbd setuid root (i think
 thats how it's done from memory). On 12/22/2014 11:55 AM, Li, Hao H
 wrote: Hi,
 I have connected by Gear S with Ubuntu, sdb -d shell and then whoami
 shows
 current user is developer. But when I go back to Ubuntu by root or normal
 user and then do sdb root on, it always shows Permission denied

 Does anyone know how to resolve it?

 Thanks!

 Li Hao
 Best Regards
 Email:hao.h...@intel.commailto:hao.h...@intel.com

 Software and Service Group
 Intel Asia-Pacific Research  Development Ltd.
 Tel: 86-21-61167039






 ___

 Dev mailing list

 Dev@lists.tizen.orgmailto:Dev@lists.tizen.org

 https://lists.tizen.org/listinfo/dev




 --

 The above message is intended solely for the named addressee and may

 contain trade secret, industrial technology or privileged and

 confidential information otherwise protected under applicable law

 including the Unfair Competition Prevention and Trade Secret Protection

 Act. Any unauthorized dissemination, distribution, copying or use of the

 information contained in this communication is strictly prohibited. If

 you have received this communication in error, please notify the sender

 by email and delete this communication immediately.



 --

 The above message is intended solely for the named addressee and may

 contain trade secret, industrial technology or privileged and

 confidential information otherwise protected under applicable law

 including the Unfair Competition Prevention and Trade Secret Protection

 Act. Any unauthorized dissemination, distribution, copying or use of the

 information contained in this communication is strictly prohibited. If

 you have received this communication in error, please notify the sender

 by email and delete this communication immediately.

 --
 Carsten Haitzler (The Rasterman) ti...@rasterman.com
 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev
 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev


-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Question about sdb root on failed with permisson denied when connectiong to Gear S

[Carsten Haitzler]

that's going to have to wait until i get home tonight - i don't have my
dongle/cradle thing here.

On 12/22/2014 12:17 PM, Li, Hao H wrote:

 Could you help to list your ps aux and let me know the process of home
 UI in your Gear2?

  

 *From:*Carsten Haitzler [mailto:c.haitz...@samsung.com]
 *Sent:* Monday, December 22, 2014 11:16 AM
 *To:* Li, Hao H; dev@lists.tizen.org
 *Subject:* Re: [Dev] Question about sdb root on failed with permisson
 denied when connectiong to Gear S

  

 i don't know - i don't have a gear s, but on my gear 2 - i have a
 rooted os image... and it works. :) (sdb root is on...)

 On 12/22/2014 12:11 PM, Li, Hao H wrote:

 So is there any way to see the running process like home UI or
 weather etc in Gear S?

 After running some apps like weather, setting etc, I just sdb –d
 shell and then ps aux but I don’t find the relate process. Do you
 know how I can see it?

  

 Thanks!

  

 *From:*Dev [mailto:dev-boun...@lists.tizen.org] *On Behalf Of
 *Carsten Haitzler
 *Sent:* Monday, December 22, 2014 11:09 AM
 *To:* dev@lists.tizen.org mailto:dev@lists.tizen.org
 *Subject:* Re: [Dev] Question about sdb root on failed with
 permisson denied when connectiong to Gear S

  

 like android devices - no root for you on tizen. there is no eay
 to resolve it. thats how production devices come.

 unless you root your device. ie hack around security and find an
 exploit to do it with... or hack up your own tizn image with sdbd
 setuid root (i think thats how it's done from memory).

 On 12/22/2014 11:55 AM, Li, Hao H wrote:

 Hi,

 I have connected by Gear S with Ubuntu, sdb –d shell and then
 whoami shows current user is developer.

 But when I go back to Ubuntu by root or normal user and then
 do sdb root on, it always shows “Permission denied”

  

 Does anyone know how to resolve it?

  

 Thanks!

  

 Li Hao

 Best Regards

 Email:hao.h...@intel.com mailto:hao.h...@intel.com

  

 Software and Service Group

 Intel Asia-Pacific Research  Development Ltd.

 Tel: 86-21-61167039

  





 ___

 Dev mailing list

 Dev@lists.tizen.org mailto:Dev@lists.tizen.org

 https://lists.tizen.org/listinfo/dev




 -- 

 The above message is intended solely for the named addressee and may

 contain trade secret, industrial technology or privileged and

 confidential information otherwise protected under applicable law

 including the Unfair Competition Prevention and Trade Secret Protection

 Act. Any unauthorized dissemination, distribution, copying or use of the

 information contained in this communication is strictly prohibited. If

 you have received this communication in error, please notify the sender

 by email and delete this communication immediately.



 -- 
 The above message is intended solely for the named addressee and may
 contain trade secret, industrial technology or privileged and
 confidential information otherwise protected under applicable law
 including the Unfair Competition Prevention and Trade Secret Protection
 Act. Any unauthorized dissemination, distribution, copying or use of the
 information contained in this communication is strictly prohibited. If
 you have received this communication in error, please notify the sender
 by email and delete this communication immediately.

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Question about sdb root on failed with permisson denied when connectiong to Gear S

[Carsten Haitzler]

On 12/22/2014 12:09 PM, Carsten Haitzler wrote:
 like android devices - no root for you on tizen. there is no eay to
 resolve it. thats how production devices come.


gee that's typo land. i shouldnt write mails while talking with other
people.

like android devices - no root for you on tizen. there is no easy way to
resolve it. that's how production devices come.

 unless you root your device. ie hack around security and find an
 exploit to do it with... or hack up your own tizn image with sdbd
 setuid root (i think thats how it's done from memory).

 On 12/22/2014 11:55 AM, Li, Hao H wrote:

 Hi,

 I have connected by Gear S with Ubuntu, sdb –d shell and then whoami
 shows current user is developer.

 But when I go back to Ubuntu by root or normal user and then do sdb
 root on, it always shows “Permission denied”

  

 Does anyone know how to resolve it?

  

 Thanks!

  

 Li Hao

 Best Regards

 Email:hao.h...@intel.com mailto:hao.h...@intel.com

  

 Software and Service Group

 Intel Asia-Pacific Research  Development Ltd.

 Tel: 86-21-61167039

  



 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev

 -- 
 The above message is intended solely for the named addressee and may
 contain trade secret, industrial technology or privileged and
 confidential information otherwise protected under applicable law
 including the Unfair Competition Prevention and Trade Secret Protection
 Act. Any unauthorized dissemination, distribution, copying or use of the
 information contained in this communication is strictly prohibited. If
 you have received this communication in error, please notify the sender
 by email and delete this communication immediately.


 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] obs packages queue is too high to maintain development flow

[Carsten Haitzler]

maybe people should be buildinglocally, ont on shared servers which
easily get overloaded like this... thats why gbs exists... and yocoto/oe
lst i used it a few years back did only local builds... (nice clean pure
cross-compile ones too).

On 12/17/2014 06:31 PM, Dominig ar Foll (Intel OTC) wrote:
 Hello;

 with the addition of new profile joined to the change of some low
 level packages, we have created a dead lock within Tizen public OBS.
 At the time of writing that email 1200 packages are waiting for
 building and critical projects such as the IVI release M14.4 or
 Tizen-Yocto are stalled.

 More details and progress can be fond here :
ttps://bugs.tizen.org/jira/browse/TINF-751

 In order to help the system to regain a stable and working state,
 quite a few submissions will have to be delayed or cancelled.

 I would also propose that general submission to Tizen which is the
 default are removed and that default goes only on Common, submission
 for real profiles should be done on a specific request.
 Note that submission of a specific profile is already possible.

 Advises, hints and alternatives from the infra team for solving that
 issue are more than welcome.

 Regards


-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Forcing non agreed architecture changes is not acceptable.

[Carsten Haitzler]

On 12/11/2014 02:54 AM, Thiago Macieira wrote:
 On Wednesday 10 December 2014 13:27:54 Karol Lewandowski wrote:
 As for kdbus - it's been agreed 3.0 feature before Tizen:Common, and
 Generic were established.  Heck, it's even on official wiki page so
 please tell me why we do have to agree things that were already accepted?

   https://wiki.tizen.org/wiki/Tizen_3.0
 It was agreed when we expected that it would land in time for 3.0. It's way 
 too late for it now. Please consider Tizen 3.0 feature-frozen as we're 
 talking 
 about releasing it in the next couple of weeks.

 It looks to me that we should start the branch for Tizen 3.1 soon so you're 
 not blocked.

where is this release date documented? i have heard a mountain of tizen
3 releae dates come and go over time. there is nothing on the tizen 3
wiki indicating this. where is this officially agreed on in some formal
way? and please don't say inside some jira tickets somewhere, some email
sent (of whihc i can find none in the past few months with any subject
on tizen 3 release), or some tsg meeting minutes which aren't exactly
shared widely and prominently.

my information atm as to tizen 3 release schedules is mid 2015.

until there is clear communication and documentation on what is a
schedule (and agreement) enforcing things like a freeze are not going to
fly. it'd better be in big bold writing on the tizen 3.0 wiki for this
to be enforcable. that's a central place for this stuff.

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] [DEV][RFC] Resource management daemon

[Carsten Haitzler]

On 12/04/2014 06:03 PM, Dominig ar Foll wrote:
 Le 04/12/2014 00:49, Carsten Haitzler (The Rasterman) a écrit :
 All the Telco product that I worked on before joining Intel, use that 
 model. Checking has a cost.
 The trick is to ask for enough in one go to be able to take a decision 
 on Kernel refusal without forcing the kernel to take action by itself.
 Not that nice, but works pretty well.
 Dominig
 problem is that this won't work well on linux...
 All those products that I have in mind were running Linux.
 1. swap - if you have it the above method won't be that great
 In my experience swap is never activated on embedded critical system.

then i think this code was getting something seriously wrong.

 2. until you touch the pages (read or write) they don't exist so it will have
 no impact
 I have not checked that detail with latest kernel. but is use to be that
 when the kernel was giving you the allocation, the RAM was there.
 Remember tha tI assume that there is no swap.

so last i checked, linux overcommit was enabled by default. so unless
you disable it:

cat /proc/sys/vm/overcommit_memory

to see if it is on or not (1 or 0).

linux will allow you to allocate as much as you like:

 6:14PM ~  free -m   
  totalusedfree  shared  buff/cache  
available
Mem:   38671684 158 247   
20241653
Swap: 0   0   0

my sample code:

#include stdio.h
#include string.h
#include unistd.h
#include stdlib.h

int main(int argc, char **argv)
{
   size_t size = atoi(argv[1]);
   void *ptr = malloc(size * 10124 * 1024);
   printf(malloc result = %p\n, ptr);
   return 0;
}

and me running it:

 6:14PM ~  ./tt 1
malloc result = 0x7fc5b0a37010

i just allocated 10gb... on a machine with only 4gb of physical ram
(only 3.8 total usable) and only 1.7g or so actually available given
existing memory usage... and zero swap to spill over into. how is it
possible to allocate 10g on this machine? overcommit. if i were to now
walk through this memory and read/write to each and every page.. the
kernel will be forced to ACTUALLY realize the alocation. once i end up
touching about 1.6gb of memory... it'll actually crash as that memory
doesn't actually exist at all even though allocation succeeded.

there is a reason overcimmit exists.

1. lots of apps allocate memory and then only use some of it. via malloc
or mmap or brk or sbrk (heap/stack). so forcing the real memory to exist
for all of it is a waste

2. biggest reason - fork().

since fork makes a COPY of the current process in a new one. let us
asume we have a machine with 4gb ram.. and i have a process using 2.5g
of ram (no swap)  that simply wishes to fork+exec some binary. the first
thing it does after a fork is a simple exec. you cannot do this. the
fork will fail unless you overcommit. why? by definition the child could
dirty (write to) any pages it has and cause a copy-on-write and thus the
kernel MUSt ensure the memory exists for theat copy-on-write to happen.
even if all that happens now is exec() .. it coudl be a ssimpel as
execcing ls... just from a large binary. this is also commonly the
case with apache where it forks off a lot of slaves.

 3. a malloc won't give you linear/continuous memory. either will a mmap etc.
 unless it's a specialized device guaranteeing that (i know of no general 
 device
 providing that)
 4. due to linux doing overcommit to ensure we don't waste lots of memory any
 allocation is never guaranteed. you can turn this off, but then you basically
 need a chunk more real memory to make up for it. i might guess 50% to 100%
 more

 you really need the kernel to give userspace more information.
 Kernel certainly has a better and more detailed view but you still need
 to extract that information to take decision in time.



-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] [RFC] AUL UI request for multi-process applications (ICO/Crosswalk...)

[Carsten Haitzler]

this sounds like it's all co-operative. since an app itsdelf determines
via metadata (manifest) what its purpose is. i assume you could
download/replac your reverse camera app with another one, (maybe it's
better at guiding you into parking spots?), so in the end it's really up
to the developer to identify the class of app.

but an app may have more than one window. one window may play video -
another may not. so don't use manifest. use window properties. in x11
it'd be some extended atoms you add indicating window purpose - in
wayland, a protocol extension to do that to a surface. the compositor
would then decide what gets displayed or hidden based on these
properties. the compositor would know/track current state (reversing,
moving, still etc.) and enforce this policy. this is the correct solution.

On 11/27/2014 05:42 PM, Puustinen, Ismo wrote:
 Hi Casey,

 In IVI domain the car manufacturers may want to place regulations that
 limit the applications that can be shown on the screen in different car
 use cases. For instance:

 * When the car is moving, applications that play video are not allowed
 on the screen.
 * When the car is in reverse gear, the application that shows reverse
 camera video must be shown on the screen.
 * When the car is not moving, all applications are allowed on the
 screen.

 You can easily think up a large number of possible use cases such as
 these ones.

 It's easy to enforce similar audio policies since we have a pretty
 good idea who is playing audio to PulseAudio. In order to do such screen
 policy enforcement (even in collaborative way, when the application is
 announcing it's true capabilities in the manifest file) we have to
 somehow know which surface belongs to which application.

 Ismo


 On Wed, 2014-11-26 at 17:00 +, Schaufler, Casey wrote:
 Why does the package name get used to determine if a window gets
 displayed? What policy do you really want to enforce? There has got to
 be a less convoluted way to get what you want than this.

  

  

 From: Dev [mailto:dev-boun...@lists.tizen.org] On Behalf Of Manuel
 Bachmann
 Sent: Wednesday, November 26, 2014 5:10 AM
 To: dev@lists.tizen.org
 Subject: [Dev] [RFC] AUL UI request for multi-process applications
 (ICO/Crosswalk...)


  

 Hi folks,


 This RFC is about bug TC-1691, TC-159...


  


 (The problem happens with Crosswalk today, but it could happen with
 any other application)


 AUL provide somes function calls, like  aul_app_get_pkgname_bypid
 (), which permit to get the application package name associated with
 a running PID.


 Under IVI, the ICO Homescreen (profile/ivi/ico-uxf-homescreen) uses
 these calls to determine if it should show a window, by getting the
 PID of its process, and then comparing it will the package name. If if
 does not match, the window stays hidden.

 The problem is :


 In Crosswalk, the process which creates the window (the GPU process)
 is *not* the same that the one (the browser process) which registers
 itself as a Tizen application.


 Crosswalk has a dedicated process for UI operations, which is
 different of the one that does the application logic.
 So, the name is never found, and Web applications never show.


  


 In this respect, we need a way for an application to pass its
 application identifier to the graphical layer (in this case, ICO).Here
 are 2 options :

 1) in Crosswalk itself, have a package name passed from application
 layer to the UI/GPU one (won't probably be upstream). Then, have a
 Weston plugin receive and store the information. When requested by
 the aul_app_get_pkgname_bypid () call, AUL will also request the
 plugin for this information and respond.


  Requires modifications in : 3 packages (crosswalk, weston, aul-1)


  


 2) in Crosswalk itself, have a package name passed from application
 layer to the UI/GPU one (won't probably be upstream). Then, store this
 data in a local database or specific tmpfs.  When requested by the
 aul_app_get_pkgname_bypid () call, AUL will also request this base
 or tmpfs for this information and respond.


  Requires modification in : 2 packages (crosswalk, aul-1)


  


 The 2nd idea modifies less packages but may be trickier to implement.
 Any opinion on this ?




 -- 

 Regards,

 Manuel BACHMANN
 Tizen Project
 VANNES-FR


 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev
 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev


-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this 

Re: [Dev] Packages alignment between Tizen and Yocto which version to use.

[Carsten Haitzler]

On 11/27/2014 07:14 PM, Łukasz Stelmach wrote:
 It was 2014-11-27 czw 10:38, when Carsten Haitzler wrote:
 On Thu, 27 Nov 2014 08:09:50 +0100 Kévin THIERRY
 kevin.thie...@open.eurogiciel.org said:
 On 11/27/2014 12:18 AM, Carsten Haitzler (The Rasterman) wrote:
 does this mean we are dropping GBS then as we'll build with OE?
 Yes but OBS build will still be supported as an alternative. I'm not 
 sure if GBS will still be supported but it can make sense since OBS is 
 still supported...
 why bother? the OE build is a clean proper cross-compile build with no need
 for qemu or misc binary emulation... no root needed. :) much nicer.
 In my experience there is a price to pay for it. It's harder to make
 such build modular and create packages.

yes. correct... but.. OE have already done that work for us. :) at least
for everything that comes from OE.. and if most comes from OE.. just fix
up what's left. :)

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.




signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Tizen 2.3 native API and services with their own event loop.

[Carsten Haitzler]

On 11/26/2014 08:52 PM, José Bollo wrote:
 Le mercredi 26 novembre 2014 à 20:01 +0900, Carsten Haitzler a écrit :
 On Wed, 26 Nov 2014 11:40:01 +0100 José Bollo 
 jose.bo...@open.eurogiciel.org
 said:

 Hi all,

 Congratz to you Carsten for putting the feets in the
 course (translation of a french expression meaning going into
 embarassant discussion). That is great to read! And I fully agrre with
 you that there is something weird.

 However, (please, correct me if I'm wrong) there is at least one
 recurring problem with event loops when your are using libraries (like C
 API of tizen 2.3 native progtramming libraries) that should access
 ressources provided by an event loop.

 These libraries don't know what is the event loop you chosen. It rather
 use an event loop API and expects that it works. There is no cool
 solution to solve this problem. A common solution is to use the GLIB
 event loop primitive while providing a GLIB loop integration in common
 event loops, like in ecore.
 that is one way. but it is a fairly big assumption to assume there is alwasy 
 a
 glib mainloop. efl has it as a build option, but it's not guaranteed. there 
 is
 a call - ecore_main_loop_glib_integrate() that returns true if glib is
 integrated (at runtime) and false otherwise. (it will also enable integration
 if not aleady enabled). this only will work if it's compiled with the support
 though. it'd always fail (return false) if not. at least libraries can 
 detect.

 there are some gotchas. for example efl has things like ecore_poller()s. 
 these
 are intended for polling and minimizing wakeups .. if this is needed. they 
 can
 be allowed to be fuzzy - eg not go off at an exact time and instead be
 deferred until some more desired time. efl can automatically mess around with
 these, but it can't do anything with glib.

 efl has animators (last i knew glib didn't). these are callbacks that are
 called per frame. when they are called may vary on vsync (if screen is 
 70hz,
 animators go off at 70hz - exactly at vblank interrupt time with the ecore
 mainloop wakeup timepoint set to EXACTLY the time when the hardware 
 interrupt
 fired to generate the vblank interrupt, even if called later). if glib is 
 used
 then you totally drop the support for vsync based animation for example.

 efl also has thread marshalling constructs that handle a thread worker pool 
 for
 you and marshal results back to the mainloop calling their callbacks there
 (makes it really easy to isolate thread work and cleanly get results without
 nasty locks everywhere). also stuff like locks on the mainloop, so if you 
 have
 a thread that needs to do things to the ui (or whatever) in the mainloop, and
 you don't want to handle async marshallling of results back, but want to
 implement the results inline you can do an ecore_thread_main_loop_begin() 
 and
 ecore_thread_main_loop_end() around your critical section to ensure you have 
 a
 lock on the mainloop for those lines of code.

 there are a whole bunch of other mainloop callback constructs in efl that 
 don't
 exist in glib (last i knew - correct me if i'm wrong), like idle enterers and
 exiters (glib has idlers to call while idling in a tight loop).

 so assuming glib as the mainloop will limit what you can do by a fair degree
 (and cause you to likely re-invent some of the above yourself in your code, 
 or
 simply be unable to do things like the mainloop lock begin/end from a 
 thread).
 I agree that from your description, efl has many advantages. Using glib
 implies the greatest common denominator that is not much.

 so we could assume glib as a base - but then it comes with the above problems
 at a minimum. and yes - i agree that it is a problem for apps and all the
 libraries to not know what their mainloop infra is and depend on it (and 
 re-use
 it as much as possible to save code/effort and behave as well as possible).
 Yes, being agnostic, refusing to choose are some of the drawbacks of
 using linux. For example: Q: Do you know libevent? I believe that it is
 used in chromium. A: What? Oh yes! It's just yet another dispatch
 loop 

yeah. there is no standard we all agree on. if there was a standard
event loop at the libc level - then we'd all use it. instead everyone
makes a new one. the slight problem is that each event loop lib in the
past prettymuch also comes with a bunch of baggae too - eg data
structures and other utilities too. and thats when peole begin to disagree.

the best we can do is that if you make a 3rd party lib - make sure it
CAN be integrated into an event loop. it's the job of whoever uses that
lib to integrate it. a bunch of bits of efl do exactly this - they
wrap a lib and integrate it into the mainloop. the lib is still used,
just efl providing the integration and marshaling. i suspect this kind
of solution is the best option we have.

as for apps - they will need to integrate into some mainloop - they need
to assume one somewhere and i guess.. whatever mainloop

Re: [Dev] Question about /etc/profile.d/dbus.sh

[Carsten Haitzler]

session bus is the wrongplace for this as the xserver runs outside the
session (as root) normally. it is part of the infra to HOST a session,
but not quite part of it (one example would be x spawned by lightdm/xdm).

so in the generic sense, this is kind of wrong.

i'm kind of surprised that you used dbus protocol? i might have gone by
creating an x extension and then it's be directly tied to the display
itself (as you connect to it). like a wm or compositor - you conenct and
then set debug up and get debug events like x events etc. as it's x11
specific this would have been my go. give xcb protocol files and xcb
extension code generation, this should have not been hard.  but too late
now.

On 11/04/2014 05:05 PM, Boram Park wrote:
 Hi

 On 11/04/2014 02:49 AM, St챕phane Desneux wrote:
 Hi Boram,

 Could you, please, elaborate a little bit on the problem you're facing.
 During developing our project, we(samsung) faced many issues which
 were difficult to be analyzed in application side. So to analyze them
 in xserver side powerfully and conveniently, we have developed
 xf86-module-xdbg. xf86-module-xdbg consists of two parts. One is the
 module(libxdbg.so) which is loaded during xserver is launching, and혻
 another is a executable command(xdbg) which communicates with the
 module(libxdbg.so) by using DBUS system bus. By using xdbg with root
 right, we can trace x request, event, reply and error between xserver
 and xclients.

 However, when I tried to launch another second xserver, xdbg module
 got failure when calling dbus_bus_get because xdbg uses one request
 name(connection name?), previous xserver use .

 To solve this issue, looks like xdbg needs to use different request
 names for each xserver.
  - name like .xdbg-{display number}

 But if request name isn't fixed, I can't use bus configuration file in
 /etc/dbus-1/system.d/. (I'm not expert. If wrong, correct me. :) )

 So I was thinking about session bus.

 Technically, as long as Xorg is launched inside a user session it will
 have the DBUS_SESSION_BUS_ADDRESS set by systemd, as explained Maciej
 previously.

 NB: for weston, if weston-launch is used, it's not true as weston-launch
 clears the environment before forking weston and thus doesn't propagate
 the DBUS_SESSION_BUS_ADDRESS. My patch would also handle this corner
 case; but it wasn't its main goal...

 Well, this leaves me with 2 questions, regarding a multiuser system:

 * why would we want to start xorg in a user session ? There's often only
 one GPU and the users must be able to share it :)
 As my understanding, we can launch xserver more than one ideally. One
 of the ways launching Xorg is that user can call xorg-launch-helper in
 user session. And xorg-launch-helper starts Xorg with root right. So
 above issue can be potential problem.

 * if it was started as a system component, why does Xorg would need to
 know the DBUS session address (of a particular user) ? 'app' is dead, so
 which user are we talking about ? I hope it's not 'guest' :)
 For these reason, I was trying to use session bus in xserver side.
 If you look at Tizen:Common/wayland images, you'll see that weston is
 started as a system daemon and by no way it's aware of DBUS session
 address(es). If we must make it aware of the user sessions, it could be
 interfaced with logind (or tlm, or whatever handles the user
 sessions)...
 I'll trying to other way not using session bus and your recommend also.

 Thanks

 Best regards,

 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Is it possible to access tizen.org?

[Carsten Haitzler]

try accessing it outside of samsung's network.

i bet you its the proxies that decrypt and re-encrypt  it's now causing
issues security-wise (which it fundamentally is by playing
man-in-the-middle which security like ssl is meant to stop).

On 11/03/2014 09:36 AM, Boram Park wrote:
 Dear ALL.

 I can't access https://www.tizen.org. It shows me only This webpage
 is not available message.
 Does it happen to only me? or do you also have same problem?


 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] enlightenment support wayland

[Carsten Haitzler]

e compositor right now doesnt support drm (egl) client buffers. just
shm. so shm clients should be ok. all elm apps can be either shm or egl
wayland clients. other toolkits/apps - not sure.

On 08/28/2014 03:40 PM, Wang, Yan wrote:

 Again, I have set the following:

 export E_WL_FORCE=drm

 export ELM_DISPLAY=wl

 export ELM_ACCEL=opengl

  

 I haven’t tested  ELM examples so far.

  

 Yan Wang

  

 *From:*Dev [mailto:dev-boun...@lists.tizen.org] *On Behalf Of *Wang, Yan
 *Sent:* Thursday, August 28, 2014 2:36 PM
 *To:* gl77@samsung.com; Dominig ar Foll (Intel OTC);
 dev@lists.tizen.org
 *Subject:* Re: [Dev] enlightenment support wayland

  

 Hi, All,

   Just I tried e_comp_wl based on README.wayland in Enlightenment
 upstream on my Fedora 20.

   We could run enlightenment by ./enlightenment_start and found
 wayland socket in /run/user/1000/e-yanwang@XXX. And some applications
 (e.g. calculator of Fedora 20 but terminal not) could run.

   But I couldn’t run Weston sample application like
 Weston-simple-egl even if I change XDG_RUNTIMR_DIR from /run/user/1000
 to /run/user/1000/e-yanwang@XXX. It reports the following:

 weston-simple-egl: clients/simple-egl.c:151: init_egl: Assertion `ret
 == 1' failed.

 Aborted (core dumped)

   It seems that EGL initialization is failed. May I miss some
 necessary steps?

   BTW, Weston could run and Weston-simple-egl could run on it rightly.

   Thanks.

  

 Yan Wang

  

 *From:*Dev [mailto:dev-boun...@lists.tizen.org] *On Behalf Of *Wang, Yan
 *Sent:* Thursday, August 28, 2014 10:20 AM
 *To:* gl77@samsung.com mailto:gl77@samsung.com; Dominig ar
 Foll (Intel OTC); dev@lists.tizen.org mailto:dev@lists.tizen.org
 *Subject:* Re: [Dev] enlightenment support wayland

  

 Hi, Gwanglim,

 Thanks for your information.

 I will try the upstream on Linux Desktop first.

  

 Yan Wang

  

 *From:*Gwanglim Lee [mailto:gl77@samsung.com]
 *Sent:* Wednesday, August 27, 2014 10:37 PM
 *To:* Dominig ar Foll (Intel OTC); Wang, Yan; dev@lists.tizen.org
 mailto:dev@lists.tizen.org
 *Subject:* Re: Re: [Dev] enlightenment support wayland

  

 Hi Yan,

  

 We are trying to enable enlightenment wayland server and EFL for Tizen
 Common/mobile platform.
 But now, we are working on upstream.
 https://git.enlightenment.org/core/enlightenment.git/
 https://git.enlightenment.org/core/enlightenment.git/
 You can see current upstream enlightenment has no x dependency if it
 is building with wayland-only version.
 We are going to merge it to tizen common when it is stable.

  

 BR,
 Gwanglim

  

 --- *Original Message* ---

 *Sender*: Dominig ar Foll (Intel OTC)dominig.arf...@fridu.net
 mailto:dominig.arf...@fridu.net

 *Date*: 2014-08-27 23:34 (GMT+09:00)

 *Title*: Re: [Dev] enlightenment support wayland

  

 Yan,

 In Tizen 3 each platform may do what it wants when it come to the
 window manager but for most embedded system Weston/XDG might be enough.




 Dominig ar Foll
 Senior Software Architect
 Open Source Technology Centre
 Intel SSG

 Le 27/08/2014 16:22, Wang, Yan a écrit :

 So as my understanding, we won't port enlightenment to the later
 (Wayland./ Weston with XDG extensions ) platform. Right?

 Best regards,

 Yan Wang

 *From:*Dominig ar Foll (Intel OTC) [mailto:dominig.arf...@fridu.net]
 *Sent:* Wednesday, August 27, 2014 9:58 PM
 *To:* Wang, Yan; dev@lists.tizen.org mailto:dev@lists.tizen.org
 *Subject:* Re: [Dev] enlightenment support wayland

 Yan,

 we have two version of Common :
   - X based with Enlightenment
   - Wayland./ Weston with XDG extensions.

 The later is the base for IVI and has no X at all (not even xwayland)
 QT, efl and Ozone have been patches to integrate XDG support.

 Regards




 Dominig ar Foll
 Senior Software Architect
 Open Source Technology Centre
 Intel SSG

 Le 27/08/2014 15:30, Wang, Yan a écrit :

 Hi,

  Thanks for your clarifying this about Tizen IVI. But for
 Tizen Common?

  I haven't tried e_comp_wl so far and could you please give me
 more detail of X legacy if possible?

 Best regards,

 Yan Wang

 *From:*Dev [mailto:dev-boun...@lists.tizen.org] *On Behalf Of *Dominig
 ar Foll (Intel OTC)
 *Sent:* Wednesday, August 27, 2014 9:17 PM
 *To:* dev@lists.tizen.org mailto:dev@lists.tizen.org
 *Subject:* Re: [Dev] enlightenment support wayland

 Yan

 to be honest there is no plan to add enlightenment in IVI yet, and we
 do not see a strong pull from  the automotive community.
 Furthermore as the current implementation still requires some X legacy
 than we do not want to see coming back in IVI, it unlikely to called
 by the IVI community in a short term.

 But t is nice to see the progress.



 Dominig ar Foll
 Senior Software Architect
 Open Source Technology Centre
 Intel SSG

 Le 27/08/2014 14:25, Wang, Yan a écrit :

 Hi,

  Just read this page:
 https://phab.enlightenment.org/w/wayland/
 https://phab.enlightenment.org/w/wayland/

  

Re: [Dev] Question about tizen wearable image

[Carsten Haitzler]

dunno. worked for me on arch at home.

On 08/28/2014 03:41 PM, Li, Hao H wrote:

 In my ubuntu, even if I connect the gear2 to PC via usb cable, sdb
 devices can’t detect the device…

  

 *From:*Carsten Haitzler [mailto:c.haitz...@samsung.com]
 *Sent:* Thursday, August 28, 2014 2:33 PM
 *To:* Li, Hao H; dev@lists.tizen.org
 *Subject:* Re: [Dev] Question about tizen wearable image

  

 i dont use windows... i also dont do html5 apps. i assume there might
 be - you do have a usb cable, a little cradle thing for the watch and
 sdb works over it (i rooted my gear2 so my sdb gives me root... i hadt
 o unpatch the silly commenting out of sdb root cmd in sdb and rebuild
 it myself... god sdb's build setup is a mess! that makefile is horrible!)

 On 08/28/2014 02:44 PM, Li, Hao H wrote:

 If I only want to install html5 wgt app to Gear2 for testing from
 Tizen wearable SDK in windows, is there any way to do it?

 Thanks!

  

 *From:*Dev [mailto:dev-boun...@lists.tizen.org] *On Behalf Of
 *Carsten Haitzler
 *Sent:* Thursday, August 28, 2014 1:00 PM
 *To:* dev@lists.tizen.org mailto:dev@lists.tizen.org
 *Subject:* Re: [Dev] Question about tizen wearable image

  

  

 On 08/28/2014 11:28 AM, Li, Hao H wrote:

 Hi

 For image
 
 http://download.tizen.org/snapshots/2.3-wearable/common/latest/images/WEARABLE/tizen-2.3-wearable_20140605.1_WEARABLE.tar.gz,
 is there any document like wiki page etc show how to burn and
 update package or install package in Samsung Gear2 device?


 go find an odin3.exe for windows (i know - shameful isn't it that
 you need windows to flash linux based tizen devices), and power on
 and keep pressing the power button multiple times quickly until
 you go into flasher mode... use button to select download, then
 use odin as above plugged into usb and it'll flash.

 one of these days someone needs to reverse enigneer that new
 flasher protocol and fix lthor to work. it's seriously painful as
 a developer. i can generate images on linux only, then have to
 xfer to windows (and let's not get into how normal corporate
 windows boxes are locked down to make this not possible).



 Thanks!

  

 Li Hao

 Best Regards

 Email:hao.h...@intel.com mailto:hao.h...@intel.com

  

 Software and Service Group

 Intel Asia-Pacific Research  Development Ltd.

 Tel: 86-21-61167039

  





 ___

 Dev mailing list

 Dev@lists.tizen.org mailto:Dev@lists.tizen.org

 https://lists.tizen.org/listinfo/dev




 -- 

 The above message is intended solely for the named addressee and may

 contain trade secret, industrial technology or privileged and

 confidential information otherwise protected under applicable law

 including the Unfair Competition Prevention and Trade Secret Protection

 Act. Any unauthorized dissemination, distribution, copying or use of the

 information contained in this communication is strictly prohibited. If

 you have received this communication in error, please notify the sender

 by email and delete this communication immediately.



 -- 
 The above message is intended solely for the named addressee and may
 contain trade secret, industrial technology or privileged and
 confidential information otherwise protected under applicable law
 including the Unfair Competition Prevention and Trade Secret Protection
 Act. Any unauthorized dissemination, distribution, copying or use of the
 information contained in this communication is strictly prohibited. If
 you have received this communication in error, please notify the sender
 by email and delete this communication immediately.

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Question about tizen wearable image

[Carsten Haitzler]

oh yeah... that too. :)

On 08/28/2014 04:02 PM, Wang, Ning W wrote:

 Hi Hao,

  

 Did you enable usb debug mode on the watch?

  

 Thanks,

 Ning

 *From:*Dev [mailto:dev-boun...@lists.tizen.org] *On Behalf Of *Li, Hao H
 *Sent:* Thursday, August 28, 2014 2:42 PM
 *To:* Carsten Haitzler; dev@lists.tizen.org
 *Subject:* Re: [Dev] Question about tizen wearable image

  

 In my ubuntu, even if I connect the gear2 to PC via usb cable, sdb
 devices can’t detect the device…

  

 *From:*Carsten Haitzler [mailto:c.haitz...@samsung.com]
 *Sent:* Thursday, August 28, 2014 2:33 PM
 *To:* Li, Hao H; dev@lists.tizen.org mailto:dev@lists.tizen.org
 *Subject:* Re: [Dev] Question about tizen wearable image

  

 i dont use windows... i also dont do html5 apps. i assume there might
 be - you do have a usb cable, a little cradle thing for the watch and
 sdb works over it (i rooted my gear2 so my sdb gives me root... i hadt
 o unpatch the silly commenting out of sdb root cmd in sdb and rebuild
 it myself... god sdb's build setup is a mess! that makefile is horrible!)

 On 08/28/2014 02:44 PM, Li, Hao H wrote:

 If I only want to install html5 wgt app to Gear2 for testing from
 Tizen wearable SDK in windows, is there any way to do it?

 Thanks!

  

 *From:*Dev [mailto:dev-boun...@lists.tizen.org] *On Behalf Of
 *Carsten Haitzler
 *Sent:* Thursday, August 28, 2014 1:00 PM
 *To:* dev@lists.tizen.org mailto:dev@lists.tizen.org
 *Subject:* Re: [Dev] Question about tizen wearable image

  

  

 On 08/28/2014 11:28 AM, Li, Hao H wrote:

 Hi

 For image
 
 http://download.tizen.org/snapshots/2.3-wearable/common/latest/images/WEARABLE/tizen-2.3-wearable_20140605.1_WEARABLE.tar.gz,
 is there any document like wiki page etc show how to burn and
 update package or install package in Samsung Gear2 device?


 go find an odin3.exe for windows (i know - shameful isn't it that
 you need windows to flash linux based tizen devices), and power on
 and keep pressing the power button multiple times quickly until
 you go into flasher mode... use button to select download, then
 use odin as above plugged into usb and it'll flash.

 one of these days someone needs to reverse enigneer that new
 flasher protocol and fix lthor to work. it's seriously painful as
 a developer. i can generate images on linux only, then have to
 xfer to windows (and let's not get into how normal corporate
 windows boxes are locked down to make this not possible).


 Thanks!

  

 Li Hao

 Best Regards

 Email:hao.h...@intel.com mailto:hao.h...@intel.com

  

 Software and Service Group

 Intel Asia-Pacific Research  Development Ltd.

 Tel: 86-21-61167039

  




 ___

 Dev mailing list

 Dev@lists.tizen.org mailto:Dev@lists.tizen.org

 https://lists.tizen.org/listinfo/dev



 -- 

 The above message is intended solely for the named addressee and may

 contain trade secret, industrial technology or privileged and

 confidential information otherwise protected under applicable law

 including the Unfair Competition Prevention and Trade Secret Protection

 Act. Any unauthorized dissemination, distribution, copying or use of the

 information contained in this communication is strictly prohibited. If

 you have received this communication in error, please notify the sender

 by email and delete this communication immediately.

  

 -- 
 The above message is intended solely for the named addressee and may
 contain trade secret, industrial technology or privileged and
 confidential information otherwise protected under applicable law
 including the Unfair Competition Prevention and Trade Secret Protection
 Act. Any unauthorized dissemination, distribution, copying or use of the
 information contained in this communication is strictly prohibited. If
 you have received this communication in error, please notify the sender
 by email and delete this communication immediately.

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] enlightenment support wayland

[Carsten Haitzler]

On 08/28/2014 04:06 PM, Wang, Yan wrote:

 Hi, Carsten,

  I tested Weston-simple-shm and get segment fault error.


what segfaulted? client or server?

  And from
 https://phab.enlightenment.org/w/wayland/elementarytest/
 https://phab.enlightenment.org/w/wayland/elementarytest/,
 wayland_egl seems available? I could see the test report of wayland egl.


thats for client-side. enlightenment as a server doesnt yetr support drm
(egl) client buffers

  I will tried elementary examples.

  Thanks

  

 Yan Wang

  

 *From:*Dev [mailto:dev-boun...@lists.tizen.org] *On Behalf Of *Carsten
 Haitzler
 *Sent:* Thursday, August 28, 2014 2:45 PM
 *To:* dev@lists.tizen.org
 *Subject:* Re: [Dev] enlightenment support wayland

  

 e compositor right now doesnt support drm (egl) client buffers. just
 shm. so shm clients should be ok. all elm apps can be either shm or
 egl wayland clients. other toolkits/apps - not sure.

 On 08/28/2014 03:40 PM, Wang, Yan wrote:

 Again, I have set the following:

 export E_WL_FORCE=drm

 export ELM_DISPLAY=wl

 export ELM_ACCEL=opengl

  

 I haven’t tested  ELM examples so far.

  

 Yan Wang

  

 *From:*Dev [mailto:dev-boun...@lists.tizen.org] *On Behalf Of
 *Wang, Yan
 *Sent:* Thursday, August 28, 2014 2:36 PM
 *To:* gl77@samsung.com mailto:gl77@samsung.com; Dominig
 ar Foll (Intel OTC); dev@lists.tizen.org mailto:dev@lists.tizen.org
 *Subject:* Re: [Dev] enlightenment support wayland

  

 Hi, All,

   Just I tried e_comp_wl based on README.wayland in
 Enlightenment upstream on my Fedora 20.

   We could run enlightenment by ./enlightenment_start and
 found wayland socket in /run/user/1000/e-yanwang@XXX. And some
 applications (e.g. calculator of Fedora 20 but terminal not) could
 run.

   But I couldn’t run Weston sample application like
 Weston-simple-egl even if I change XDG_RUNTIMR_DIR from
 /run/user/1000 to /run/user/1000/e-yanwang@XXX. It reports the
 following:

 weston-simple-egl: clients/simple-egl.c:151: init_egl: Assertion
 `ret == 1' failed.

 Aborted (core dumped)

   It seems that EGL initialization is failed. May I miss some
 necessary steps?

   BTW, Weston could run and Weston-simple-egl could run on it
 rightly.

   Thanks.

  

 Yan Wang

  

 *From:*Dev [mailto:dev-boun...@lists.tizen.org] *On Behalf Of
 *Wang, Yan
 *Sent:* Thursday, August 28, 2014 10:20 AM
 *To:* gl77@samsung.com mailto:gl77@samsung.com; Dominig
 ar Foll (Intel OTC); dev@lists.tizen.org mailto:dev@lists.tizen.org
 *Subject:* Re: [Dev] enlightenment support wayland

  

 Hi, Gwanglim,

 Thanks for your information.

 I will try the upstream on Linux Desktop first.

  

 Yan Wang

  

 *From:*Gwanglim Lee [mailto:gl77@samsung.com]
 *Sent:* Wednesday, August 27, 2014 10:37 PM
 *To:* Dominig ar Foll (Intel OTC); Wang, Yan; dev@lists.tizen.org
 mailto:dev@lists.tizen.org
 *Subject:* Re: Re: [Dev] enlightenment support wayland

  

 Hi Yan,

  

 We are trying to enable enlightenment wayland server and EFL for
 Tizen Common/mobile platform.
 But now, we are working on upstream.
 https://git.enlightenment.org/core/enlightenment.git/
 https://git.enlightenment.org/core/enlightenment.git/
 You can see current upstream enlightenment has no x dependency if
 it is building with wayland-only version.
 We are going to merge it to tizen common when it is stable.

  

 BR,
 Gwanglim

  

 --- *Original Message* ---

 *Sender*: Dominig ar Foll (Intel OTC)dominig.arf...@fridu.net
 mailto:dominig.arf...@fridu.net

 *Date*: 2014-08-27 23:34 (GMT+09:00)

 *Title*: Re: [Dev] enlightenment support wayland

  

 Yan,

 In Tizen 3 each platform may do what it wants when it come to the
 window manager but for most embedded system Weston/XDG might be
 enough.





 Dominig ar Foll

 Senior Software Architect

 Open Source Technology Centre

 Intel SSG

 Le 27/08/2014 16:22, Wang, Yan a écrit :

 So as my understanding, we won't port enlightenment to the later
 (Wayland./ Weston with XDG extensions ) platform. Right?

 Best regards,

 Yan Wang

 *From:*Dominig ar Foll (Intel OTC) [mailto:dominig.arf...@fridu.net]
 *Sent:* Wednesday, August 27, 2014 9:58 PM
 *To:* Wang, Yan; dev@lists.tizen.org mailto:dev@lists.tizen.org
 *Subject:* Re: [Dev] enlightenment support wayland

 Yan,

 we have two version of Common :
   - X based with Enlightenment
   - Wayland./ Weston with XDG extensions.

 The later is the base for IVI and has no X at all (not even xwayland)
 QT, efl and Ozone have been patches to integrate XDG support.

 Regards

Re: [Dev] enlightenment support wayland

[Carsten Haitzler]

On 08/28/2014 04:17 PM, Wang, Yan wrote:

 Client. Weston-simple-shm is crashed.


well you'd know more if you gdb'd it to find out :)

  

 *From:*Carsten Haitzler [mailto:c.haitz...@samsung.com]
 *Sent:* Thursday, August 28, 2014 3:14 PM
 *To:* Wang, Yan; dev@lists.tizen.org
 *Subject:* Re: [Dev] enlightenment support wayland

  

  

 On 08/28/2014 04:06 PM, Wang, Yan wrote:

 Hi, Carsten,

  I tested Weston-simple-shm and get segment fault error.


 what segfaulted? client or server?

  




  And from
 https://phab.enlightenment.org/w/wayland/elementarytest/
 https://phab.enlightenment.org/w/wayland/elementarytest/,
 wayland_egl seems available? I could see the test report of wayland egl.


 thats for client-side. enlightenment as a server doesnt yetr support
 drm (egl) client buffers


  I will tried elementary examples.

  Thanks

  

 Yan Wang

  

 *From:*Dev [mailto:dev-boun...@lists.tizen.org] *On Behalf Of *Carsten
 Haitzler
 *Sent:* Thursday, August 28, 2014 2:45 PM
 *To:* dev@lists.tizen.org mailto:dev@lists.tizen.org
 *Subject:* Re: [Dev] enlightenment support wayland

  

 e compositor right now doesnt support drm (egl) client buffers. just
 shm. so shm clients should be ok. all elm apps can be either shm or
 egl wayland clients. other toolkits/apps - not sure.

 On 08/28/2014 03:40 PM, Wang, Yan wrote:

 Again, I have set the following:

 export E_WL_FORCE=drm

 export ELM_DISPLAY=wl

 export ELM_ACCEL=opengl

  

 I haven’t tested  ELM examples so far.

  

 Yan Wang

  

 *From:*Dev [mailto:dev-boun...@lists.tizen.org] *On Behalf Of
 *Wang, Yan
 *Sent:* Thursday, August 28, 2014 2:36 PM
 *To:* gl77@samsung.com mailto:gl77@samsung.com; Dominig
 ar Foll (Intel OTC); dev@lists.tizen.org mailto:dev@lists.tizen.org
 *Subject:* Re: [Dev] enlightenment support wayland

  

 Hi, All,

   Just I tried e_comp_wl based on README.wayland in
 Enlightenment upstream on my Fedora 20.

   We could run enlightenment by ./enlightenment_start and
 found wayland socket in /run/user/1000/e-yanwang@XXX. And some
 applications (e.g. calculator of Fedora 20 but terminal not) could
 run.

   But I couldn’t run Weston sample application like
 Weston-simple-egl even if I change XDG_RUNTIMR_DIR from
 /run/user/1000 to /run/user/1000/e-yanwang@XXX. It reports the
 following:

 weston-simple-egl: clients/simple-egl.c:151: init_egl: Assertion
 `ret == 1' failed.

 Aborted (core dumped)

   It seems that EGL initialization is failed. May I miss some
 necessary steps?

   BTW, Weston could run and Weston-simple-egl could run on it
 rightly.

   Thanks.

  

 Yan Wang

  

 *From:*Dev [mailto:dev-boun...@lists.tizen.org] *On Behalf Of
 *Wang, Yan
 *Sent:* Thursday, August 28, 2014 10:20 AM
 *To:* gl77@samsung.com mailto:gl77@samsung.com; Dominig
 ar Foll (Intel OTC); dev@lists.tizen.org mailto:dev@lists.tizen.org
 *Subject:* Re: [Dev] enlightenment support wayland

  

 Hi, Gwanglim,

 Thanks for your information.

 I will try the upstream on Linux Desktop first.

  

 Yan Wang

  

 *From:*Gwanglim Lee [mailto:gl77@samsung.com]
 *Sent:* Wednesday, August 27, 2014 10:37 PM
 *To:* Dominig ar Foll (Intel OTC); Wang, Yan; dev@lists.tizen.org
 mailto:dev@lists.tizen.org
 *Subject:* Re: Re: [Dev] enlightenment support wayland

  

 Hi Yan,

  

 We are trying to enable enlightenment wayland server and EFL for
 Tizen Common/mobile platform.
 But now, we are working on upstream.
 https://git.enlightenment.org/core/enlightenment.git/
 https://git.enlightenment.org/core/enlightenment.git/
 You can see current upstream enlightenment has no x dependency if
 it is building with wayland-only version.
 We are going to merge it to tizen common when it is stable.

  

 BR,
 Gwanglim

  

 --- *Original Message* ---

 *Sender*: Dominig ar Foll (Intel OTC)dominig.arf...@fridu.net
 mailto:dominig.arf...@fridu.net

 *Date*: 2014-08-27 23:34 (GMT+09:00)

 *Title*: Re: [Dev] enlightenment support wayland

  

 Yan,

 In Tizen 3 each platform may do what it wants when it come to the
 window manager but for most embedded system Weston/XDG might be
 enough.






 Dominig ar Foll

 Senior Software Architect

 Open Source Technology Centre

 Intel SSG

 Le 27/08/2014 16:22, Wang, Yan a écrit :

 So as my understanding, we won't port enlightenment to the later
 (Wayland./ Weston with XDG extensions ) platform. Right?

 Best regards,

 Yan Wang

 *From:*Dominig ar Foll (Intel OTC) [mailto:dominig.arf...@fridu.net]
 *Sent:* Wednesday, August 27, 2014 9:58 PM
 *To:* Wang, Yan; dev

Re: [Dev] Question about tizen wearable image

[Carsten Haitzler]

On 08/28/2014 11:28 AM, Li, Hao H wrote:

 Hi

 For image
 http://download.tizen.org/snapshots/2.3-wearable/common/latest/images/WEARABLE/tizen-2.3-wearable_20140605.1_WEARABLE.tar.gz,
 is there any document like wiki page etc show how to burn and update
 package or install package in Samsung Gear2 device?


go find an odin3.exe for windows (i know - shameful isn't it that you
need windows to flash linux based tizen devices), and power on and keep
pressing the power button multiple times quickly until you go into
flasher mode... use button to select download, then use odin as above
plugged into usb and it'll flash.

one of these days someone needs to reverse enigneer that new flasher
protocol and fix lthor to work. it's seriously painful as a developer. i
can generate images on linux only, then have to xfer to windows (and
let's not get into how normal corporate windows boxes are locked down to
make this not possible).

 Thanks!

  

 Li Hao

 Best Regards

 Email:hao.h...@intel.com mailto:hao.h...@intel.com

  

 Software and Service Group

 Intel Asia-Pacific Research  Development Ltd.

 Tel: 86-21-61167039

  



 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Issues on converting from vconf to buxton

[Carsten Haitzler]

http://docs.enlightenment.org/auto/efl/ecore_fd_handler_example_c.html
http://docs.enlightenment.org/auto/efl/group__Ecore__Main__Loop__Group.html

:) there in tizen everywhere - even where glib is not. documented already.

but generally in efl land we don't go forcing people to do this. we
generally make thin wrappers that do this glue for people and then glue
in any callback work and other stuff so they work/look/appear to fit in. :)

On 08/22/2014 07:16 PM, Semun Lee wrote:

 Thanks for guide about buxton.

  

 However, I worry about that developers should register the fd of
 buxton to the main loop of a program.

 Most programs in Tizen use g_main_loop as its main loop, so, it may be
 very useful if there is a simple api for registering buxton fd to the
 g_main_loop.

  

 What do you think about it?

  

 Best regards,

 Semun

  

 *From:*Peters, Brad T [mailto:brad.t.pet...@intel.com]
 *Sent:* Thursday, August 21, 2014 6:12 AM
 *To:* Semun Lee
 *Cc:* Tizen Dev
 *Subject:* Re: [Dev] Issues on converting from vconf to buxton

  

 What is Buxton and how can I use it? 

  

 Should it replace our use of vconf?

  

 I have uploaded A Brief Guide to Buxton to the public Tizen wiki, which 

 should answer these questions, and more.

  

https://wiki.tizen.org/w/images/e/e9/ABriefGuidetoBuxton.pdf

  

 Note there is also a Wiki page for Buxton, which provides a high-level
 overview of Buxton.

  

https://wiki.tizen.org/wiki/Buxton

  

 We'll be providing a sample conversion of the FLIGHT_MODE vconf key,
 as used in a Tizen 2.2 RD PQ image.

 Though I would have loved to provide these sample conversions in a 3.0
 environment, the only 3.0 Tizen image

 I have access to is IVI, which does not use vconf. Thus, not a
 particularly good demonstration project ;)

  

 Please use the resources provided, and let me know if there are questions.

  

 Best regards,

 Brad Peters
 Intel Tizen Mobile Development Lead

and AppFW Architect

  

 On Mon, Aug 11, 2014 at 10:37 AM, Peters, Brad T
 brad.t.pet...@intel.com mailto:brad.t.pet...@intel.com wrote:

 Hi Semun,

  

 This is a valid point and a good idea. We're currently working to put
 together several demonstration projects which have been fully
 converted.  A guide like you suggest would go well with these. I'll
 start putting such a document together, and have something out towards
 end of week.

  

 Best regards,

 -Brad Peters

  

 Best 

  

 On Mon, Aug 11, 2014 at 3:11 AM, Semun Lee sm79@samsung.com
 mailto:sm79@samsung.com wrote:

 Hi folks,

  

 There are hundreds jira issues about converting from vconf to buxton.

 Is there any guide in detail for this issue?

 I think we need a guide to convert from vconf to buxton coherently.

  

 Best regards,

 Semun


 ___
 Dev mailing list
 Dev@lists.tizen.org mailto:Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev

  

  



 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Disabled Mouse Cursor in Tizen 2.2

[Carsten Haitzler]

On 08/13/2014 03:46 PM, 박성진 wrote:
 I didn't mean that if we enable S/W cursor in xserver, moving mouse will 
 cause damage events even now.

oh... thats what i thought you said... and that WOULD be very broken. :)

 In history, we had met the UI rendering performance degradation in Xserver 
 when we turned on S/W cursor.

yeah - this is a bi-product of how x does sw cursors. honestly x in this
regard is BRAIN DEAD! it seriously needs a kick in the rear when it
comes to sw cursors, and has needed one for 20 years. (it just overdraws
cursor and any draws that intersect cursor rect then has x redraw cursor
on top again - thus flickering horribly). it SHOULD clip away rendering
for the cursor rect area, draw to tmp offscreen buffer just that region
after the rest, composite cursor on top then copy to fb. but it doesn't. :(

one thing that would be smart is if it scanned the pixels in the cursor
bitmap/pixmap and if they are all transparent, then just turn off cursor
handling entirely. this would be better than your disable sw cursors
entirely hack. :) it'd cover the majority case of wanting cursor
off/invislbe withotu the side-effect of disabling all cursors in sw when
they are actually needed. :)

 Thus someone had disabled S/W cursor and after that, we used to use H/W 
 cursor in mobile. : )

 --- Original Message ---
 Sender : 하이츨러c.haitz...@samsung.com  수석/차세대Computing Lab(S/W센터)/삼성전자
 Date   : 2014-08-13 14:59 (GMT+09:00)
 Title  : Re: [Dev] Disabled Mouse Cursor in Tizen 2.2


  
 On 08/13/2014 12:39 PM, 박성진 wrote:
 Hello.
 as I remember, in Tizen 2.2 mobile, SW cursor has been disabled by default 
 inside Xserver.
 Using SW cursor in Xserver will make damage events as the cursor needs to be 
 updated.
 This can be tightly coupled with UI rendering performance.
 Thus the mouse cursor won't be shown even if the proper cursor image has 
 been set by enlightenment window manager,
 sw cursor causes damages? really? wow! thats... all kinds of wrong!

 If you want to display mouse cursor, you can do one of the followings:
 - implement H/W cursor related functions in your X video driver
   and make sure that H/W cursor is being supported in your kernel.
 - enable S/W cursor with the following command.
 # DISPLAY=:0 xsetroot -cursor_name left_ptr

 Best regards,
 Sung-Jin Park

 --- Original Message ---
 Sender : Carsten Haitzlerti...@rasterman.com 
 Date   : 2014-08-13 12:04 (GMT+09:00)
 Title  : Re: [Dev] Disabled Mouse Cursor in Tizen 2.2

 On Wed, 13 Aug 2014 00:42:22 +0900 GyeongHwan Hong redcarro...@gmail.com 
 said:

 Hello,
 I appreciate your advise.
 As you mentioned, I tried to remove all the contents of ~/.e.
 I also tried to disable part of the contents with all number of cases.
 As a result, I failed to make mouse cursor appear.

 I checked the original theme file in the source code of Enlightment in
 Tizen 2.2, as well.
 There are samsung.edc and default.edc on framework/uifw/e17/data/themes.
 In Tizen 2.2, samsung.edc is set as default theme file, so I investigated
 it.
 samsung.edc is pointing a image file of mouse cursor.
 Although default.edc is pointing dozens of image files, samsung.edc is
 definitely pointing cursor image file and allowing to show the cursor.

 I guess that there is some code forbidding cursor's appearance in source
 code of Enlightment, Xorg or Xorg drivers.

 Do you have anything else idea?
 you should go back to the default profile as well, as i said - make sure all
 modules are compiled. then you will get the ui you want. all the samsung mods
 there (samsung profile, theme) are hyper specific to just make a mobile ui 
 and
 nothing else. no mouse cursor (normally), no window titlebars/borders. only 
 1
 window at a time etc.

 if you want a desktop env ... you want to rebuild e to have all modules,
 ensure you are starting out of the box without changes and you'll get a
 regular wizard and desktop.

 tizen is not user friendly. it's product/oem friendly. unless it is a
 phone/mobile device you are making.. you want likely a regular windowed
 expeirence and that has basically been removed in tizen enlightenment. the 
 best
 is to disable as many changes as possible to get back to that.

 Regards,
 Gyeonghwan Hong.

 -- 
 Gyeonghwan Hong (RedCarrottt)
 Embedded Software Lab.
 Sungkyunkwan University
 redcarro...@gmail.com


 On Tue, 12 Aug 2014 14:45:48 +0900, Carsten Haitzler wrote:
 Date: Tue, 12 Aug 2014 14:45:48 +0900
 From: Carsten Haitzler c.haitz...@samsung.com
 To: dev@lists.tizen.org
 Subject: Re: [Dev] Disabled Mouse Cursor in Tizen 2.2
 Message-ID: 53e9aa0c.8000...@samsung.com
 Content-Type: text/plain; charset=utf-8

 it may be the enlightenment theme that sets an invisible cursor (just is
 all alpha pixels) and that is done by the theme. maybe try make sure you
 have the std default theme as shipped - not the modified ones, and dont
 use anything but the default profile.

 you also want to make sure your build doesnt enable or disable

Re: [Dev] HW key event grabbing on Tizen Wayland

[Carsten Haitzler]

On 08/12/2014 05:38 PM, 박성진 wrote:
 Samsung Enterprise Portal mySingle

 Hi, Wang, Yan,

 libinput is a library to handle input devices and it'll be used for a
 display server like Xserver and wayland compositors.

 Wayland clients will get input events through GUI toolkits from
 wayland compositors.

  

 Regarding utilx library, the key definitions in it had been made for
 mobile profile on X based window system.

 This kind of key definitions won't be made in wayland because the key
 list will be different from H/Ws and

 the list of keys must not be hard-coded. :)

 We're going to propose a new protocol for wayland clients

 to make a request for H/W key event and to get the key event from
 wayland compositor.


basically ... keyrouter for wl. :) (be able to grab keys or  have them
routed intelligently based on app prefs and/or its focused or other
states etc.)

 Thanks and regards,
 Sung-Jin Park

 --- Original Message ---
 Sender : Wang, Yanyan.w...@intel.com
 Date   : 2014-08-12 17:08 (GMT+09:00)
 Title  : [Dev] HW key event grabbing on Tizen Wayland

 Hi, All,
   Today I checked HW key event grabbing on Tizen. In Tizen X (mobile),
 libslp-utilx package could do this. (E.g.
 KEY_MENU/POWER/VOLUME_UP/VOLLUME_DOWN/CAMERA...) But how about in Wayland?
   In Wayland/Weston upstream, I think libinput could do it because I
 could see KEY_VOLUME_UP/DOWN, KEY_POWER, KEY_BACK, KEY_MENU, ... in
 it. Is it right?
   http://cgit.freedesktop.org/wayland/libinput.
   libinput hasn't been migrated to Tizen Wayland Common/IVI repos so
 far. Will it be available on Tizen in the future?
   Thanks.

 Yan Wang
 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev
 pnbsp;/ppnbsp;/p



 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Disabled Mouse Cursor in Tizen 2.2

[Carsten Haitzler]

On 08/13/2014 12:39 PM, 박성진 wrote:
 Hello.
 as I remember, in Tizen 2.2 mobile, SW cursor has been disabled by default 
 inside Xserver.
 Using SW cursor in Xserver will make damage events as the cursor needs to be 
 updated.
 This can be tightly coupled with UI rendering performance.
 Thus the mouse cursor won't be shown even if the proper cursor image has been 
 set by enlightenment window manager,

sw cursor causes damages? really? wow! thats... all kinds of wrong!

 If you want to display mouse cursor, you can do one of the followings:
 - implement H/W cursor related functions in your X video driver
   and make sure that H/W cursor is being supported in your kernel.
 - enable S/W cursor with the following command.
 # DISPLAY=:0 xsetroot -cursor_name left_ptr

 Best regards,
 Sung-Jin Park

 --- Original Message ---
 Sender : Carsten Haitzlerti...@rasterman.com 
 Date   : 2014-08-13 12:04 (GMT+09:00)
 Title  : Re: [Dev] Disabled Mouse Cursor in Tizen 2.2

 On Wed, 13 Aug 2014 00:42:22 +0900 GyeongHwan Hong redcarro...@gmail.com 
 said:

 Hello,
 I appreciate your advise.
 As you mentioned, I tried to remove all the contents of ~/.e.
 I also tried to disable part of the contents with all number of cases.
 As a result, I failed to make mouse cursor appear.

 I checked the original theme file in the source code of Enlightment in
 Tizen 2.2, as well.
 There are samsung.edc and default.edc on framework/uifw/e17/data/themes.
 In Tizen 2.2, samsung.edc is set as default theme file, so I investigated
 it.
 samsung.edc is pointing a image file of mouse cursor.
 Although default.edc is pointing dozens of image files, samsung.edc is
 definitely pointing cursor image file and allowing to show the cursor.

 I guess that there is some code forbidding cursor's appearance in source
 code of Enlightment, Xorg or Xorg drivers.

 Do you have anything else idea?
 you should go back to the default profile as well, as i said - make sure all
 modules are compiled. then you will get the ui you want. all the samsung mods
 there (samsung profile, theme) are hyper specific to just make a mobile ui and
 nothing else. no mouse cursor (normally), no window titlebars/borders. only 1
 window at a time etc.

 if you want a desktop env ... you want to rebuild e to have all modules,
 ensure you are starting out of the box without changes and you'll get a
 regular wizard and desktop.

 tizen is not user friendly. it's product/oem friendly. unless it is a
 phone/mobile device you are making.. you want likely a regular windowed
 expeirence and that has basically been removed in tizen enlightenment. the 
 best
 is to disable as many changes as possible to get back to that.

 Regards,
 Gyeonghwan Hong.

 -- 
 Gyeonghwan Hong (RedCarrottt)
 Embedded Software Lab.
 Sungkyunkwan University
 redcarro...@gmail.com


 On Tue, 12 Aug 2014 14:45:48 +0900, Carsten Haitzler wrote:
 Date: Tue, 12 Aug 2014 14:45:48 +0900
 From: Carsten Haitzler c.haitz...@samsung.com
 To: dev@lists.tizen.org
 Subject: Re: [Dev] Disabled Mouse Cursor in Tizen 2.2
 Message-ID: 53e9aa0c.8000...@samsung.com
 Content-Type: text/plain; charset=utf-8

 it may be the enlightenment theme that sets an invisible cursor (just is
 all alpha pixels) and that is done by the theme. maybe try make sure you
 have the std default theme as shipped - not the modified ones, and dont
 use anything but the default profile.

 you also want to make sure your build doesnt enable or disable any
 modules - remove those module configure options from the build so you
 get all modules by default. if $HOME has an empty ~/.e dir then you'll
 be launched into e's default startup wizard with mouse pointer and all.
 basically i'm sayng rmove all the csutomizing tizen has done and go
 back to 'as shipped by upstream' and you'll get what you want. :)

 of course that e is really old. really old.

 On 08/12/2014 02:36 PM, GyeongHwan Hong wrote:
 In Tizen 2.2, who is drawing mouse cursor icon on the screen, among
 graphic device driver, Xorg library, X server, X resource and Enlightment?

 As I investigated, all of those have functions about drawing mouse cursor.
 However, one of them may draw it in effect, as I think.

 Thanks,
 Gyeonghwan Hong.



 2014-08-12 14:10 GMT+09:00 ??? myungjoo@samsung.com
 mailto:myungjoo@samsung.com:

 This may be helpful: https://bugs.tizen.org/jira/i#browse/TIVI-515



 (googled Tizen -nocursor)



 --- *Original Message* ---

 *Sender* : GyeongHwan Hongredcarro...@gmail.com
 mailto:redcarro...@gmail.com


 *Date* : 2014-08-12 13:51 (GMT+09:00)

 *Title* : [Dev] Disabled Mouse Cursor in Tizen 2.2



 Hello.

 I am porting Tizen 2.2 on my ODROID-U3 board.
 I built source of all the packages in Tizen 2.2, made a image by
 MIC and flashed on the device.
 As almost porting, I can see GUI of Tizen such as lock screen,
 launchpad and some basic apps.

 When I plug a mouse to USB port of the board

Re: [Dev] Disabled Mouse Cursor in Tizen 2.2

[Carsten Haitzler]

it may be the enlightenment theme that sets an invisible cursor (just is
all alpha pixels) and that is done by the theme. maybe try make sure you
have the std default theme as shipped - not the modified ones, and dont
use anything but the default profile.

you also want to make sure your build doesnt enable or disable any
modules - remove those module configure options from the build so you
get all modules by default. if $HOME has an empty ~/.e dir then you'll
be launched into e's default startup wizard with mouse pointer and all.
basically i'm sayng rmove all the csutomizing tizen has done and go
back to 'as shipped by upstream' and you'll get what you want. :)

of course that e is really old. really old.

On 08/12/2014 02:36 PM, GyeongHwan Hong wrote:
 In Tizen 2.2, who is drawing mouse cursor icon on the screen, among
 graphic device driver, Xorg library, X server, X resource and Enlightment?

 As I investigated, all of those have functions about drawing mouse cursor.
 However, one of them may draw it in effect, as I think.

 Thanks,
 Gyeonghwan Hong.



 2014-08-12 14:10 GMT+09:00 함명주 myungjoo@samsung.com
 mailto:myungjoo@samsung.com:

 This may be helpful: https://bugs.tizen.org/jira/i#browse/TIVI-515

  

 (googled Tizen -nocursor)

  

 --- *Original Message* ---

 *Sender* : GyeongHwan Hongredcarro...@gmail.com
 mailto:redcarro...@gmail.com

 *Date* : 2014-08-12 13:51 (GMT+09:00)

 *Title* : [Dev] Disabled Mouse Cursor in Tizen 2.2

  

 Hello.

 I am porting Tizen 2.2 on my ODROID-U3 board.
 I built source of all the packages in Tizen 2.2, made a image by
 MIC and flashed on the device.
 As almost porting, I can see GUI of Tizen such as lock screen,
 launchpad and some basic apps.

 When I plug a mouse to USB port of the board, however, any mouse
 cursor is not shown on the screen, but I can click some button an
 app icon or make a drag on the lock screen.

 I checked that Xinput identified my mouse by xinput command.
 I also set Xcursor themes on /usr/share/icons/ and configuration
 file on /etc/X11/Xresources.

 I am guessing the reason is that Xorg or Enlightment is modified
 to interrupt behavior about mouse cursor, for touch screen devices.
 I heard that there was a patch on xorg in Tizen 2.1 as below URL.
 (In Tizen 2.2, this patch is integrated into
 framework/uifw/xorg/server/xorg-server/mi/misprite.c)
 This patch seems to disable a behavior drawing SW cursor.

 
 https://build.tizen.org/package/view_file?file=0012-Add-a-feature-not-to-draw-sw-cursor.patchpackage=xorg-serverproject=Tizen%3AGenericrev=9506db4c8b3e9136288cbfb7fcce158b

 I removed it off and put a rebuilt xorg-server package into the
 device,
 but mouse cursor still does not appear.

 How can mouse cursor be shown?
 Is there other code disabling mouse cursor?


 Thanks,
 Gyeonghwan Hong.


 -- 
 Gyeonghwan Hong (RedCarrottt)
 Embedded Software Lab.
 Sungkyunkwan University
 redcarro...@gmail.com mailto:redcarro...@gmail.com

  

 --

 MyungJoo Ham (함명주), PHD

 Frontier CS Lab, Software Center
 Samsung Electronics
 Cell: +82-10-6714-2858 tel:%2B82-10-6714-2858

  




 -- 
 Gyeonghwan Hong (RedCarrottt)
 Embedded Software Lab.
 Sungkyunkwan University
 redcarro...@gmail.com mailto:redcarro...@gmail.com


 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Common/X11 schedule

[Carsten Haitzler]

On 07/31/2014 05:55 PM, Counihan, Tom wrote:
 Is there a future roadmap whereby Tizen will harmonise on 1 - X11 | Wayland?

when it's ready - wayland. mobile, tv and wearable are all still tied to
x11. there is work underway to untie this, but it simply is taking
longer than the timeframe for tizen 3, thus both x11 and wayland need to
be supported.

 I totally get protecting and leveraging past investment, but what strikes me 
 on this thread is, has there been any cost-benefit analysis on the tax of 
 leveraging 2.0 vs. the cost moving to a more unified graphics architecture?
 Perhaps product timelines impose this current inertia, but I'd be very 
 appreciative for feedback from the experts here in painting a more long term 
 vision of where we want to go in this area.

product timelines necessitate the lack of effort on movign to wayland.
what is ideal and what we have are not the same thing unfortunately.

 Will X11 + Wayland always be on offer, or is there a desire to move to a pure 
 Wayland based solution in the foreseeable future?

 -Original Message-
 From: Dev [mailto:dev-boun...@lists.tizen.org] On Behalf Of Carsten Haitzler
 Sent: Thursday, July 31, 2014 12:14 AM
 To: Dominig ar Foll (Intel OTC)
 Cc: dev@lists.tizen.org
 Subject: Re: [Dev] Common/X11 schedule

 On Wed, 30 Jul 2014 17:51:04 +0200 Dominig ar Foll (Intel OTC)
 dominig.arf...@fridu.net said:

 Carlsen,

 we need your advise for building Common.
 The hack done in Tizen 2 for Mobile is not a legacy that we can afford
 to assume in the Common project.
 mobile has to build off common - so that is something that i have to take 
 into
 account. as does tv, wearables and ivi. otherwise it should not be called
 common.

 That is the issue of the mobile team who will be in charge of the move
 from Tizen 2 to Tizen 3.
 not as long as it's called common.

 In view of that position what is your advise ?

 Dominig ar Foll
 Senior Software Architect
 Open Source Technology Centre
 Intel SSG

 Le 30/07/2014 16:20, Carsten Haitzler (The Rasterman) a écrit :
 On Wed, 30 Jul 2014 15:36:39 +0200 Stéphane Desneux
 stephane.desn...@open.eurogiciel.org said:

 Hi Carsten,

 Is Enlightenment 0.18.7 a better candidate ?
 no. e17. as of e18 compositor is no longer a module. this totally
 kills the compositor module fork of e's original compositor that was
 done for e17 and tizen 2.x - this needs a re-do/design. this also
 changes how clients/borders are handled api-wise.

 It's not the latest one but it's far more recent than the 0.17.4 on
 tizen git. We took this version because it was quite aligned with
 EFL
 1.9.3 which is the current EFL version on Tizen:Common.

 With these details, is it still a bad idea ? :)
 only if you want to break tizen mobile entirely (as a mobile style
 ui - apps will still display - just in windows) - then sure. go for
 it. then also remove all the custom samsung e profile packages and
 config and go back to vanilla enlightenment - then no problems. :)
 you definitely then want to nuke the tizen elementary theme too and
 go back to vanilla as well. :) if you do this then may as well go
 for git master. :)

 --
 Stéphane Desneux
 Intel OTC - Vannes/FR
 gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726

 On 30/07/2014 14:37, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 30 Jul 2014 12:35:39 +0200 Stéphane Desneux
 stephane.desn...@open.eurogiciel.org said:

 bumping to enlightenment upstream is going to be... bad at this stage.
 hold on that for the time-being.

 Hi Boram,

 I updated our project with the 4 packages you updated.

 1 new error occured, on xf86-video-intel (which is not up to date
 probably).

 Also, what happens for these remaining packages:

 https://github.com/Tarnyko/enlightenment.git tizen
 https://github.com/Tarnyko/xf86-video-intel.git  tizen
 https://github.com/Tarnyko/glproto.git
 5903b304417886de32ad620ff8874998ddee4254

 I think we should still bump them all. Your opinion ?

 --
 Stéphane Desneux
 Intel OTC - Vannes/FR
 gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726

 On 29/07/2014 14:49, Boram Park wrote:
 Hello Stephane



 Today, I upgraded below 4 git repos to rebase xorg-server to
 1.16. All patches are pushed in devel/x11 branch.

platform/upstream/xorg-server

platform/upstream/xproto

platform/upstream/fontsproto

platform/upstream/libXfont



 Please check wethere there are any issues in your side. If no
 issue, I'll send SRs together when I send SRs of x11 integration work.



 Regards

 Boram



 --- *Original Message* ---

 *Sender* : Stéphane
 Desneuxstephane.desn...@open.eurogiciel.org

 *Date* : 2014-07-29 16:46 (GMT+09:00)

 *Title* : Re: [Dev] Common/X11 schedule



 Boram,

 No problem for patches. Merging into tizen branch makes just
 things easier (we can compare project manifests, submit diffs
 etc. easily)

 FYI: to submit multiple packages at the same time on
 Tizen:Common, please use 'group submissions'.

 See: §3.1.2 on
 https

Re: [Dev] elementary upgrade / Re: Merge commit gerrit push fail

[Carsten Haitzler]

On 07/29/2014 07:12 PM, Philippe Coval wrote:
 On 29/07/2014 12:05, Dominig ar Foll (Intel OTC) wrote:
 Hello;

 the strategy of Tizen has been so far to use the last Stable release
 when ever possible.
 At this moment we're a litle late since upstream released a few
 versions since
 not the reason we did not upgrade at this time it was to keep common
 aligned to ivi (or the opposite) ...

 Now It would also think it's a better timing to upgrade it

 Just need someone to propose this on jira
 if noone is against for some reasons
 then I can do that task if it helps

 Following a daily of an upstream project is not the selected model.
 this can be done in sandbox branches quiet easily

 We have favoured stability and as far as I know that has not be been
 changed.
 yes but sometime we need to make validate decisions on version jumps

 ie we have glib2 upgrade blocked for some time now :
 https://bugs.tizen.org/jira/browse/PTREL-773

 Regards

 ps: I upgraded the efl upstream branch and tags if it helps


there is a general reason to upgrade efl - it has bugfixes your old
version smapshot does not. we don't do bugfixes for older versions of
efl for long. it even has secuurity fixes for lz4. it also has new
features people will depend on soon enough and long nto the future. my
advice is to track master until you get close to tizen common release.
your release cycle is ~3 months (12 weeks). we release close to like
clockwork so you can predict the release you want to then lock in
before tizen common release and stick to that for tizen release. it will
be easiest on everyone by a long shot.

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.




signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Building platform image with Mesa or Virtual driver in Tizen 3.0

[Carsten Haitzler]

On 07/25/2014 02:13 PM, Damian Hobson-Garcia wrote:
 Hi Carsten,

 On 2014-07-25 1:07 PM, Carsten Haitzler wrote:

 Mesa could also be used during build time instead of the
 opegl-es-virtual-drv.
 Yes and no, I think.  There is the minor problem that the Mesa
 drivers provide a versioned libGLESv2.so.2, which all of the
 built packages will link to.  This means that if I want to
 install a driver (such as Mali or SGX) after the fact, I have to
 provide libGLESv2.so.2 to overwrite the Mesa driver. If Mesa
 changes its version number for some reason, now the Mali and SGX
 drivers must update their names as well. opegl-es-virtual-drv is
 nice because it is not versioned, so as long as there is a
 libGLESv2.so (or a link of that name) in the non floss drivers,
 everything works.
 or just provide a symlink. far simpler a solution. drivers just
 ghave to agree all to provide at least the same symlink to the real
 driver version

 I don't think it matters whether it's a symlink or not.  Either way,
 it requires all of the drivers to keep track of whatever version
 number that Mesa is using for its libGLESv2 and update the symlink
 accordingly.

for ABI compatibility, mesa can't just go changing major so version
anyway as a binary links agains the major s at the time i'ts build. if
they change major so version they are saying they broke ABI. so onse
everyone is building against libGLxx.so.2 then it has to stay - unless
they break ABI which they neever should.

so it can be ASSUMED to always be that version - tizen as a platform has
to force/define that and guarantee it across all tizen variations and
versions. if we have to patch mesa (or just add special symlinks in
pkgs) or do the same for other vendor gl drivers, thatis the price you
pay to keep compatibility. that is what we have to do.

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.




signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Building platform image with Mesa or Virtual driver in Tizen 3.0

[Carsten Haitzler]

On 07/25/2014 02:23 PM, 하상원 wrote:
 Samsung Enterprise Portal mySingle

 Hi Carsten,

  

 I agree with Damian on that method is not the problem but whether
 we'll follow

 Mesa's versioning scheme if we decide to use it during build time.

 Btw, we already provide opengles and egl capability using sym links
 for all Mali drivers

 in their versioned .so files. :)


then you maintain those - with their major versions (i don't have a
tizen fs haandy to look which one). that is now your ABI. you can't
break it. keep it.

  

 Best regards,

 Sangwon Ha

  

 --- *Original Message* ---

 *Sender* : Damian Hobson-Garciadhobs...@igel.co.jp

 *Date* : 2014-07-25 14:13 (GMT+09:00)

 *Title* : Re: [Dev] Building platform image with Mesa or Virtual
 driver in Tizen 3.0

  

 Hi Carsten,

 On 2014-07-25 1:07 PM, Carsten Haitzler wrote:

  Mesa could also be used during build time instead of the
  opegl-es-virtual-drv.
  Yes and no, I think.  There is the minor problem that the Mesa
  drivers provide a versioned libGLESv2.so.2, which all of the
  built packages will link to.  This means that if I want to
  install a driver (such as Mali or SGX) after the fact, I have to
  provide libGLESv2.so.2 to overwrite the Mesa driver. If Mesa
  changes its version number for some reason, now the Mali and SGX
  drivers must update their names as well. opegl-es-virtual-drv is
  nice because it is not versioned, so as long as there is a
  libGLESv2.so (or a link of that name) in the non floss drivers,
  everything works.
 
  or just provide a symlink. far simpler a solution. drivers just
  ghave to agree all to provide at least the same symlink to the real
  driver version
 

 I don't think it matters whether it's a symlink or not.  Either way,
 it requires all of the drivers to keep track of whatever version
 number that Mesa is using for its libGLESv2 and update the symlink
 accordingly.

 Damian
 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev

  

 

  






 

   

  

   

 *HA, SANGWON, Ph.D.
 *Senior Engineer

 System S/W Lab, S/W Platform Team,
 S/W Center

 *SAMSUNG ELECTRONICS CO., LTD.*
 129 Samsung-Ro, Maetan-Dong,
 Yeongtong-Gu, Suwon,
 Gyeonggi-Do, Korea 443-742

 TEL: +82-31-279-1091
 FAX: +82-31-279-2348
 MOBILE: +82-10-3199-8833
 E-mail: sw815...@samsung.com mailto:sw815...@samsung.com

 

  



 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] First measurement of the SAPI overhead

[Carsten Haitzler]

On 07/03/2014 06:58 PM, Dominig ar Foll (Intel OTC) wrote:

 that is indeed another option - assuming it actually is a service and
 doesnt go
 direct to some sqlite db or file. :)


 Unfortunatly we cannot trust the application to make the control in
 Cynera, so the enforcement must be external to the application.
 When it come to critical or high usage App, they will always be
 provided by the platform creator who always has the option to created
 a trusted App which can by pass the default model.

when i read on the service side i understood it was the server that
already exists handing out the resources so we do it at the current
protocol level of the service, not per api. (1 api might not equal 1
protocol request).

 I was in the IVI conference yesterday and the needed for highly
 optimised trusted application was discussed and to be honest was more
 the exception but the requirement to enforce security to most Apps (as
 trusted App cost a lot more to develop and maintain) was confirmed.

 If we look at how Android works, it's very close to José proposition
 and they are quite successful in the world of Phones.

 Regards

 Dominig



 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev


-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.




signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] First measurement of the SAPI overhead

[Carsten Haitzler]

On 07/02/2014 04:08 PM, Patrick Ohly wrote:
 On Wed, 2014-07-02 at 10:31 +0900, Carsten Haitzler wrote:
 On 07/02/2014 08:58 AM, Dominig ar Foll (Intel OTC) wrote:

 Le 02/07/2014 01:01, Carsten Haitzler (The Rasterman) a écrit :

 O

 2. what's the call overhead without socket (cost of a function call)... :) 
 that
 is what you are comparing against.

 the best case scenario here - 0.1ms ... give a BEST case of 10,000 calls 
 per
 second.. assuming the ONLY thing i do is that and nothing else... that's 
 pretty
 low. but then again you need some level of real-life data
 Remember that we are only taking about the signaling API and not the
 transfer API.
 So having 1 of call  per second is not a realistic concern.
 i thought this was meant to be an ipc round trip per api?
 Indeed. So let's look at the mail API:

 https://review.tizen.org/gerrit/gitweb?p=platform/core/api/email.git;a=blob;f=include/email.h;h=61676806748c7ed44ee4505e0c71588832ec82c4;hb=refs/heads/tizen

 There's email_create_message() giving us a local pointer. Then there's
 email_set_subject(), taking such a pointer. This is a specific example
 of the problem that I mentioned in my other email, where the proxy needs
 to validate the pointer before calling the original CAPI
 email_set_subject().

 It's also an example for local function call becomes
 RPC 
 (https://review.tizen.org/gerrit/gitweb?p=platform/core/api/email.git;a=blob;f=src/email.c;h=a6d447602a965ef25e610f13edc63a52c11bf4be;hb=refs/heads/tizen).

 One can argue that this function will only be called rarely. But is that
 the case for all functions?

 And is this really the right API to look at in the first place? See
 below.

 I invite you to look at the current CAPI which are the candidate for
 wrapping, you will find an updated list here :

https://wiki.tizen.org/wiki/User:Sdi2 
 These are the services. Do you have the corresponding list of APIs which
 are meant to be wrapped?

 For email, there's the capi referenced above (pretty limited, only
 supports composing and sending an email) and the underlying
 email-service API
 (https://review.tizen.org/gerrit/gitweb?p=platform/core/messaging/email-service.git;a=tree;f=email-api/include;h=cbe9692e989ae1b5abbfa5bb065048f4bbc81306;hb=refs/heads/tizen).

 It was said that Crosswalk should rely on SAPI to implement the web
 APIs. For email, the capi is not sufficient for implementing the Tizen
 messaging API
 (https://developer.tizen.org/dev-guide/2.2.1/org.tizen.web.device.apireference/tizen/messaging.html).

 email and messaging, from memory allow you to fetch messages/emails.
 that means you have data to fetch... ?
 The capi for email doesn't allow fetching, the email-service does. So we
 need to clarify first which one is supposed to be wrapped.

ok sorry - bad illustration. MESSAGE api does allow this

https://review.tizen.org/gerrit/gitweb?p=framework/api/messages.git;a=blob;f=include/messages.h;h=09e7a96e97d4ae7973ac8b8c2a80a9be3e45c279;hb=HEAD

you get message count, then using messages_foreach_message() or
messages_search_message(), then per messge you messages_get_time(),
messages_get_text(), messages_get_address(), messages_get_message_type()
etc. etc.

now let's imagine you are scrolling through a list of 1000's of
messages. yoou have a big screen that can display a list of 100
messages. as you scroll, you will have to (if scrolling fast) query 100
new messages per frame (you scroll 1 screne or more worth of content
each frame). at 60hz. and you need to spend your time also rendering and
doing other things. sure - do the queries in a thread... but hear me
out. let's assume you have a dedicated thread for this ALONE. that means
6000 messages need querying for display every second (100*60). if each
of the above calls (first to list the 100 messages, then per message get
address, type, text etc.) are wrapped in SAPI as client/server
round-trips... you are doing at least 4 round trip calls per message...
0.4 ms at a best case... 6000 times per second to keep up display. that
means we are burining 2400ms of round-trip query time PER 1000ms of time
we have. we just can't keep up. this is a best scase scenario. it gets
worse on different cpu architectures etc.

if SAPI is just a wrapper around CAPI call-by-call, this is doomed to
have these kinds of performance issues all through it. and that above is
the best case scenario. it has to be far more involved and intelligent
than that.

example above - when you query for a bunch of messages ALL of the
messages and data are transferred locally to the client side in memory
and after that all data is local, so the gets then are simply getting
ptrs inside an already client-side structure.

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized

Re: [Dev] First measurement of the SAPI overhead

[Carsten Haitzler]

On 07/02/2014 08:24 PM, José Bollo wrote:
 On mer, 2014-07-02 at 16:43 +0900, Carsten Haitzler wrote:

 (snip)

 ok sorry - bad illustration. MESSAGE api does allow this

 https://review.tizen.org/gerrit/gitweb?p=framework/api/messages.git;a=blob;f=include/messages.h;h=09e7a96e97d4ae7973ac8b8c2a80a9be3e45c279;hb=HEAD

 you get message count, then using messages_foreach_message() or
 messages_search_message(), then per messge you messages_get_time(),
 messages_get_text(), messages_get_address(), messages_get_message_type()
 etc. etc.

 now let's imagine you are scrolling through a list of 1000's of
 messages. yoou have a big screen that can display a list of 100
 messages. as you scroll, you will have to (if scrolling fast) query 100
 new messages per frame (you scroll 1 screne or more worth of content
 each frame). at 60hz. and you need to spend your time also rendering and
 doing other things. sure - do the queries in a thread... but hear me
 out. let's assume you have a dedicated thread for this ALONE. that means
 6000 messages need querying for display every second (100*60). if each
 of the above calls (first to list the 100 messages, then per message get
 address, type, text etc.) are wrapped in SAPI as client/server
 round-trips... you are doing at least 4 round trip calls per message...
 0.4 ms at a best case... 6000 times per second to keep up display. that
 means we are burining 2400ms of round-trip query time PER 1000ms of time
 we have. we just can't keep up. this is a best scase scenario. it gets
 worse on different cpu architectures etc.

 if SAPI is just a wrapper around CAPI call-by-call, this is doomed to
 have these kinds of performance issues all through it. and that above is
 the best case scenario. it has to be far more involved and intelligent
 than that.

 example above - when you query for a bunch of messages ALL of the
 messages and data are transferred locally to the client side in memory
 and after that all data is local, so the gets then are simply getting
 ptrs inside an already client-side structure.
 Hi Carsten,

 You are right and I let you image what it could be if DBUS (or even
 KDBUS) was used instead... ;) But, currently, I have no time to bench it
 o_O

indeed dbus would be worse... :) i was more saying how much worse is
this vs no ipc at all - ie as it is now. :)

 The current compromise is to advance and have security inside Tizen 3.
 As you perhaps remember, the security should no more be checked in the
 user space, it have to be a service. That's the problem.

sure. i agree we should have good security - more fine grained control
is better. but it shouldn't come at a significant expense in
performance. this simply reduces battery life, hurts usr expeirence and
ultimately all the best security on the planet is pointless if users
just abandon the plantform because they are unhappy with their
performance. making a perfectly secure os that no one wants is a pretty
pointless task. there has to be a middle ground. :)

as such wraping every CAPI calll in an ipc call is not going to fly -
it's going to create nasty bottlenecks in a range of usages. this has to
be done intelligently and maybe it requires we go slowly and wrap 1 api
at a time, carefully redesigning the client-side lib to have minimal
round-trips and lots of client-side data shadowing. it may take longer
than expected. i just think we likeely nheed to account for this in
timelines and goals.

 The problem of time that you described really exist and have to be
 treated. I agree with that. As wrote Dominique, for this kind of problem
 can be solved by separating the signaling of the content. The precise
 answers for each API have to be studied. That's a lot of work. A lot of
 compromises too.

 The example of the emails is really good because emails are not seen as
 being time critical data but it can be a timing problem because the
 count of emails can be high. 

 Best regards
 José




-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.




signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] VTC 1010,

[Carsten Haitzler]

odd. does hdmi display right? i have one of these and it works like a
charm - tizen image boots all the way to desktop. display and input work.

On 07/02/2014 04:43 AM, McGee, Art wrote:
 I am not seeing the AMB bios message.



 On 1 July 2014 11:47, Hofemeier, Ulf ulf.hofeme...@intel.com
 mailto:ulf.hofeme...@intel.com wrote:

 Do you see the AMI Bios messages to confirm the adapter is
 connected right? Past that point VGA needs to be disabled using
 the following kernel parameter video=VGA-1:d 

 Thanks,
 Ulf


 On Tue, Jul 1, 2014 at 11:15 AM, McGee, Art
 amcg...@jaguarlandrover.com mailto:amcg...@jaguarlandrover.com
 wrote:

 Just received the Active Adapter from StartTech.  Still unable
 to get the VTC 1010 to display anything on the screen.  I have
 disable the VGA with the kernel option.  I've added the rule
 to direct the touch events.  I've corrected the westion ini
 file mode for DP1.  This could be a lower level problem
 because I am not able to see the boot process.

 -- 
 Art McGee
 Infotainment Engineer
 Jaguar Land Rover
 One World Trade Center, 121 Southwest Salmon Street, 11th
 Floor, Portland, Oregon, 97204





 -- 
 Art McGee
 Infotainment Engineer
 Jaguar Land Rover
 One World Trade Center, 121 Southwest Salmon Street, 11th Floor,
 Portland, Oregon, 97204



 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] First measurement of the SAPI overhead

[Carsten Haitzler]

On 07/02/2014 08:58 AM, Dominig ar Foll (Intel OTC) wrote:
 Le 02/07/2014 01:01, Carsten Haitzler (The Rasterman) a écrit :
 O

 2. what's the call overhead without socket (cost of a function call)... :) 
 that
 is what you are comparing against.

 the best case scenario here - 0.1ms ... give a BEST case of 10,000 calls per
 second.. assuming the ONLY thing i do is that and nothing else... that's 
 pretty
 low. but then again you need some level of real-life data
 Remember that we are only taking about the signaling API and not the
 transfer API.
 So having 1 of call  per second is not a realistic concern.

i thought this was meant to be an ipc round trip per api?

 I invite you to look at the current CAPI which are the candidate for
 wrapping, you will find an updated list here :

https://wiki.tizen.org/wiki/User:Sdi2
 https://wiki.tizen.org/wiki/User:Sdi2

 Dominig

email and messaging, from memory allow you to fetch messages/emails.
that means you have data to fetch... ?




 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Cynara

[Carsten Haitzler]

On 04/16/2014 03:25 AM, Schaufler, Casey wrote:
 -Original Message-
 From: Dev [mailto:dev-boun...@lists.tizen.org] On Behalf Of Carsten
 Haitzler
 Sent: Monday, April 14, 2014 6:59 PM
 To: dev@lists.tizen.org
 Subject: Re: [Dev] Cynara



 On 04/15/2014 10:16 AM, Schaufler, Casey wrote:
 -Original Message-
 From: Dev [mailto:dev-boun...@lists.tizen.org] On Behalf Of Carsten
 Haitzler
 Sent: Monday, April 14, 2014 4:47 PM
 To: Lukasz Wojciechowski
 Cc: dev@lists.tizen.org
 Subject: Re: [Dev] Cynara

 On Tue, 08 Apr 2014 20:57:37 +0200 Lukasz Wojciechowski
 l.wojciec...@partner.samsung.com said:

 Services that are being used by applications need to control if the
 caller has sufficient privileges to call each API. In Tizen 2.2.X
 this level of access control was done using very detailed Smack
 policy on IPC mechanisms. Since Tizen 3.0 is introducing compact
 3-domain Smack policy, there is a need for user-space mechanism that
 complements the solution. This is a place for new module - Cynara.

 Details can be found at wiki page:
 http://wiki.tizen.org/wiki/Security:Cynara

 Page is still being constructed, but is is high time to share and
 probably start a discussion.
 I will be glad to answer any questions about it.
 I plan to publish roadmap for Cynara development and API draft this
 week.

 cynara_check ... where will the service daemon get the client string,
 and client_session string?

 SO_PEERCRED and SO_PEERSEC. Dependable. The wiki includes examples
 of
 how to do it.

 yeah - i know this one. this is how you can get pid/uid/gid from the other 
 end
 of a unix socke. how do you get the client and client_session string (in a 
 way
 that the client can't lie to you)?
 
 SO_PEERSEC gets you the Smack label. Since every Application
 gets a unique Smack label at installation time the Smack label
 can be used to identify the Application. It would be better if we
 had an explicit AppID that was independent of Smack, but there
 are kernel constraints that make that infeasible. 

then the documentation is not great. if client == smack label... the
docs should say this. :)

  
 if these are provided by the client... a client can just lie.

 You're correct.

 why not just provide the PID of the client directly to cynara and it
 does the rest? (this also means you can change, in future, what
 parameters/info you use to categorize a client).

 This is one of the methods available. There are race conditions in
 /proc, so it isn't technically reliable.

 sure. interestingly the cynra wiki suggests using proc to get creds:

 https://wiki.tizen.org/wiki/Security:Cynara:ApplicationCredentials

 i would expect to tell peolpe to only use socket+ SO_PEERCRED only it is
 reliable.


 --
 Carsten Haitzler (The Rasterman) ti...@rasterman.com
 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev
 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev


 --
 The above message is intended solely for the named addressee and may
 contain trade secret, industrial technology or privileged and confidential
 information otherwise protected under applicable law including the Unfair
 Competition Prevention and Trade Secret Protection Act. Any unauthorized
 dissemination, distribution, copying or use of the information contained in
 this communication is strictly prohibited. If you have received this
 communication in error, please notify the sender by email and delete this
 communication immediately.
 
 

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Cynara

[Carsten Haitzler]

On 04/15/2014 10:16 AM, Schaufler, Casey wrote:
 -Original Message-
 From: Dev [mailto:dev-boun...@lists.tizen.org] On Behalf Of Carsten
 Haitzler
 Sent: Monday, April 14, 2014 4:47 PM
 To: Lukasz Wojciechowski
 Cc: dev@lists.tizen.org
 Subject: Re: [Dev] Cynara

 On Tue, 08 Apr 2014 20:57:37 +0200 Lukasz Wojciechowski
 l.wojciec...@partner.samsung.com said:

 Services that are being used by applications need to control if the
 caller has sufficient privileges to call each API. In Tizen 2.2.X this
 level of access control was done using very detailed Smack policy on IPC
 mechanisms. Since Tizen 3.0 is introducing compact 3-domain Smack
 policy, there is a need for user-space mechanism that complements the
 solution. This is a place for new module - Cynara.

 Details can be found at wiki page:
 http://wiki.tizen.org/wiki/Security:Cynara

 Page is still being constructed, but is is high time to share and
 probably start a discussion.
 I will be glad to answer any questions about it.
 I plan to publish roadmap for Cynara development and API draft this week.

 cynara_check ... where will the service daemon get the client string, and
 client_session string?
 
 SO_PEERCRED and SO_PEERSEC. Dependable. The wiki includes
 examples of how to do it.

yeah - i know this one. this is how you can get pid/uid/gid from the
other end of a unix socke. how do you get the client and client_session
string (in a way that the client can't lie to you)?

 if these are provided by the client... a client can just lie.
 
 You're correct.
 
 why not just provide the PID of the client directly to cynara and it does
 the rest? (this also means you can change, in future, what parameters/info
 you
 use to categorize a client).
 
 This is one of the methods available. There are race conditions
 in /proc, so it isn't technically reliable.

sure. interestingly the cynra wiki suggests using proc to get creds:

https://wiki.tizen.org/wiki/Security:Cynara:ApplicationCredentials

i would expect to tell peolpe to only use socket+ SO_PEERCRED only it is
reliable.


 --
 Carsten Haitzler (The Rasterman) ti...@rasterman.com
 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev
 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev
 

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Cynara

[Carsten Haitzler]

On 04/11/2014 04:47 PM, Jussi Laako wrote:
 On 11.4.2014 2:14, Carsten Haitzler (The Rasterman) wrote:
 4. once you do these, you'll know why. (it's an essential part of
 input routing
 and focus management, as well as shortcuts, mouse pointer control and
 routing
 - only display server knows WHERE the mouse or touch point is pointing
 to on
 screen, and routes the mouse events appropriately).
 
 Route control and data are two separate things. In order to control data
 flow you don't actually have to see the data. Just like uploading
 routing table to a hardware based route matrix.

you route on an event by event basis based on the content of the event
and the requests from clients plus current display state. that's how you
manage key grabs.

 Display server knows that application X has topmost window at (x, y, w,
 h) so it tells mouse routing matrix to route translated mouse events
 from input device to the application when mouse position is within these
 coordinates. It shouldn't actually know where the mouse is.

and what when the window is rotated by 30 degrees, or wrapped around a
3d mesh of a bunny rabbit? and the only one who knows the mesh is the
compositor/display server? yes - that's wayland. it allows this and is
designed to be able to do it and work correctly.

 Display server also knows that application X has keyboard focus, so it
 tells keyboard route matrix to route keyboard input events from input
 device to the application. Display server doesn't need to see the actual
 commands.
 
 Shortcuts can be implemented using a special global meta key filter in
 the input layer driver and route those to a special shortcut key handler
 device node where a special shortcut handler process sits, none of the
 normal keyboard input events would be routed there.

so you just move stuff from display server into kernel, bloating the
kernel with policy it isn't interested in and is better handled in
userspace. and that policy can get increasingly more complex as time
goes on to handle all the event routing situations - see above with 3d
bunny mesh.

 Note that the route matrix can either reside within separate user space
 process, or could be just a simple implementation right in the kernel
 input layer.
 
 You can see this kind of software design pattern for example in the
 Postfix email server, where each subtask is split to a separate least
 privileged process.
 
 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev
 

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Cynara

[Carsten Haitzler]

On 04/11/2014 05:29 PM, Jussi Laako wrote:
 On 11.4.2014 2:34, Carsten Haitzler (The Rasterman) wrote:
 it does. in real life.
 
 No it doesn't when I'm configuring the system... ;)

do you use linux? X11? do you even intend to use wayland?

 For example, credit card payment terminals have their own keyboards for
 entering the PIN code, these input methods and routed to the POS system.
 For a reason...
 
 good luck. you can't. root only can access those. also bypassing the
 display
 
 Of course I make the particular binary u+s root.

so you throw out all the security giving unabridged access to this app.
so youi fully trust this app to not just blast over /dev/mem or
/dev/kmem or add backdoors into your kernel or libc, but you can't trust
a display server that is shipped with the os (kernel and more)? i smell
a bit of a double standard here.

 server bypasses focus management and policy. even if you had root
 access, if
 the display server has decided your app is not to be shown right now
 because
 some other dialog/app is more important and deserves to be
 seen/focused (this
 happens a LOT), then you would suddenly stop all input from working -
 a user
 couldn't type or interact with the app they currently see. they cant
 switch
 desktops. an app that does this would be shunned by users and
 ultimately booted
 from an ecosystem because it is malicious in terms of usability.
 
 You may notice that for example pinentry-gtk/pinentry-qt enforces focus
 on window system and you cannot switch the focus away for security reasons.

and all that input goes through the display server. x11 supports xinput
to allow clients to see things.. like multitouch devices and mroe
advanced devices. one of these days try:

  xinput list

then find your virtual core keyboard device (with id next to it)

  xinput test-xi2 DEVID

and then keep that going while you have one of these secure pin entry
apps that use xgrabkeyboard (xterm secure mode is one for example).

surprise. every key you press appears despite your notion that this is
secure. trust me. x11 is not secure in the slightest. if you have
access to the display server as a client, it's game over. your world
belongs to the app that has access.

and the DISPLAY SERVER still sees all these events. it's xorg. do you
trust it? you obviously seem to have no problem trusting it right now,
and it has full access. if xorg were malicious - same as weston or any
wayland compositor, you'd be totally out of luck. i seem to be repeating
myself.

 perfect example. amazon. don't even need to auth. it keeps your cookies.
 one-click buy.
 
 Luckily, I have that disabled on my account and always logout.

but 99% of peolpe don't. what you do in your locale area is not what 99%
of users do. the point remains - that for users, in general, if the
display server is compromised and/or malicious, you are screwed. it's a
false sense of security to think otherwise. and like it or not the
display systems in tizen are x11 and in future wayland (iv using wayland
now) and neither work the way you would like them to and neither WILL
work the way you want them to because they have to work this way for
many reasons which i have been trying to explain, and for one major
reason above all - compatibility.

 Browser also clears all my cookies every time I close it and certain
 cookies are blocked.
 
 i repeat. the display server is a trusted part of the system. in a
 wayland
 world, display server includes policy and desktop (focus policies,
 virtual
 desktop policies, etc. - ie window manager). do not dismiss it as
 incapable of
 foiling your magic security mechanisms. it can and if malicious, will.
 
 I don't know why you keep talking about wayland while I'm talking about
 _ALL_ service processes in the entire system.

because you replied to my mail that mentioend that weston (wayland
display server) would have access to pim data regardless of security
measures as long as some app could read the data and display it (which
there will be) and/or write to it. weston was sepcifically mentioned in
the original mail.

 I don't like ALL service processes running at EQUIVALENT privileges.
 Where did the least privilege model go?
 
 they have to be for routing. and go read wayland and x11 protcol. you
 don't
 live in the same world as the rest of us.
 
 Yeah, I hear that frequently. I don't want to live in that same world... :D

then you'll have to make your own os and display system as that is not
how the ones we have work.

 in the real world they will be using the same gpu. in the real world a
 double
 compositor setup is something that will not be shipped because of the
 extra
 
 I am using VirtualBox all the time and I guess many other people are too.

i deal with production issues in making products regularly and have done
so for many years. a few ms of latency is a production issue BUG that
halts the release of a product. that is how important latency and
performance is. every level of abstraction costs

Re: [Dev] Cynara

[Carsten Haitzler]

On 04/10/2014 06:05 PM, Patrick Ohly wrote:
 On Wed, 2014-04-09 at 16:34 +, Schaufler, Casey wrote: 
 On Wed, 2014-04-09 at 15:13 +0200, José Bollo wrote:
 On mer, 2014-04-09 at 14:35 +0200, Patrick Ohly wrote:
 You are right: apps not launched, not receiving the treatment have
 full accesses. But to my eyes it is not a problem because:
  - Tizen enforces the use of launcher (for security) so what are the
 applications that aren't launched?

 Which Tizen profile do you refer to here?

 In Tizen IVI there are several user processes which do not get spawned by
 the launcher and thus have access to more data than they really need.

 Those are mostly services (weston, murphyd) and basic
 UI applications (weekeyboard). Everything on Tizen (true
 for Android, too BTW) has access to more data than it needs.
 The question is whether it has access to data that matters.
 Who cares if it can read /etc/tizen-release?
 
 I guess it depends on the data and the goals. I'd certainly would be
 more comfortable with a Tizen device where Weston, murphyd and
 weekeyboard can't read or (worse) write my PIM data.

weston (or the display server) can just remote control your pim app,
monitor all keyboard input for passwords and more and just control the
app to export the data one way or another. it has to be assumed that
something like a displayserver etc. is already priveleged as everything
you see and all you input goes through it.

 Whether it's worth investing extra effort is up to the people defining
 the product and its requirements.
 
  - DAC and MAC are still here filtering real intrusions

 But that doesn't help when the uid and smack label are the same.

 Regarding leaving details of multi-threading to the integrator:
 that may simplify the work for the lib developer, but it complicates
 the usage of the lib for service developers, in particular if those
 services are not yet multithreaded. Just saying.

 Agreed too. But remember only if it doesn't want to block.

 My expectation is that services will not be allowed to block. So either they
 are multithreaded, asynchronous or both. Cynara as currently designed does
 not fit into services which are asynchronous, but not multithreaded.

 Do we have services that are asynchronous, but not multithreaded?
 I'm all in favor of generality, but I don't believe in solving problems
 that we don't have.
 
 As Jussi said, at least in the glib-based world, asynchronous without
 multithreading is the preferred model. If you need a specific example:
 syncevo-dbus-service, implementing the PIM Manager API in IVI, is not
 multithreaded.
 
 There's one more related issue with having a single blocking API
 function: suppose a service did create a thread to invoke that API and
 then while the check still runs needs to shut down cleanly, or (perhaps
 more realistic) the client asking for the restricted operation quits. A
 service must be prepared for this, even if it is only in the error
 handling paths. Can the service cancel the running call into Cynara?
 
 If it can't then it can only kill the thread, without knowing in which
 state that thread is.
 
 Cynara also needs to be thread-safe itself internally, of course.
 

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Cynara

[Carsten Haitzler]

On 04/10/2014 07:08 PM, Jussi Laako wrote:
 On 10.4.2014 12:21, Carsten Haitzler wrote:
 weston (or the display server) can just remote control your pim app,
 monitor all keyboard input for passwords and more and just control the
 app to export the data one way or another. it has to be assumed that
 something like a displayserver etc. is already priveleged as everything
 you see and all you input goes through it.
 
 At least from gSSO perspective, display server only has narrow time
 window when it can capture the input. After that point it cannot access

all input goes thru the display server. thus it has all the time in the
world to capture anything it likes. if it's malicious you're up the
creek without a paddle. the input goes THROUGH it via the display server
protocol (socket) it actively reads input devices and
munges/passes/routes data onto gui clients.

 the data unless it can impersonate it's kernel process as being some
 other process. And it may not be sufficient anyway like entering PIN
 code for smart card, since display server process wouldn't be allowed
 have access to the smart card.

if a user can input it. the display server can fake it. if ths smart
card is already plugged in (incredibly likely) it'll work fine.

 This because in typical cases applications cannot retrieve the stored
 data, only ask operations to be performed using the stored data and this
 is still subject to per-process access control enforced on the IPC.
 
 Think this as similar to popping up pinentry (used by gpg) and then
 performing write to a write-only database. Or similar to fusing
 properties to hardware. Only attack surface it at the point of
 performing the write.
 
 But email application shouldn't be able to read your PayPal password,
 should it?

it wouldnt need the password. if the paypal app can transfer money (lets
say any useful app can do things like this as thats the job - to do such
things for a user), then the display server, if it so chooses, can just
trigger the launch of the paypall app (while you're not looking and
screen is off). it can go punch in a pin number or password. click on
the buttons needed to start a transfer, enter numbers for destination
account, amunt etc, then close off the app without you being any the
wiser. the display server can get access to display pixel data and ocr
the data if it really wants, so it can read like you can. the smarter
and more dedicated the programmer behind a malicious display server, the
more he can do.

the display server is by its sheer nature and the data that goes through
it, a trusted process that you'd better hope you trust, and if yuou
don't, then tell me - how do you trust the kernel not to sanoop in on
all of this too? if you can trust the kernel, you can grant trust to
other elements of the system necessary for making it work.

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] (RFC) FreeRDP for Weston into Tizen

[Carsten Haitzler]

ELM_ENGINE is actualyl right for the env var. :)

On 04/05/2014 01:49 AM, Manuel Bachmann wrote:
 Hello folks,
 
 I very recently pushed a request to get the FreeRDP package into Tizen.
 
 If it's accepted, it will allow to compile Weston with the RDP protocol
 support. Using this, we will be able to :
 - run one or multiple Weston instances on a Tizen device ;
 - accessing them remotely, from a station running Linux, Win32,
 Android... in a way similar to VNC, but with better performance :
 
 Here is a video sample of Weston running with FreeRDP :
 https://www.youtube.com/watch?v=rSTswsuDK54
 
 I personally see at least 2 use-cases :
 - development, debugging without need to have a device at hand ;
 - displaying end-user applications remotely.
 
 As for the current limitations, you cannont currently run GL-accelerated
 applications through RDP, so you have for example to degrade EFL into
 software mode to make them run.
 
 Initial request :
 https://bugs.tizen.org/jira/browse/TINF-539
 
 Please comment and give your impressions on this !
 -- 
 Regards,
 
 /*Manuel BACHMANN*
 Tizen Project
 VANNES-FR/
 
 
 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev
 

-- 
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.



signature.asc
Description: OpenPGP digital signature
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] [SDK/Emulator] Discuss about remote GL acceleration.

[Carsten Haitzler]

Title: Samsung Enterprise Portal mySingle

  
  

On 03/24/2014 04:56 PM, SeokYeon Hwang
  wrote:


  
  
  
  
  
  Unfortunately it doesn't work.
  We should try to find the way.
  
  Anyway, is there no way to enable GL acceleration on windows
RDP ??
  Even thoughit could not draw on real display - we can not see
that, It's OK.
  It can be used for remote display or remote auto testing.
  
  


include your own osmesa library with the emulator and explicitly use
osmesa (with its own osmesa "eg" layer). you now use the cpu to
render gl, and push out puxels manually from the osmesa buffer. it
works. on a fast enough cpu it's usable (but not brilliant).


  Thanks.
  
  --- Original Message ---
  Sender : Stanislav
Vorobiovs.vorob...@samsung.com Expert Engineer/SRR-Tizen
S/W Group/
  Date : 2014-03-19 16:19 (GMT+09:00)
  Title : Re: [Dev] [SDK/Emulator] Discuss about remote GL
acceleration.
  
  Hi,
  
  I see. Is jenkins agent configured as a windows service ? If yes,
  m.b. this can help:
  
http://jenkins-ci.361315.n4.nabble.com/DirectX-and-Jenkins-td4525448.html
  
  IMHO this problem is not related to RDP at all, jenkins does not
  use RDP, it simply runs your app
  and can't initialize OpenGL since service may not be allowed to be
  interactive. Does jenkins slave
  service has "allowed interactive" enabled in service properties ?
  
  On 03/19/2014 10:51 AM, SeokYeon Hwang wrote:
   We already running auto-test exactly same method described
  that instruction.
   
   We can run emulator and can do test, but we can not enable GL
  acceleration and can not run GL test.
   
   Maybe, the jenkins JNLP agent using windows RDP logic.
   
  
   
   You can test it using "windows remote desktop".
   
   1. In PC (A), Windows, open "cmd" window.
   
   2. Run "[TIZEN_SDK]/tools/emulator/bin/check-gl.exe". It may
  produce positive results.
   
   3. In PC (B), connect to PC (A) via "mstsc.exe" (Windows
  Remote Desktop client).
   
   4. You can see already opened "cmd" window that contains
  positive result of "check-gl.exe".
   
   5. Run "[TIZEN_SDK]/tools/emulator/bin/check-gl.exe". It may
  produce negative results.
   
  
   
  
   
  
   
   --- *Original Message* ---
   
   *Sender* : Stanislav Vorobiov Expert
Engineer/SRR-Tizen S/W Group/
 
 *Date* : 2014-03-19 14:58 (GMT+09:00)
 
 *Title* : Re: [Dev] [SDK/Emulator] Discuss about remote GL
acceleration.
 

 
 Hi,
 
 I didn't use jenkins for quite a while and I don't have it
installed to check, but
 it seems that jenkins can run tests using interactive
logon, thus, it can run accelerated apps.
 
 Some quick googling shows:
 

http://stackoverflow.com/questions/19441324/how-to-run-gui-tests-on-a-jenkins-windows-slave-without-remote-desktop-connectio
 
 On 03/19/2014 06:25 AM, SeokYeon Hwang wrote:
 We are running auto-test using "jenkins".

 A "jenkins" master node trigger "tests" in slave nodes
with various OS via JNLP Agent.

 We can use GL acceleration with linux, macos slaves,
but we can not use it with Windows slaves.

 That is our issue currently encountered.



 Thanks.



 --- *Original Message* ---

 *Sender* : Stanislav VorobiovExpert Engineer/SRR-Tizen
S/W Group/

 *Date* : 2014-03-18 21:36 (GMT+09:00)

 *Title* : Re: [Dev] [SDK/Emulator] Discuss about remote
GL acceleration.



 Hi,

 Thanks, but our case is to run the emulator itself
remotely, i.e. this is a little different.

 BTW, TigerVNC indeed works, OpenGL apps and emulator
can be launched remotely but within a single session.
 SeokYeon, will that do for auto-tests ?

 On 03/18/2014 04:05 PM, Roman Kubiak wrote:
 x11vnc works well, i tested it with the M0 target
and got the tizen display from the phone on my desktop. I
remember doing the same trick @home with XBMC, and i know XBMC
uses some sort of hardware acceleration technique to run so
x11vnc mirrors that, but
 you'll need to install it inside the emulator, i
had to build it myself for ARM.

 best regards
 On 03/18/2014 12:50 PM, Stanislav Vorobiov wrote:
 Hi,

  

Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User Environment

[Carsten Haitzler]

On 03/20/2014 07:33 PM, Jussi Laako wrote:

On 20.3.2014 11:28, Carsten Haitzler (The Rasterman) wrote:
but that still is not the same level of security for OPENING the car 
door and

starting the car. ivi does not require the same level of security as the
potential damage of someone who is SITTING in your care and using the 
ivi system
(hey are trusted enough to sit in your car), vs someone outside of 
your car, at
3am when you are asleep trying to break in to steal the car. vastly 
different

level of consequences due to a security breach, thus likely need vastly
different amounts of attention security-wise.


It needs more security, because the consequences of someone stealing 
your information can be much more severe than someone stealing your 
car. Insurance covers stolen car, but usually not stolen information. 
If you access your company email from the car IVI system for example 
(or mobile device for that matter)...


i seriously doubt any ivi system i ever have will have more than music, 
movies and maps in my car, so i can guarantee you, the vastly more 
valuable thing to lose is the car.


You already get set of requirements if you want to certify your device 
for MS Exchange access (policy enforcement etc).


Each user still needs to be authenticated properly, especially if they 
have their Google Wallet or Facebook credit card accessible behind the 
authentication system.


At least here for example taxis are just ordinary cars, usually 
something like Skoda Superb or Mercedes E-class. Same goes for driving 
school cars, those tend to be ordinary stuff like Skoda Octavia.


not if data has been backed up. as most peolpe just hand their data 
to google
etc. all their emails are there. all their facebook messages are 
there. their


I wonder how many corporations would allow their emails stored there.


enough. i have worked at companies that use google docs for their actual 
work. real life.


http://www.google.com/enterprise/apps/business/customers.html

google trumpet on 1000's uploading their data to their services, handing 
comapny communications, documents and more to a 3rd party (google). my 
point is... your view is biased. there is another side to things. :)


And most ordinary non-privacy aware private persons is not enough to 
steer platform requirements. What if the device is used by government 
officials or company CEO?


contacts are synced to gmail. they already gave their private info 
away for
free and they just get it back. :) ok - i lose my call log and sms's 
- not used

that much anymore. :)


I don't think platform should be designed based on requirements of 
least-security aware users.


no - but at the same time it should not become unusable or undesireable 
because of security for the minority of users.



quick survey of me and 2 other engineers next to me. 0% use encrypted
filesystems. i can tel you no one in my family uses them either. sol 
add a few
more there. i actually personally know no one who uses this feature 
on their
phones (that has in any way indicated they do - they may or may not 
use it, but
they haven't said so), so my really quick survey of ENGINEERS around 
me says...

this is not commonly used. you're likely not in the majority. :)


Or they don't know, because it is just silently enforced by the 
Exchange account policy?


no. my phone is my phone. company can't say squat diddly about it. i 
paid for it. it's mine. my property and my rules. that is the same case 
for every single enigneer around me. NONE of them had a phone given to 
them by their company. they are personal phones paid for and owned by 
them, on their own phone plans.



Again, majority in which category and geography?


i was making a point. your point is that no one at ALL uses unecrypted 
phones. your point of view is just your own world. stand aback and look 
at the bigger picture. what you do and what everyone does.. are 2 vastly 
different things. that's the point i'm trying to make. your view is 
colored by just what you see immediately around you and you arer 
applying it to everyone.


Almost 40 percent in our survey didn’t take even minimal security 
measures,
such as using a screen lock, backing up data, or installing an app to 
locate a

missing phone or remotely erase data from it.


Some will only learn the hard way when their device is lost or stolen.


and many will just never care. my phone has no personal information on 
it that isn't already shared and public. my phone cant do banking or 
share trading without and ADDED password auth (in fact cant to banking 
at all). the only email account it has access to is my throw-away email 
account i use to appease accounts i don't care about. i don't have any 
company data or email on the phone.


since my phone is in a case that also holds my credit cards, if i lost 
my phone i'd be in far more trouble of people misusing my credit cards 
than anything else. forget the phone and data there. it's the credit 
card

Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User Environment

[Carsten Haitzler]

On 03/21/2014 12:23 AM, Schaufler, Casey wrote:

-Original Message-
From: dev-boun...@lists.tizen.org [mailto:dev-boun...@lists.tizen.org] On
Behalf Of Carsten Haitzler
Sent: Thursday, March 20, 2014 2:28 AM
To: Jussi Laako
Cc: dev@lists.tizen.org
Subject: Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User
Environment

On Thu, 20 Mar 2014 10:44:20 +0200 Jussi Laako jussi.la...@linux.intel.com
said:


On 20.3.2014 2:33, Carsten Haitzler (The Rasterman) wrote:

yes - but ivi wont be authenticating access to the car (ie the
door), so security is less of an issue compared to a fob that can
open the car door and turn it on.

Well, it would still authenticate with the key fob to recognize the
user. You don't get same result with two different key fobs.

but that still is not the same level of security for OPENING the car door and
starting the car.

It is unreasonable to assume that no auto manufacturer
will combine IVI and control systems in the interest of
saving a few thousand won. When they do, and people
get killed after it gets hacked, who is going to get blamed?
Not the User Experience people. It will be the security people.
You can talk all you want about proper use and the like,
but in the end schedules and costs will lead people to do
stupid things. That's why we want to do our best up front.


actually the person who decided to use the ivi system to auth vehicle 
access wil get blamed., he/she decided to use a system that doesn't meet 
such requirements. unless the security guys were asked is this ok to 
use for a car door and they say yes... then the blame will get passed.


on the flip side of that coin. if a product is made and it sales are 
abysmal... and then some investigation reveales customers ran away in 
droves because user experience sucked. guess who gets blamed for causing 
a company to lose millions of $?


this isn't a one sided issue.


ivi does not require the same level of security as the
potential damage of someone who is SITTING in your care and using the ivi
system (hey are trusted enough to sit in your car), vs someone outside of
your car, at 3am when you are asleep trying to break in to steal the car. vastly
different level of consequences due to a security breach, thus likely need
vastly different amounts of attention security-wise.


I was planning to construct ecryptfs home directory encryption key
using the key fob or NFC. I can also support multiple authentication
methods for the same storage, such as keyfob, NFC tag or passphrase.

Usually my goal has been that even if you desolder the flash chip from
the hardware and NSA puts it on their hacking bench they cannot get
the data out.


factory reset from bootloader then re-setup account login+pw for
play/market and u can get all your apps back... :) in fact android
handsets, last i played,

That's equivalent of buying a new device, it's not a recovery, it's a

it's not the equivalent. you don't spend another $500 or $1000. very far from
it. :)


complete device wipe. Btw, do you know how to make a factory reset
from bootloader? Manual doesn't say anything.

yes. a quick googling will show you how for many models of phone etc. no i'ts
not in the manual they give you in the box, but it's documented.


Yeah, I can reinstall applications, but all my data is gone. I don't
worry about applications, I have something like five of them.

not if data has been backed up. as most peolpe just hand their data to google
etc. all their emails are there. all their facebook messages are there. their
contacts are synced to gmail. they already gave their private info away for
free and they just get it back. :) ok - i lose my call log and sms's - not used 
that
much anymore. :)


- it could just reset screenlock mode on the host. as long as it can
get fs access to the internal storage. if it's encrypted and you
forget your encryption key... then you're in trouble. factory reset
method then for you. :)

If there's a way to get past the device lock code, it's a really bad
security bug.

Who wouldn't have their device encrypted these days?

quick survey of me and 2 other engineers next to me. 0% use encrypted
filesystems. i can tel you no one in my family uses them either. sol add a few
more there. i actually personally know no one who uses this feature on their
phones (that has in any way indicated they do - they may or may not use it,
but they haven't said so), so my really quick survey of ENGINEERS around me
says...
this is not commonly used. you're likely not in the majority. :)

http://consumerreports.org/privacy0613

Almost 40 percent in our survey didn’t take even minimal security
measures, such as using a screen lock, backing up data, or installing an app to
locate a missing phone or remotely erase data from it.

extrapolate that. if they don't even bother locking their scree.. do u think
most people encrypt their filesystems? just remember. you're not in the
majority. not by a long shot. :)


yeah. the nsa agrees

Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User Environment

[Carsten Haitzler]

On 03/19/2014 12:38 PM, ANUJ MISHRA wrote:

Just a thought:
Until now all devices used to boot with default user, so default user need not 
to enter password to access device profile. But, in case of
multiuser environment default user should protect its account by password. 
Incase he forgets his password

How easy for default user to recover/reset his own password? In same way, how 
difficult for another user not to break-in into device?
Also, what will be the method to recover password for default user? In case of 
Linux environment, there is some method to recover
root password, but it is very difficult.


that is in fact a good point. so either we lock down security to the 
point that other than finding exploits, it's unbrakable (and then if you 
forget your password your device is a brick, effectively, and without 
hardware level intervention - eg jtag, you can't do anything. a properly 
secure device would even disallow jtag override), or we leave a hole, 
that requires a fair bit of effort and jumping through hoops, but allows 
you to regain control of your device, BUT this means that this hole is 
known and can be used to break the password of the device owner.


imho it's the same position as allowing developers root acces if they 
need/want it. it's a security hole required for sheer practicality. in 
this case to have users not send devices in for warranty repair alll the 
time going it's locked. if it is impossible to unlock or you charge 
them a fee, then there is a godo chance users will avoid buying similar 
devices in future. same story for developers.


so you just have to make the ability to recover your access something 
that is not trivial. ie it takes some time and effort, and perhaps some 
extra equipment (a pc) and requires physical access to the device. if 
you loan your phone to someone you already are trusting them. you 
already trust them not to throw the phone into the ocean or drive their 
car over it etc..


same for developers - soem random person must not be able to take your 
phone, plug it into their pc and instantly have root without some form 
of authentication that this is the actual owner of the device, but the 
owner (developer) should have that freedom.



--Anuj Mishra

--- Original Message ---
Sender : Clark, Joeljoel.cl...@intel.com
Date : Mar 19, 2014 11:43 (GMT+09:00)
Title : Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User 
Environment

You can add to the list (for IVI devices at least) multiple 3G modems, Multiple 
BT modems, multiple SIM cards, multiple displays and connected to multiple 
handsets (smartphones) with simultaneous streaming of media by different users 
to the different displays, etc

Regards
Joel

On Mar 18, 2014, at 7:25 PM, Bumjin Im wrote:


Never thought of such scenario that a device has multiple SD card slots for different 
user. This will be another issue to track to. I don't have good idea yet but I think we 
can make use of some daemons which take care of mount and usb insertion with 
some policy.

Bumjin

-- May the Force be with you 

* BumJin Im
* Senior Engineer,  Mobile S/W Platform lab, S/W Platform Team
   Samsung Electronics
-




--- Original Message ---
Sender : Jos? Bollo
Date : 2014-03-18 23:41 (GMT+09:00)
Title : Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User 
Environment

On mar, 2014-03-18 at 00:22 +, ??? wrote:


For external memory cards, we are thinking that
the use of links in the home directories is needed
for applying quotas (see below page 7). Mounting
memory cards would imply the creation/synchronisation
of the links and of the data on the card. For example:
on the card, should exists the directories:
- /home/user1...usern
- /opt/...
and the main FS would have the links:
- /home/user1/sdcard - /mount/sdcard/home/user1
- /opt/sdcard - /mount/sdcard/opt
That is our draft idea.
[Bumjin] My point was that the SDcard cannot be access
controlled when it's plugged off and plugged in to window
machine. If we cannot fully enforce, then we should untrust.
That was the simple reason.

You are right, I agree. Maybe was I confused between external memory
card and device media storage. But part of the proposal may still be
accurate.

I still think that if a user plug a memory SDcard or USBkey, its data
should not be shared by default. That use case is complicated. For
multi-seat configuration as what for IVI, the scenario is that the
device will be by default associated to the seat's user.

Best regards
José

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

___
Dev mailing list
Dev@lists.tizen.org

Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User Environment

[Carsten Haitzler]

On 03/13/2014 09:12 AM, Bumjin Im wrote:

As I mentioned before, I haved focused on usage scenario. Technically most of 
the things are just matter of policy configuration, but wanted to remove 
complexity as much as possible.
Answer inline.

--- Original Message ---
Sender : c.haitz...@samsung.com
Date : 2014-03-12 19:26 (GMT+09:00)
Title : Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User 
Environment

1.

i would disagree with only default user is able to install  uninstall
applications. it sounds like an artificial limitation to work around our
installation of apps in system dirs.

i would say only default user can install/uninstall *SYSTEM* apps unless they
grant access to other users to do this too (eg use some group and place other
users in the same group that allows this - default user is in that group by
default). system apps are available to all users. user installed apps are only
available to that user. user installed apps of the same name override system
installed apps when executing an app.

[Bumjin] This is because of complexity reduction. Let's say a usage scenario.
Assuming that there are 3 users in a device, user_1(owner, who pays the bill),
user_2  user_3 (not bad guys, able to install apps but could be selfish)
user_1 installed a hot_porn app for $20, and did not allow to run the apps to 
any
  users.
The hot_porn app can send prem can send premium SMSs to get in-app-purchase
contents.
user_2 does not know the existence of hot_porn app, and he tries to install 
it again.
However user_3 does the same thing and user_1 gets trippled pay bill next month.
Another scenario... user_2 installs hot_porn, and downloaded many hot 
contents.
user_3 didn't like it and remove it. Who gonna pay user_2's lost money?
We ended up with the simplest setup for this becuase money has involved a lot.


user_2 and user_3 should be able to happily install the app... just 
user_2 and 3 are barred from senging sms's. if user_2 and user_3 just 
have access to the dialler or messaging subsystem they can do the same 
thing without installing anything - send sms's to premium sms numbers 
and cause a bill. this has nothing to do with app execution or 
installation permissions, but permission to access a service that can 
CAUSE someone to have to pay a bill. pretend user_3 just kept sending 
sms's to their friend... while roaming... and every sms costs $1. they 
send 500+ a day because user_2 is a teenager who loves to chat with 
friends all day and has no idea of the cost they are incurring. same 
scenario.


security here should be done at the service access level (access to 
sending an sms, or sending to known premium numbers) and non-authorized 
usres are simply denied. if every user installs their own apps in their 
own dirs - they are in charge. they can install or remove their own 
apps. no other user apps can be touched. system installled apps (in 
/opt/ as opposed to $HOME) are controlled by the admin (owner) user. 
any credentials for billing per apps should be stored in $HOME - per 
user. billing like for calls and sms that is done for the account holder 
as a whole, should be allowed to be restricted by the owner (person 
being billed). :)




2.

the above impacts all files and dirs owned by root for apps. this also nicely
avoids worrying about setuid root binaries in apps... their files are never
owned by root... so who cares? :)

[Bumjin] Even in Tizen 2.2, all(most?) files are owned by root except for
/opt/home/app/ and /opt/[appid]/data. What do you want to point out?


apps installed AS the usr id... belong to THAT user id. you don't need a 
shared app location with mixed user id's (right now it's all root except 
indeed data... and /opt/home/app .. these are owned by app... which just 
smells wrong to me). if apps are installed in $HOME/apps/ (or somewhere 
else in $HOME) and are owned by the user... unlike now where the 
binaries are owned by root, then you don't have the possibility of a 
setuid root binary in a pkg. binaries are installed by the user in the 
user dir with user permissions. user can delete them. like any files 
they own. no special permission needed.




3.

why is there a group id per app? what purpose does this have? it sounds like a
needless complication (and surely is not sensible if apps are installed as a
user). is this for defining per user access to system apps?


yeah. just saying that a group per app really isn't even needed if users 
install their own apps. if its personal - no other users have acces. if 
its system installed, other users do. credentials for logins, accounts, 
billing are private per user except for billable services like 
sms/calls/data usage on 2g/3g/lte etc. and these should all have access 
policies settable by the owner and enforced by system daemons.



4.

device media storage ... shouldn't this just be spread across /home so all
users already use it? we can use quotas if we want to limit usage per user.

[Bumjin]
Device 

Re: [Dev] [Multiuser] Security Policy Proposal for Multi-User Environment

[Carsten Haitzler]

1.

i would disagree with only default user is able to install  uninstall
applications. it sounds like an artificial limitation to work around our
installation of apps in system dirs.

i would say only default user can install/uninstall *SYSTEM* apps 
unless they
grant access to other users to do this too (eg use some group and place 
other

users in the same group that allows this - default user is in that group by
default). system apps are available to all users. user installed apps 
are only

available to that user. user installed apps of the same name override system
installed apps when executing an app.

2.

the above impacts all files and dirs owned by root for apps. this also 
nicely

avoids worrying about setuid root binaries in apps... their files are never
owned by root... so who cares? :)

3.

why is there a group id per app? what purpose does this have? it sounds 
like a

needless complication (and surely is not sensible if apps are installed as a
user). is this for defining per user access to system apps?

4.

device media storage ... shouldn't this just be spread across /home so all
users already use it? we can use quotas if we want to limit usage per user.

5.

configuration of device i think should be allowed to other users... based on
what the default user decides - eg add user X ro group wifi and thus 
they can
configure wifi (but not bluetooth, unless added to the bluetooth 
group). we

don't have to IMPLEMENT the support for adding other users to such groups to
start with, but allow for it in future and ensure we implement the 
appropriate

security checks in daemons that configure these things.

6.

developer support should be assignable to any set of users. imagine i have a
small company. i buy 10 phones for my developers to use, but they share 
them.

they each have users/logins on these phones, each with their own
config/data/setup, but they all are developers doing development and 
they have

10 DIFFERENT phones to test different models and features of hardware and
swap.share them around as needed to save money. same for developing
application can be launched only as default user and developer user. :)

7.

shell prompt for developer should only support developer user... no. we 
NEED to

be able to change user id. we need to be able to switch smack labels. app is
being used as developer, you now suddenly have a bug. it's using 100% 
cpu and
you don't know why. normally i'd ssh in, sudo or su - to the user 
logged in

and then strace -p PID. if there is no way to become the uid of the given
problem app we are in trouble and can't figure out what's going on. same for
gdb attaching to that problem process etc.

provide a way to do this - it may be sudo + password (set up when developer
mode is set up) or some special setuid root tool that does this auth + 
switch,

but it's something we need and developers will demand.

8.

/home/username/dbspace ... please NO! /home/username/.dbspace if 
anything ...

hide it by default. and if anything... a db is just config - same thing. it
should just be initted by the app or daemon or lib when/if neeeded. eg 
if it's

email maybe /home/username/.config/email/ or for
contacts /home/username/.config/contacts or if its a db for a facebook
app .. /home/username/.config/facebook/ - inside these dirs they can do
whatever they like. freedom to put sqlite db;'s or xml files or plain 
text or

small furry animals.

9.

per system installed package ... peer user data
(/opt/apps/[pkg_name]/data/[user_name])... sounds .. wrong to me.

On 03/12/2014 10:04 AM, ??? wrote:

Hi all,

We have investigated what the security policy should look like in the 
multi-user environment considering various usage scenarios. I believe 
multi-user support is a platform wide and full vertical task that everybody 
should be involved, so please review the attached proposal and it'll be happy 
to hear any feedback.

Bumjin


___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev


--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] [Multiuser] gumd further work (reject)

[Carsten Haitzler]

On 03/12/2014 07:27 PM, Jussi Laako wrote:

On 12.3.2014 11:41, Carsten Haitzler wrote:

imho most of these are legacy mistakes we have had to live with. we
shouldn't emulate them in apps, daemons or libraries. the mail and spool
at least. /dev/mqueue /var/tmp or /tmp (and /var/run/username) are well
known locations that can be cleaned up.


We still have to be able to deal with those. gumd is not written to be 
specific to Tizen, it should work on any Linux distro.


There's no standard way to list/find items in mqueue/sem/shm or Linux 
anonymous socket (AF_UNIX name prefixed by \0) namespaces so we cannot 
clean up those and I don't think it is straight as a job of gumd.


well you could just do the equivalen of find / -print -uid ID -exec 'rm 
-rf' :)


/var/run/username is cleaned up PAM, because it is specified that it 
must not survive across sessions.



any resouce stil around is now accessible by the new user recycling the
uid. shm/semaphores/mqs honestly should be cleaned up on clean exit of
any user processes that use them (unlink them etc.). (they can leak and
hang around though on unclean exits). if you still are running processes
as the uid on deletion... then that needs to be fixed by ensuring they
are all terminated on user delete.


We terminate the processes on user deletion, but especially if we need 
to SIGKILL those, anything that would need unlink to be cleaned up 
will be left over.


I would say Unix multiuser as such is racy when it comes to 
adding/deleting users. There's nothing across the system to enforce 
those operations to be atomic in overall system scope.


you should at least be NICE and first kill with a SIGINT ... and wait a 
bit for them to exit. if they are still around after a few seconds (lets 
say 5) then SIGKILL them. sigkilling out of the box is just rude. :)



___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev



--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] [Multiuser] gumd further work (reject)

[Carsten Haitzler]

On 03/12/2014 02:22 AM, Stéphane Desneux wrote:

Hi all,

I agree: if things can be done without hooked scripts at user creation
time, it's clearly better. This also means more commitment on the
multiuser topic from developers and maintainers, which is also a good thing.

Now, having this consensus raises another question: if I suppose that we
support user deletion (please confirm that assertion !), what happens at
user deletion time ?

NB: for actual resources not in user homedir, the tizen-platform-config
package will help to move easily some files from /opt to /home simply by
changing the global tizen-platform.conf file (this is anticipated).


there should be no resources outside a homedir. simple. if there is a 
default system config - it is owned by the system. it stays because any 
newly created user will copy/start with that config (and if 
needed/desired write a copy of that to $HOME/somewhere). if there are 
user resources outside the users homedir (other than temporary things 
like /tmp or /var/run that can get nuked at a reboot etc.)... it's just 
plain wrong™. :) it's the app's job to deal with loading a system config 
if no user config is done, to deal with writing out user config, 
handling config upgrades etc.



I see at least two cases:
-1- a user-specific resource is stored INSIDE the user home dir
(database, files ...)
-2- a user has objects or is referenced OUTSIDE his/her homedir (global
database, global files ...) for example the media-server or package manager.


as above. #2 is just wrong (tm) if this data is user-related. rpm db is 
not user-related data. it's system related and managed by the system. 
user can read it, but not modify it (unless root - and if root then root 
is modifying the system). this would be the case for any other system 
data. same story.



If removing the user also removes his/her homedir, there's no problem
for case 1: all user related object will be removed correctly.

If we exclude deletion hooks on gumd, how can we deal with case 2 ? I
mean: what is the link between gumd and the daemons responsible for
those global, user-related resources ?

A solution can be to run the cleanup procedure at system start time (or
daemon start).
Pro: this would delete the resources associated to deleted/non existing
users later at next reboot
Cons: next reboot maybe longer


assuming a reboot to clean up imho is a bad move, but as above... case 2 
just shouldn't happen (IMHO).



Other ideas ?

Thanks for feedback.



--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Linux Containers on Tizen

[Carsten Haitzler]

imho apps installed by a user... should live in $HOME. just like config 
aand data. then all of these problems are solved. :) system apps (things 
that are globally shhared between all users) are installed on the system 
(/usr, /opt etc.). i just think that our current app model is wrong and 
creates these kinds of problems and neceesitates overcomplicated 
solutions. :(


On 03/11/2014 11:14 PM, Jan Olszak wrote:

When I give my phone away I'm not only concerned about what this user can
do, but rather what the applications that he will install can do. In this
case starting a container would give you greater protection than just
creating a new user. So yes, maybe containers could be a good technology to
implement this.

Not Umbrella Containers operate under the assumption that we all failed -
that there is a hole and a malicious application can use it to do stuff. NUC
would place a concrete wall between the private and business environments,
so malicious apps still can do stuff but only in one environment. That is
the use case we are concentrating on.
The main threat for the security of the user is the user himself. I would
accept any set of permissions just to get this Tree Climbing Game I long,
but at least I wouldn't imperile my business data.


Thanks,
Jan

-Original Message-
From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
Sent: Tuesday, March 11, 2014 11:33 AM
To: MyungJoo Ham
Cc: Schaufler, Casey; Jan Olszak; dev@lists.tizen.org
Subject: Re: [Dev] Linux Containers on Tizen

On Tue, Mar 11, 2014 at 01:56:33AM +, MyungJoo Ham wrote:

Not related with multi-user project at least for now. It is an
independent project and it does not assume that the two domains
have different users.

In thhe first mail there was a use case where you would give your phone or
tablet to your child. Should multi-user address the same use case or not?

The main difference I see with multi-user and this is that:

1. Multi-user is a feature and proper technologies are chosen to implement
it.

2. Containers (not that well defined umbrella term for linux namespaces and
cgroups when you combine them) is a technology.
You might use parts of it for implementing features such as multi-user
support.

With my limited knowledge of this effort it really looks like as someone was
climbing feet first into the tree.

/Jarkko


___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev



--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] [Multiuser] gumd further work (reject)

[Carsten Haitzler]

On 03/11/2014 09:45 AM, Schaufler, Casey wrote:

-Original Message-
From: Carsten Haitzler [mailto:ti...@rasterman.com]
Sent: Monday, March 10, 2014 5:05 PM
To: Dominig ar Foll (Intel OTC)
Cc: Schaufler, Casey; Leonard Milcin; dev@lists.tizen.org
Subject: Re: [Dev] [Multiuser] gumd further work (reject)

On Mon, 10 Mar 2014 17:24:42 +0100 Dominig ar Foll (Intel OTC)
dominig.arf...@fridu.net said:


Hi,

until said otherwise, I am the architect in charge of Multi User and I
will repeat for those who missed it, what I said in an earlier mail.

I do not think that the model of adding, to the module in charge of
creating new users in the system (useradd, gumd or any other), App
specific user resource creation tasks such as DB, directories, config
files, ...
Such model is an ugly hack, which will break rather earlier than later.

Application knows what resources they need in relation to a specific
user at installation as well as later during update or upgrade.

Those tasks need to stay with the Apps themselves.

Until someone convince me that I am incorrect in my statement about risk
on system stablity on the long term, I will not accept to off load these
App specific resources creation to the useradd service in Tizen.

Apps developpers, that is your job.

I would agree. it's the job of an app to work with an entirely empty user
directory, and work sensibly. what sensible is isa matter for the app in
question. if the app insists on having a database in the user homedir - then
app must create it if db not found and populate it with initial data. if db is
corrupt - app must deal with it (fix db, nuke it and start again etc.). same
for config etc.

Perfectly sensible once we address the case where two apps want
to use a file named Configuration. Does the first app get it? The
second? If we agree on a convention that all application specific
files go in the application's directory (or some other differentiation)
we'll be fine. But we need to do that, and be clear about it.


i would have thought that was already assumed. 2 apps sharing the same 
config is just asking for trouble unless they carefulyl negotiate 
ownership with locks etc. - and if they do then they're fine. if they 
don'tthey have inherent bugs already that need fixing regardless and 
this is a good kick in the behind to force those to be fixed. :)




  

Dominig ar Foll
Senior Architect
Intel Open Source Technology Centre


___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev



--
Carsten Haitzler (The Rasterman) ti...@rasterman.com

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev



--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] sdbd or sshd (was Re: pam module for Smack)

[Carsten Haitzler]

On 01/22/2014 06:10 PM, Negreanu, Adrian M wrote:




On Wed, Jan 22, 2014 at 10:55 AM, Carsten Haitzler
c.haitz...@samsung.com mailto:c.haitz...@samsung.com wrote:


On 01/22/2014 05:46 PM, Negreanu, Adrian M wrote:




On Wed, Jan 22, 2014 at 1:58 AM, Carsten Haitzler
ti...@rasterman.com mailto:ti...@rasterman.com wrote:

On Tue, 21 Jan 2014 11:28:03 -0800 Ryan Ware
ryan.r.w...@intel.com mailto:ryan.r.w...@intel.com said:

  Tue, Jan 21, 2014 at 2:01 AM, Jussi Laako
jussi.la...@linux.intel.com
mailto:jussi.la...@linux.intel.comwrote:

  On 21.1.2014 10:38, José Bollo wrote:
 
  IMHO, SDB is integrated with the developer tools and
that is really
  good. But it is not sure at all: you can become root on
the device
  without being asked for any password, just a USB cable
is needed. Also
  SDB is a component that is not common, not proven, not
linked to PAM,
  and, that must be maintained at our cost. Just my 2 coins.
 
 
  SDB should require enabling developer mode on the device
itself, it
  shouldn't be enabled by default. Just like ADB (or
whatever it was called)
  on my Android devices. I've enabled it once to flash
CyanogenMOD.
 

 SDB should definitely not be on by default.  Doing so goes
against a number
 of different security principals including reducing
attackable surface area
 and least privilege.

sure - but same applies for ssh. the difference is that when
i enable developer
mode on my device. do some work, go to lunch with my phone
and someone borrows
it for 10 mins (plugs into usb and starts messing around)
they can do so with no
auth at all. zero. if sdb were to turn off every time a phone
is unplugged
we'll have insanely annoyed developers continually finding
menus to turn it on
and eventually deciding tizen is is more pain than anything else.

How about being asked for a password when the USB cable is
plugged in ?
For Android, you get a notification and you can choose whether
you enabled debug mode or not,
which as you say, is not safe.
Instead, you may be asked for a developer password and avoid
digging through menus.
Also, I find sdbd useful when bringing up new platforms, where
network connectivity is not ready yet.


how is network connectivity not there? usb network gadget has been
in the kernel as long as i've been doing phone stuff (since at
least 2008). the kernel emulates a network usb device. you don't
need wifi and other network.

I think we're viewing the problem from two different point of views.
I'm more interested in a device in the bring-up stage where you
might not have OTG ready(thus no USB gadgets),
whereas (I assume) you're interested in a device that's well after the
bring-up stage.
For the latter, when everything works fine, SDBD is indeed optional.



but sing sdb uses the same usb gadget interface to advertise effectively
what is a serial device over usb (i don't know it's details - but it
must logically appear as some custom type/class of usb device) .. thus
it has the same basic requirements of a kernel at this level? sure - you
dont need userspace to CONFIGURE the usbnet device (ip address, route
etc.) for sdb and that is indeed simpler at this stage - but at the
usb/kernel level isn't it basically the same?



as for password - ask on the device screen?

Yup, on the device screen. This means that when I'm not in graphical
run-level, I can use SDBD w/o being asked for
a password.


i suspect that woould become most infuriating to have to enter it every
time on the phone rather than via the far more useful keyboard i have in
front of me right now ... :)





--
Adrian Marius Negreanu
Intel Open Source Technology Center



--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] pam module for Smack

[Carsten Haitzler]

On 01/21/2014 12:22 PM, Yang Chengwei wrote:

On Wed, Jan 15, 2014 at 09:38:32AM +0900, Carsten Haitzler wrote:

On Tue, 14 Jan 2014 16:26:57 +0100 José Bollo jose.bo...@open.eurogiciel.org
said:


On mar, 2014-01-14 at 20:45 +0900, Carsten Haitzler wrote:

On Tue, 14 Jan 2014 11:19:43 +0200 Jussi Laako jussi.la...@linux.intel.com
said:


On 14.1.2014 4:16, Carsten Haitzler wrote:

having a enable ssh option on devices (when you enable developer mode)
would be the best of both options. it's not on by default, but it's a
simple click away.

Just Enable developer mode in device settings would be fine. But I
wouldn't like to have a car that has ssh wide open to the world with
some default password or key... Nor phone either.

i'm fine with that. a single simple checkbox is fine for me :) and agree -
if enabled as a service, it should require you enter a password at that
tome - no default passwords/accounts. perhaps limit sshd to only listen on
usbnet and any wifi etc. networks you tags as trusted. :)


The check box should have a time limited effect. That means that you can
forget to uncheck it, it will uncheck itself after a while.

The check box should also be associated to a kind of password. It is not
acceptable that a developer tool can connect to any device just because
to check box is checked. I'm not saying that a password must be set but
that a password can be set if wanted.

i would say a password SHOULD be set at that time - no defaults. and that
password retained so you don't need to keep re-setting it each time (but able
to be changed too from that menu). if there is a timeout, i would say it should
be a timeout between successful logins on sshd. if there has not been a
successful login in let's say 7 days, turn it off. (that would mean developers
using it all the time at least once per week don't get bothered). or hey - make
the timeout configurable... :) let the developer decide how bothersome they are
willing to accept things vs security.

I'm not sure it's worth a discussion or not about ship Tizen with ssh
service, for me, sdb is useful enough for developers, and it's more
security, at least one need connect a usb cable to the device, if one
can archive your device, then it's done.


ssh offers far more:

* authorized access by passoword and/or ssh key (so if someone gets hold
of your device and plugs it in they can't do anything without auth).
* sshfs. need i say more. much more useful than sdb. :)




--
Thanks,
Chengwei


--
Carsten Haitzler (The Rasterman) ti...@rasterman.com
___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev


___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev


--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] pam module for Smack

[Carsten Haitzler]

On 01/21/2014 02:46 PM, Yang Chengwei wrote:

On Tue, Jan 21, 2014 at 02:03:42PM +0900, Carsten Haitzler wrote:

On 01/21/2014 12:22 PM, Yang Chengwei wrote:

 On Wed, Jan 15, 2014 at 09:38:32AM +0900, Carsten Haitzler wrote:

 On Tue, 14 Jan 2014 16:26:57 +0100 José Bollo 
jose.bo...@open.eurogiciel.org
 said:


 On mar, 2014-01-14 at 20:45 +0900, Carsten Haitzler wrote:

 On Tue, 14 Jan 2014 11:19:43 +0200 Jussi Laako 
jussi.la...@linux.intel.com
 said:


 On 14.1.2014 4:16, Carsten Haitzler wrote:

 having a enable ssh option on devices (when you 
enable developer mode)
 would be the best of both options. it's not on by 
default, but it's a
 simple click away.

 Just Enable developer mode in device settings would be 
fine. But I
 wouldn't like to have a car that has ssh wide open to the 
world with
 some default password or key... Nor phone either.

 i'm fine with that. a single simple checkbox is fine for me :) 
and agree -
 if enabled as a service, it should require you enter a 
password at that
 tome - no default passwords/accounts. perhaps limit sshd to 
only listen on
 usbnet and any wifi etc. networks you tags as trusted. :)


 The check box should have a time limited effect. That means that 
you can
 forget to uncheck it, it will uncheck itself after a while.

 The check box should also be associated to a kind of password. It 
is not
 acceptable that a developer tool can connect to any device just 
because
 to check box is checked. I'm not saying that a password must be 
set but
 that a password can be set if wanted.

 i would say a password SHOULD be set at that time - no defaults. and 
that
 password retained so you don't need to keep re-setting it each time 
(but able
 to be changed too from that menu). if there is a timeout, i would say 
it should
 be a timeout between successful logins on sshd. if there has not been a
 successful login in let's say 7 days, turn it off. (that would mean 
developers
 using it all the time at least once per week don't get bothered). or 
hey - make
 the timeout configurable... :) let the developer decide how bothersome 
they are
 willing to accept things vs security.

 I'm not sure it's worth a discussion or not about ship Tizen with ssh
 service, for me, sdb is useful enough for developers, and it's more
 security, at least one need connect a usb cable to the device, if one
 can archive your device, then it's done.


ssh offers far more:

* authorized access by passoword and/or ssh key (so if someone gets hold of
your device and plugs it in they can't do anything without auth).

I think this is not a common using scenario for a *mobile* device, why
it works like server? Why you don't bring it around you?


someone stelas your device and plugs it in and starts downloading all 
your data. perfectly common scenario. someone borrows your phone while 
you are not looking and tries to download all your data, then repaces it 
- someone just snarfed your data and you don't know. they needed 
physical access - but thats not hard to get.




In the last word, you can setup a sdb over ssh tunnel if you like.


* sshfs. need i say more. much more useful than sdb. :)

I don't know how common sshfs be used in your daily work, but not for
me, I only used it for my tomboy notes sync-up.

For developers (I think mostly app developers), sdb is good enough,
anyone want more, I think he'll manage to root or reflash the device,
then it's a developer-version device.


if your app devsa are the i develop for any os if you pay me enough 
crowd. if that is who we expect to dev for tizen, we had better be 
putting together boatloads of cash. if you go for the i develop because 
i love linux and this tizen os is different to android and everyone 
because its FAMILIAr to me.. it supprots the tools i already know and 
use then keepign ssh is a very good idea. it's playing to strengths 
tizen has, not weaknesses.



--
Thanks,
Chengwei





 --
 Thanks,
 Chengwei


 --
 Carsten Haitzler (The Rasterman) ti...@rasterman.com
 ___
 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev



 ___

 Dev mailing list
 Dev@lists.tizen.org
 https://lists.tizen.org/listinfo/dev


--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under

Re: [Dev] [E-devel] elementary frame for wayland backend ?

[Carsten Haitzler]

On 01/07/2014 10:07 PM, Thiago Macieira wrote:

On segunda-feira, 30 de dezembro de 2013 17:09:16, Carsten Haitzler wrote:

this will require some negotiation before the first buffer is rendered. ie
surface created but not SHOWN... then ask wayland given this surface, if i
showed it, should i draw frames or not?. this kind of negotiation will be
needed for many other things - like requesting what possible screen it may
end up on - or what profile to use. imagine a phone WITH a desktop monitor
attached. does the app display on the desktop monitor in desktop mode
with frames etc. and work with kbd+mouse, or does it display on the mobile
screen with no mouse and fill the screen etc.?

That negotiation is part of the xdg_shell extension to Wayland. We're not
using it in Tizen. If the compositor only supports wl_shell, then the toolkit
decides whether it should show anything or not, opting to showing something in
case of doubt.

You should probably make it a system-wide or compile-time setting.


we SHOULD use xdg_shell. it's not part of core wayland proto atm (in 
wayland src tree in master) so i haven't looked at it. but this SHOULD 
be configured at runtime based on the display. the toolkit can take care 
of decorating or not at that moment. that's the right way to do it that 
means you have less forking in the core os and more dynamic config 
based on context. :)





___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev


--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Update EFL code to latest

[Carsten Haitzler]

On 01/03/2014 03:53 PM, Ylinen, Mikko wrote:


On Thu, Jan 2, 2014 at 4:31 PM, Daniel Juyung Seo 
seojuyu...@gmail.com mailto:seojuyu...@gmail.com wrote:


This sounds ok to me.
By the way, how about naming the branch efl-1.8 or
upstream-efl-1.8 as efl upstream uses efl-1.8 as its stable
branch name?


We should follow the Tizen guidelines [1] here, i.e., pull EFL 
'efl-1.8' branch to platform/upstream/efl 'upstream' branch (v1.8.3 tag),

and git rebase upstream tizen.

And is there any plan to sync tizen efl master with efl upstream
mater?


I don't think we should pull unnecessary branches. Ideally, patches 
from master

are cherry-picked into 'tizen' if needed.


1) tizen 3 is unlikely to see the light of day until the end of 2014 
(this is based on what i actually see of tizen 3 and 
development/activity in terms of actual work going on), master should be 
tracked  because it provides you a smooth path until the release that 
will go into tizen 3. by the time tizen 3 ships efl will have released 
1.9 (1.8 already out as of last month) and 1.10 too - maybe 1.11. so 
tizen has to re-sync then 3 times. (efl is now doing timed releases - 6 
week cycles between releases).


2) reality is that developers developing apps can't wait for the next 
release. they insist on having their feature NOW because some manager is 
breathing down their neck to have it done and they can't until it's in. 
they end up having to keep making reports giving status as to why it's 
not done and they wavoid that like the plague... as they also get yelled at.


what happens then is all the development goes on i tizen's fork of efl 
instead, so it cherry-picks random half-complete features from upstream 
git, and then out goes a tizen release WITH those things in it with a 
gold stamp of quality .. but upstream has since rejected those api's 
or features (or rejected them to begin with but due to the above to make 
someones reporting easier they were put in regardless of upstream 
approval or not), and you end up again in the situation we have now.


i've advised against this method of working repeatedly, to no avail. my 
advice has been to add no new features and only ctricial bug fixes and 
nothing more to tizen git - but that has never happend and i doubt it 
ever will. the situation literally is that tizen efl is such a large 
fork, for tizen3 we have to throw it all out and start again from 
scratch (from upstream). that is exactly what is happening.


if we are lucky people will find/cherry-pick some patches from tizen efl 
into upstream, but many will not as they have already been rejected for 
various reasons. it will happen AGAIN and AGAIN unless this way of 
development changes. as i see no way we can sensibly say sorry app devs 
- you wait 1/2/3 months until a sync from an upstream release to get 
that feature, then it is a NECESSITY to track master. ESPECIALLY during 
such a brute-force reset and start again period that will effectively 
break many/most apps depending on efl due to them depending on a fork in 
tizen.


policy simply fails given the development methods employed here in this 
situation.


this is after 5+ years of experience on this and i see no sensible way 
other than to track master for the purpose of tracking features, and 
track upstream stable for the purpose of putting out stable 
images/packages. both need to be tracked. it's the only thing that will 
work.




-- Mikko

[1] 
https://source.tizen.org/documentation/reference/git-build-system/upstream-package




___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev


--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

___
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Re: [Dev] Update EFL code to latest

[Carsten Haitzler]

On 01/03/2014 09:04 PM, Ylinen, Mikko wrote:


On Fri, Jan 3, 2014 at 11:05 AM, Carsten Haitzler 
c.haitz...@samsung.com mailto:c.haitz...@samsung.com wrote:



On 01/03/2014 03:53 PM, Ylinen, Mikko wrote:


On Thu, Jan 2, 2014 at 4:31 PM, Daniel Juyung Seo
seojuyu...@gmail.com mailto:seojuyu...@gmail.com wrote:

This sounds ok to me.
By the way, how about naming the branch efl-1.8 or
upstream-efl-1.8 as efl upstream uses efl-1.8 as its
stable branch name?


We should follow the Tizen guidelines [1] here, i.e., pull EFL
'efl-1.8' branch to platform/upstream/efl 'upstream' branch
(v1.8.3 tag),
and git rebase upstream tizen.

And is there any plan to sync tizen efl master with efl
upstream mater?


I don't think we should pull unnecessary branches. Ideally,
patches from master
are cherry-picked into 'tizen' if needed.


1) tizen 3 is unlikely to see the light of day until the end of
2014 (this is based on what i actually see of tizen 3 and
development/activity in terms of actual work going on), master
should be tracked  because it provides you a smooth path until the
release that will go into tizen 3. by the time tizen 3 ships efl
will have released 1.9 (1.8 already out as of last month) and 1.10
too - maybe 1.11. so tizen has to re-sync then 3 times. (efl is
now doing timed releases - 6 week cycles between releases).


2) reality is that developers developing apps can't wait for the
next release. they insist on having their feature NOW because some
manager is breathing down their neck to have it done and they
can't until it's in. they end up having to keep making reports
giving status as to why it's not done and they wavoid that like
the plague... as they also get yelled at.

what happens then is all the development goes on i tizen's fork of
efl instead, so it cherry-picks random half-complete features from
upstream git, and then out goes a tizen release WITH those things
in it with a gold stamp of quality .. but upstream has since
rejected those api's or features (or rejected them to begin with
but due to the above to make someones reporting easier they were
put in regardless of upstream approval or not), and you end up
again in the situation we have now.

i've advised against this method of working repeatedly, to no
avail. my advice has been to add no new features and only ctricial
bug fixes and nothing more to tizen git - but that has never
happend and i doubt it ever will. the situation literally is that
tizen efl is such a large fork, for tizen3 we have to throw it all
out and start again from scratch (from upstream). that is exactly
what is happening.

if we are lucky people will find/cherry-pick some patches from
tizen efl into upstream, but many will not as they have already
been rejected for various reasons. it will happen AGAIN and AGAIN
unless this way of development changes. as i see no way we can
sensibly say sorry app devs - you wait 1/2/3 months until a sync
from an upstream release to get that feature, then it is a
NECESSITY to track master. ESPECIALLY during such a brute-force
reset and start again period that will effectively break
many/most apps depending on efl due to them depending on a fork in
tizen.

policy simply fails given the development methods employed here in
this situation.

this is after 5+ years of experience on this and i see no sensible
way other than to track master for the purpose of tracking
features, and track upstream stable for the purpose of putting out
stable images/packages. both need to be tracked. it's the only
thing that will work.


Who would be the users of upstream master? With the current infra, 
it'd require a separate OBS project and repo AFAICT.


Both Tizen:Mobile and Tizen:IVI should use the same EFL stable branch 
version.


see above. they can't because everything will be broken for a long while 
to come until it's fixed and FIXES have to be worked at upstream due to 
the fact that tizen has decided to fork in a non-mergable way (what is a 
released tizen efl release is incompatible with an upstream one).


and the other reason - the developers being the ones who work on tizen 
apps - eg in samsung. i explained how things work above. policy just 
doesn't work. oh sure. we can just fork an interal inside samsung only 
efl git repo again like early on in tizen 1 days and just code dump it 
all without warning. would that make you happier since it'd not violate 
policy. :)


aaah history repeats. how wonderful. :)

--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection