Re: [E-devel] EFL and friends 1.17.0 beta 1

2016-01-17 Thread The Rasterman 
On Mon, 18 Jan 2016 12:36:12 +1000 David Seikel  said:

> In response to my novel below ... I fixed it, turns out it was my own
> silly fault this time.  I wasn't processing the return values from the
> script function calls that cross the network properly.

aha! pebkac :)

but seriously - we dont want to break efl. we try not to. but we need people
to call us out on a break EARLY. preferably during development (follow git
master)  or at least when stefan puts out alphas and betas. i know if i notice
something break behavior-wise or stability wise AS we develop - i look into it.

so tell us what is wrong preferably as soon as possible after when it goes
wrong. :)

> On Wed, 13 Jan 2016 20:47:56 +1000 David Seikel 
> wrote:
> 
> > On Wed, 13 Jan 2016 10:28:25 +0100 Stefan Schmidt
> >  wrote:
> > 
> > > Hello.
> > > 
> > > On 13/01/16 10:17, David Seikel wrote:
> > > > Wow, this is the first time in about a year that an EFL release
> > > > has NOT broken my highly experimental, based on beta API,
> > > > SledjHamr virtual world project.  Congratulations guys and gals.
> > > > B-)
> > > 
> > > That is good to hear!
> > > 
> > > >
> > > > On the other hand, I'm still trying to fix up all the breakage
> > > > from previous releases.  lol
> > > >
> > > This one not :(
> > > 
> > > Besides all these b0rkers jokes we are trying not to break things.
> > > From alpha1 onwards I really try to make sure we uncover the
> > > problems we might have to avoid regressions in the release. From my
> > > point of view it looks like the kind of regressions we have are
> > > mostly around behaviour changes. Actual API breaks seem to be under
> > > control.
> > > 
> > > Does this correlate with what you are seeing?
> > 
> > Keep in mind that my SledjHamr project is expected to take years to
> > complete, and has been under development (on and off, mostly off)
> > already for years.  It's due to this expectation that I'm using the
> > beta stuff in the first place.  I expect the beta APIs I've been using
> > will be well and truly stable before I can get a release out.
> > 
> > In the early days, yes API breaks where common.  These where easy to
> > fix though, look it up in the docs, or look at changes to examples,
> > just make the compiler happy.
> > 
> > These days it is more behaviour changes that's the problem.  These can
> > be tricky to sort out.  For example, one I "fixed" from the previous
> > release (or perhaps the one before that) is that the Elementary
> > toolbar on my main window would not display, even though the toolbars
> > on the child windows displayed fine.  Both use the same code.  So I
> > wrapped it in it's own child window for now, that's just big enough
> > to show the toolbar.  Just a work around for now.  While Elementary
> > might be stable, I'm using it via Eo, so the problem might be in Eo.
> > 
> > Another recent bug fix was that the 3D models where not turning up.  I
> > can't recall off the top of my head how I fixed that.  Evas_3D isn't
> > stable, so I expect problems every now and then.  Also in Evas_3D, I
> > was using the example cube and sphere code originally.  Some time last
> > year the ability to click on that cube or sphere stopped working,
> > around about the time primitives where added to Evas_3D.  I fixed this
> > by switching to primitives, and clicks work fine now.
> > 
> > There have been many other issues like those.
> > 
> > The one remaining problem, though it's entirely possible it's masking
> > more, is to do with very complex communication between the client,
> > world server, and script server.  I think, proving to be tricky to
> > track down.  Some of the stuff is working, but I should be getting a
> > dialogue popping up as the result of interacting with a script, and
> > that isn't working now.  I know the dialogue itself works, popping it
> > up other ways is fine.
> > 
> > 
> > 
> > The following novel describes how complex this is.  Skip it if you
> > like.  lol
> > 
> > I start the client, it tries to connect to a world server (local only
> > for testing), if it can't find one, it starts one, then tries again.
> > The world server does the same thing for the script server, try to
> > connect, on failure, start one.
> > 
> > Once it's all up and running, the world server tells the script server
> > to start compiling all the scripts it finds in the world.  These are
> > ordinary LSL scripts (Linden Scripting Language), as invented for
> > Second Life (SL) by Linden Labs.  Commonly used open source scripts
> > are what I'm testing with.  I'm trying to maintain backwards
> > compatibility with both that and the OpenSim (OS) variation of LSL.
> > It's common to have thousands of these scripts in one 256 x 256 meter
> > region, or even dozens on an avatar.
> > 
> > LSL is a  insert REALLY STRONG SWEAR WORDS here ... of a language,
> > trying to do stuff often involves multiple scripts communicating with

Re: [E-devel] EFL and friends 1.17.0 beta 1

2016-01-17 Thread David Seikel 
On Mon, 18 Jan 2016 13:18:14 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Mon, 18 Jan 2016 12:36:12 +1000 David Seikel 
> said:
> 
> > In response to my novel below ... I fixed it, turns out it was my
> > own silly fault this time.  I wasn't processing the return values
> > from the script function calls that cross the network properly.
> 
> aha! pebkac :)
> 
> but seriously - we dont want to break efl. we try not to. but we need
> people to call us out on a break EARLY. preferably during development
> (follow git master)  or at least when stefan puts out alphas and
> betas. i know if i notice something break behavior-wise or stability
> wise AS we develop - i look into it.

These days I usually try to compile from git after alpha, beta, and
final releases.  If I'm not otherwise busy, I'll then try to test my
SledjHamr project.  I'd been very busy last year.  Hopefully not so
busy this year, and next year I'll try to officially semi-retire.

> so tell us what is wrong preferably as soon as possible after when it
> goes wrong. :)

Nah, I prefer to see if it's pebkac first.  B-)

At least my network code got a decent refactor out of this.  SledjHamr
is all highly experimental code, so I often just throw together shit,
play with it until I figure out what works, than rewrite it properly.
After several years, I expect some small part of it might get to the
point where it's no longer experimental, then I can move that small
part to the so far empty master branch.

Now I think I'll throw together a shit script engine tester, play
around with it to see what works, but leave the rewrite until later.  I
have a few ideas of things I can test that I might break again in
future.  lol

> > On Wed, 13 Jan 2016 20:47:56 +1000 David Seikel 
> > wrote:
> > 
> > > On Wed, 13 Jan 2016 10:28:25 +0100 Stefan Schmidt
> > >  wrote:
> > > 
> > > > Hello.
> > > > 
> > > > On 13/01/16 10:17, David Seikel wrote:
> > > > > Wow, this is the first time in about a year that an EFL
> > > > > release has NOT broken my highly experimental, based on beta
> > > > > API, SledjHamr virtual world project.  Congratulations guys
> > > > > and gals. B-)
> > > > 
> > > > That is good to hear!
> > > > 
> > > > >
> > > > > On the other hand, I'm still trying to fix up all the breakage
> > > > > from previous releases.  lol
> > > > >
> > > > This one not :(
> > > > 
> > > > Besides all these b0rkers jokes we are trying not to break
> > > > things. From alpha1 onwards I really try to make sure we
> > > > uncover the problems we might have to avoid regressions in the
> > > > release. From my point of view it looks like the kind of
> > > > regressions we have are mostly around behaviour changes. Actual
> > > > API breaks seem to be under control.
> > > > 
> > > > Does this correlate with what you are seeing?
> > > 
> > > Keep in mind that my SledjHamr project is expected to take years
> > > to complete, and has been under development (on and off, mostly
> > > off) already for years.  It's due to this expectation that I'm
> > > using the beta stuff in the first place.  I expect the beta APIs
> > > I've been using will be well and truly stable before I can get a
> > > release out.
> > > 
> > > In the early days, yes API breaks where common.  These where easy
> > > to fix though, look it up in the docs, or look at changes to
> > > examples, just make the compiler happy.
> > > 
> > > These days it is more behaviour changes that's the problem.
> > > These can be tricky to sort out.  For example, one I "fixed" from
> > > the previous release (or perhaps the one before that) is that the
> > > Elementary toolbar on my main window would not display, even
> > > though the toolbars on the child windows displayed fine.  Both
> > > use the same code.  So I wrapped it in it's own child window for
> > > now, that's just big enough to show the toolbar.  Just a work
> > > around for now.  While Elementary might be stable, I'm using it
> > > via Eo, so the problem might be in Eo.
> > > 
> > > Another recent bug fix was that the 3D models where not turning
> > > up.  I can't recall off the top of my head how I fixed that.
> > > Evas_3D isn't stable, so I expect problems every now and then.
> > > Also in Evas_3D, I was using the example cube and sphere code
> > > originally.  Some time last year the ability to click on that
> > > cube or sphere stopped working, around about the time primitives
> > > where added to Evas_3D.  I fixed this by switching to primitives,
> > > and clicks work fine now.
> > > 
> > > There have been many other issues like those.
> > > 
> > > The one remaining problem, though it's entirely possible it's
> > > masking more, is to do with very complex communication between
> > > the client, world server, and script server.  I think, proving to
> > > be tricky to track down.  Some of the stuff is working, but I
> > > should be getting a dialogue popping up as

Re: [E-devel] Probie proposal: conr2d (Jee-Yong Um)

2016-01-17 Thread Daniel Juyung Seo 
Congratulations Conrad!

Daniel Juyung Seo (SeoZ)


On Tue, Jan 12, 2016 at 11:10 AM, Conrad Um  wrote:
> Thank you all. :D
>
> Best Regards,
> conr2d (Jee-Yong Um)
> On Jan 11, 2016 2:19 PM, "Jean-Philippe André"  wrote:
>
>> Welcome to the club, conr2d!
>>
>> You can now create your own developer branches to work on new features,
>> large bug fixes, or anything you need to share.
>> This might help you be more efficient than simply using Phab.
>> I believe you can also create your own repos, if you start a project from
>> scratch.
>>
>> I hope this access will help you contribute more to EFL! :)
>>
>> Congrats and enjoy,
>> jpeg
>>
>>
>> On 8 January 2016 at 21:42, Amitesh Singh  wrote:
>>
>>> +1
>>> On Jan 7, 2016 10:20 PM, "Mike Blumenkrantz" <
>>> michael.blumenkra...@gmail.com>
>>> wrote:
>>>
>>> > Thanks for this. +1 from me as well.
>>> >
>>> > On Wed, Jan 6, 2016 at 9:52 PM Jean-Philippe André 
>>> > wrote:
>>> >
>>> > > On 7 January 2016 at 03:53, Mike Blumenkrantz <
>>> > > michael.blumenkra...@gmail.com> wrote:
>>> > >
>>> > > > Not an objection, but for future cases can some example patches be
>>> > > provided
>>> > > > in the initial mail? Saying "quality patches" is great, but
>>> providing
>>> > 1-2
>>> > > > explicit/noteworthy examples would allow people who aren't as
>>> familiar
>>> > > with
>>> > > > the person's work (ie. don't work at Samsung) to form an opinion
>>> more
>>> > > > easily.
>>> > > >
>>> > >
>>> > >
>>> > > I thought of doing that, but then... I guess I was too lazy :)
>>> > >
>>> > > And in particular patches such as:
>>> > > https://phab.enlightenment.org/D3435
>>> > > https://phab.enlightenment.org/D3329
>>> > >
>>> > > And some ongoing work:
>>> > > https://phab.enlightenment.org/D3458
>>> > >
>>> > > See https://phab.enlightenment.org/p/conr2d/
>>> > >
>>> > > :)
>>> > >
>>> > >
>>> > > >
>>> > > > On Wed, Jan 6, 2016 at 10:22 AM Hermet Park 
>>> wrote:
>>> > > >
>>> > > > >  +1
>>> > > > >
>>> > > > > Regards, Hermet
>>> > > > >
>>> > > > > -Original Message-
>>> > > > > From: "Kim Shinwoo"kimcinoo@gmail.com
>>> > > > > To: "Enlightenment developer list"&
>>> > > > > lt;enlightenment-devel@lists.sourceforge.net;
>>> > > > > Cc:
>>> > > > > Sent: 2016-01-06 (수) 21:24:59
>>> > > > > Subject: Re: [E-devel] Probie proposal: conr2d (Jee-Yong Um)
>>> > > > >
>>> > > > > +1 :]
>>> > > > > 2016. 1. 6. 오후 7:20에 "Carsten Haitzler" ras...@rasterman.com
>>> > 님이
>>> > > > 작성:
>>> > > > >
>>> > > > >  On Wed, 6 Jan 2016 15:04:37 +0900 Jean-Philippe André &
>>> > > > > lt;j...@videolan.org
>>> > > > >  said:
>>> > > > > 
>>> > > > >   Hello,
>>> > > > >  
>>> > > > >  
>>> > > > >   I would like to propose a new candidate for probie
>>> access:
>>> > > > > Jee-Yong Um.
>>> > > > >  
>>> > > > >   Also known as conr2d, Jee-Yong has recently been
>>> sending a
>>> > > > > series of
>>> > > > >   quality patches for EFL and Elementary, updating them
>>> > quickly
>>> > > > in
>>> > > > > response
>>> > > > >   to review comments on Phab.
>>> > > > >  
>>> > > > >   He may be quite new to EFL and upstream in particular,
>>> he
>>> > > > > tackles non
>>> > > > >   trivial issues in Edje, preparing the ground for a
>>> higher
>>> > > > > quality API in
>>> > > > >   Elementary, including the theme API (size_class,
>>> > color_class,
>>> > > > > etc...).
>>> > > > >  
>>> > > > >  
>>> > > > >   He still has a couple of patches pending on Phab, and I
>>> > > believe
>>> > > > > a probie
>>> > > > >   access would help him work more efficiently.
>>> > > > >  
>>> > > > >  
>>> > > > >   Any objections?
>>> > > > > 
>>> > > > >  +1
>>> > > > > 
>>> > > > >  
>>> > > > >   Best regards,
>>> > > > >  
>>> > > > >   --
>>> > > > >   Jean-Philippe André
>>> > > > >  
>>> > > > > 
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> --
>>> > > > >   ___
>>> > > > >   enlightenment-devel mailing list
>>> > > > >   enlightenment-devel@lists.sourceforge.net
>>> > > > >  
>>> > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>> > > > >  <
>>> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>> > > > >;
>>> > > > > 
>>> > > > >  --
>>> > > > >  - Codito, ergo sum - "I code, therefore I am"
>>> > > > > --
>>> > > > >  The Rasterman (Carsten Haitzler)ras...@rasterman.com
>>> > > > > 
>>> > > > > 
>>> > > > > 
>>> > > > > 
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> --
>>> > > > >  ___
>>> > > > >  enlightenment-devel mailing list
>>> > > > >  enlightenment-devel@lists.sourceforge.net
>>> > > > > 
>>> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>> > > > >  <
>>> > >

Re: [E-devel] Adding support for head mounted displays.

2016-01-17 Thread Andrew Williams 
Yeah, just about every combination on win10 breaks. Setting up 8.1 to
tinker next weekend - wish me luck!

Andy

On Tue, 12 Jan 2016 at 00:10, David Seikel  wrote:

> Yeah, the DK2 is a pain to get working.  Good luck on the weekend.
>
> Dunno about Windows 10, I was using 7 and 8.1.  I'd suggest backing up
> to an older SDK at first (0.6 is the sweet spot for me and my client),
> but I think Win 10 might get in the way of that.
>
> I think I might get a Google Cardboard device after I hand back the DK2
> to the client.  Could tide me over until the CV1 arrives.  There's
> actually a company in the next town that has their own Cardboard
> version, but they have been out of stock since last year.  B-(
>
> On Mon, 11 Jan 2016 23:41:50 + Andrew Williams
>  wrote:
>
> > I honestly can't get it working :( flicks on for a few seconds then
> > off again... Tried 2 different machines - only commonality I can find
> > is win10 or the device itself... I'll try again at the weekend!
> >
> > Andy
> > On Mon, 11 Jan 2016 at 05:15, David Seikel  wrote:
> >
> > > How's your Rift going Andy?
> > >
> > > Around about now is when I'm expecting my client to ask me to return
> > > the DK2 I have, haven't heard from them yet.  Best guess for
> > > delivery of my CV1 is mid April, you might be on your own for a
> > > while.
> > >
> > > On Wed, 06 Jan 2016 08:45:00 + Andrew Williams
> > >  wrote:
> > >
> > > > Yup that's right. Actually I've yet to find out if it works on my
> > > > Mac Pro...
> > > >
> > > > Andy
> > > > On Wed, 6 Jan 2016 at 01:48, David Seikel 
> > > > wrote:
> > > >
> > > > > On Tue, 05 Jan 2016 23:56:21 + Andrew Williams
> > > > >  wrote:
> > > > >
> > > > > > Exciting stuff! Just unboxing my rift - will be happy to help
> > > > > > test where I can :-D
> > > > >
> > > > > Cool. I'm guessing you got a second hand Dk2?  The pre orders
> > > > > for the CV1 only open up in 14 hours.
> > > > >
> > > > > > Andy
> > > > > > On Tue, 5 Jan 2016 at 21:45, David Seikel 
> > > > > > wrote:
> > > > > >
> > > > > > > On Tue, 5 Jan 2016 11:47:09 -0800 Cedric BAIL
> > > > > > >  wrote:
> > > > > > > > >> >> So basically, get the mode info and check the
> > > > > > > > >> >> "flags" of the mode struct for supported layouts.
> > > > > > > > >> >> Possible values on "flags":
> > > > > > > > >> >>
> > > > > > > > >> >> #define DRM_MODE_FLAG_3D_MASK
> > > > > > > > >> >> (0x1f<<14) #define
> > > > > > > > >> >> DRM_MODE_FLAG_3D_NONE (0<<14)
> > > > > > > > >> >> #define DRM_MODE_FLAG_3D_FRAME_PACKING
> > > > > > > > >> >> (1<<14) #define
> > > > > > > > >> >> DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE(2<<14)
> > > > > > > > >> >> #define DRM_MODE_FLAG_3D_LINE_ALTERNATIVE (3<<14)
> > > > > > > > >> >> #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL
> > > > > > > > >> >> (4<<14) #define DRM_MODE_FLAG_3D_L_DEPTH
> > > > > > > > >> >> (5<<14) #define
> > > > > > > > >> >> DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH(6<<14)
> > > > > > > > >> >> #define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM   (7<<14)
> > > > > > > > >> >> #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
> > > > > > > > >> >> (8<<14)
> > > > > > > > >> >>
> > > > > > > > >> >> This would/should actually be quite simple to
> > > > > > > > >> >> detect in the ecore_drm code as we already fetch
> > > > > > > > >> >> mode info for crtcs. Would just be a matter of
> > > > > > > > >> >> checking for these flags.
> > > > > > > > >> >
> > > > > > > > >> > Not quite so correct.  Sure this probably works fine
> > > > > > > > >> > under DRM / Wayland, but I mentioned Mac OS X and
> > > > > > > > >> > Windows as well as Linux.
> > > > > > > > >>
> > > > > > > > >> Sure. I defer to your wisdom in those areas ;) I was
> > > > > > > > >> mearly stating that (as far as code goes), it would be
> > > > > > > > >> fairly simple (wrt libdrm) to add these pieces to
> > > > > > > > >> ecore_drm.
> > > > > > > > >
> > > > > > > > > Yep, looks simple enough.  Still wont be useful for Mac
> > > > > > > > > and Windows support, but at least that's Linux catered
> > > > > > > > > for in the "detect a HMD that wants to be a monitor"
> > > > > > > > > stakes.  As I pointed out, not all HMDs present
> > > > > > > > > themselves as monitors.
> > > > > > > >
> > > > > > > > Or Android. Also... it is not that useful on Linux as
> > > > > > > > there is no support for HMD at the moment and Occulus
> > > > > > > > Rift doesn't seems to interested by that.
> > > > > > >
> > > > > > > Oculus did initially support Linux and Mac, but "paused"
> > > > > > > support for them.  Older SDKs still work.  Also, see the
> > > > > > > bottom of this email. HTC Vive is a Steam thing, and Steam
> > > > > > > tries to be cross platform more or less, but I've not
> > > > > > > checked that out yet.  I did create a Steam account to see
> > > >

Re: [E-devel] Eina value optional

2016-01-17 Thread Felipe Magno de Almeida 
Hello,

Sorry to answer myself, but complementing on what I've said before.
There's also ABI and optimization's concern on adding empty value for
all types. Since Eina_Value is defined in eina_value.h header, it is
public and needs to be backwards compatible ABI-wise, and since it can
be used by value with eina_value_setup we can't just add a field in
struct _Eina_Value. And, since Eina_Value_Union is the size of 8 bytes
in most architectures, it means we'd need an unnecessary indirection
for all except char, short and ints if we added an empty state.

Regards,

On Sun, Jan 17, 2016 at 10:51 PM, Felipe Magno de Almeida
 wrote:
> On Wed, Jan 13, 2016 at 12:38 AM, Jean-Philippe André  
> wrote:
>> Hi Felipe,
>>
>> You added the optional type to eina value. I'm not sure what it's point is.
>> I understand an optional value can be empty (ie. void and not "nil" or 0 or
>> whatever).
>>
>> But I don't understand why this couldn't be implemented inside all standard
>> values. Add an "empty" property to them.
>>
>> Could you explain shortly why we need a special type? I'm sure you had a
>> good reason :)
>
> Hello jpeg,
>
> When implementing a data model for esskyuehl we needed a way to handle
> NULL values from database for certain columns. The "empty" value is
> a specific, valid, value for that type.
>
> If we added "empty" property to all values in Eina Value, we'd be adding
> an ambigous information for each use. Is that an invalid value? An
> indication of an error? Is that a valid value? Equivalent to a NULL
> Eina_Value?
>
> The optional doesn't have this problem, it is the equivalent of
> a "T + 1" in algebraic data type, with 1 meaning "empty", which
> would be used when an empty value is possible and is a valid
> value.
>
> That way we don't need to check for emptiness for all current
> uses of integer Eina Values or some other type, for example.
> Their semantics are completely intact..
>
>> Thanks in advance,
>
> Sorry for the delay of this answer,
>
>
>> --
>> Jean-Philippe André
>
> Regards,
> --
> Felipe Magno de Almeida



-- 
Felipe Magno de Almeida

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eina value optional

2016-01-17 Thread Felipe Magno de Almeida 
On Wed, Jan 13, 2016 at 12:38 AM, Jean-Philippe André  wrote:
> Hi Felipe,
>
> You added the optional type to eina value. I'm not sure what it's point is.
> I understand an optional value can be empty (ie. void and not "nil" or 0 or
> whatever).
>
> But I don't understand why this couldn't be implemented inside all standard
> values. Add an "empty" property to them.
>
> Could you explain shortly why we need a special type? I'm sure you had a
> good reason :)

Hello jpeg,

When implementing a data model for esskyuehl we needed a way to handle
NULL values from database for certain columns. The "empty" value is
a specific, valid, value for that type.

If we added "empty" property to all values in Eina Value, we'd be adding
an ambigous information for each use. Is that an invalid value? An
indication of an error? Is that a valid value? Equivalent to a NULL
Eina_Value?

The optional doesn't have this problem, it is the equivalent of
a "T + 1" in algebraic data type, with 1 meaning "empty", which
would be used when an empty value is possible and is a valid
value.

That way we don't need to check for emptiness for all current
uses of integer Eina Values or some other type, for example.
Their semantics are completely intact..

> Thanks in advance,

Sorry for the delay of this answer,


> --
> Jean-Philippe André

Regards,
-- 
Felipe Magno de Almeida

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Adding support for head mounted displays.

2016-01-17 Thread David Seikel 
On Sun, 17 Jan 2016 22:07:10 + Andrew Williams
 wrote:

> Yeah, just about every combination on win10 breaks. Setting up 8.1 to
> tinker next weekend - wish me luck!

Good luck!

> 
> Andy
> 
> On Tue, 12 Jan 2016 at 00:10, David Seikel  wrote:
> 
> > Yeah, the DK2 is a pain to get working.  Good luck on the weekend.
> >
> > Dunno about Windows 10, I was using 7 and 8.1.  I'd suggest backing
> > up to an older SDK at first (0.6 is the sweet spot for me and my
> > client), but I think Win 10 might get in the way of that.
> >
> > I think I might get a Google Cardboard device after I hand back the
> > DK2 to the client.  Could tide me over until the CV1 arrives.
> > There's actually a company in the next town that has their own
> > Cardboard version, but they have been out of stock since last
> > year.  B-(
> >
> > On Mon, 11 Jan 2016 23:41:50 + Andrew Williams
> >  wrote:
> >
> > > I honestly can't get it working :( flicks on for a few seconds
> > > then off again... Tried 2 different machines - only commonality I
> > > can find is win10 or the device itself... I'll try again at the
> > > weekend!
> > >
> > > Andy
> > > On Mon, 11 Jan 2016 at 05:15, David Seikel 
> > > wrote:
> > >
> > > > How's your Rift going Andy?
> > > >
> > > > Around about now is when I'm expecting my client to ask me to
> > > > return the DK2 I have, haven't heard from them yet.  Best guess
> > > > for delivery of my CV1 is mid April, you might be on your own
> > > > for a while.
> > > >
> > > > On Wed, 06 Jan 2016 08:45:00 + Andrew Williams
> > > >  wrote:
> > > >
> > > > > Yup that's right. Actually I've yet to find out if it works
> > > > > on my Mac Pro...
> > > > >
> > > > > Andy
> > > > > On Wed, 6 Jan 2016 at 01:48, David Seikel 
> > > > > wrote:
> > > > >
> > > > > > On Tue, 05 Jan 2016 23:56:21 + Andrew Williams
> > > > > >  wrote:
> > > > > >
> > > > > > > Exciting stuff! Just unboxing my rift - will be happy to
> > > > > > > help test where I can :-D
> > > > > >
> > > > > > Cool. I'm guessing you got a second hand Dk2?  The pre
> > > > > > orders for the CV1 only open up in 14 hours.
> > > > > >
> > > > > > > Andy
> > > > > > > On Tue, 5 Jan 2016 at 21:45, David Seikel
> > > > > > >  wrote:
> > > > > > >
> > > > > > > > On Tue, 5 Jan 2016 11:47:09 -0800 Cedric BAIL
> > > > > > > >  wrote:
> > > > > > > > > >> >> So basically, get the mode info and check the
> > > > > > > > > >> >> "flags" of the mode struct for supported
> > > > > > > > > >> >> layouts. Possible values on "flags":
> > > > > > > > > >> >>
> > > > > > > > > >> >> #define DRM_MODE_FLAG_3D_MASK
> > > > > > > > > >> >> (0x1f<<14) #define
> > > > > > > > > >> >> DRM_MODE_FLAG_3D_NONE
> > > > > > > > > >> >> (0<<14) #define DRM_MODE_FLAG_3D_FRAME_PACKING
> > > > > > > > > >> >> (1<<14) #define
> > > > > > > > > >> >> DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE
> > > > > > > > > >> >> (2<<14) #define
> > > > > > > > > >> >> DRM_MODE_FLAG_3D_LINE_ALTERNATIVE (3<<14)
> > > > > > > > > >> >> #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL
> > > > > > > > > >> >> (4<<14) #define DRM_MODE_FLAG_3D_L_DEPTH
> > > > > > > > > >> >> (5<<14) #define
> > > > > > > > > >> >> DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH
> > > > > > > > > >> >> (6<<14) #define
> > > > > > > > > >> >> DRM_MODE_FLAG_3D_TOP_AND_BOTTOM   (7<<14)
> > > > > > > > > >> >> #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
> > > > > > > > > >> >> (8<<14)
> > > > > > > > > >> >>
> > > > > > > > > >> >> This would/should actually be quite simple to
> > > > > > > > > >> >> detect in the ecore_drm code as we already fetch
> > > > > > > > > >> >> mode info for crtcs. Would just be a matter of
> > > > > > > > > >> >> checking for these flags.
> > > > > > > > > >> >
> > > > > > > > > >> > Not quite so correct.  Sure this probably works
> > > > > > > > > >> > fine under DRM / Wayland, but I mentioned Mac OS
> > > > > > > > > >> > X and Windows as well as Linux.
> > > > > > > > > >>
> > > > > > > > > >> Sure. I defer to your wisdom in those areas ;) I
> > > > > > > > > >> was mearly stating that (as far as code goes), it
> > > > > > > > > >> would be fairly simple (wrt libdrm) to add these
> > > > > > > > > >> pieces to ecore_drm.
> > > > > > > > > >
> > > > > > > > > > Yep, looks simple enough.  Still wont be useful for
> > > > > > > > > > Mac and Windows support, but at least that's Linux
> > > > > > > > > > catered for in the "detect a HMD that wants to be a
> > > > > > > > > > monitor" stakes.  As I pointed out, not all HMDs
> > > > > > > > > > present themselves as monitors.
> > > > > > > > >
> > > > > > > > > Or Android. Also... it is not that useful on Linux as
> > > > > > > > > there is no support for HMD at the moment and Occulus
> > > > > > > > > Rift doesn't seems to interested by that.
> > > > > > > >
> > > > > > > > Oculus did

Re: [E-devel] EFL and friends 1.17.0 beta 1

2016-01-17 Thread David Seikel 
In response to my novel below ... I fixed it, turns out it was my own
silly fault this time.  I wasn't processing the return values from the
script function calls that cross the network properly.

On Wed, 13 Jan 2016 20:47:56 +1000 David Seikel 
wrote:

> On Wed, 13 Jan 2016 10:28:25 +0100 Stefan Schmidt
>  wrote:
> 
> > Hello.
> > 
> > On 13/01/16 10:17, David Seikel wrote:
> > > Wow, this is the first time in about a year that an EFL release
> > > has NOT broken my highly experimental, based on beta API,
> > > SledjHamr virtual world project.  Congratulations guys and gals.
> > > B-)
> > 
> > That is good to hear!
> > 
> > >
> > > On the other hand, I'm still trying to fix up all the breakage
> > > from previous releases.  lol
> > >
> > This one not :(
> > 
> > Besides all these b0rkers jokes we are trying not to break things.
> > From alpha1 onwards I really try to make sure we uncover the
> > problems we might have to avoid regressions in the release. From my
> > point of view it looks like the kind of regressions we have are
> > mostly around behaviour changes. Actual API breaks seem to be under
> > control.
> > 
> > Does this correlate with what you are seeing?
> 
> Keep in mind that my SledjHamr project is expected to take years to
> complete, and has been under development (on and off, mostly off)
> already for years.  It's due to this expectation that I'm using the
> beta stuff in the first place.  I expect the beta APIs I've been using
> will be well and truly stable before I can get a release out.
> 
> In the early days, yes API breaks where common.  These where easy to
> fix though, look it up in the docs, or look at changes to examples,
> just make the compiler happy.
> 
> These days it is more behaviour changes that's the problem.  These can
> be tricky to sort out.  For example, one I "fixed" from the previous
> release (or perhaps the one before that) is that the Elementary
> toolbar on my main window would not display, even though the toolbars
> on the child windows displayed fine.  Both use the same code.  So I
> wrapped it in it's own child window for now, that's just big enough
> to show the toolbar.  Just a work around for now.  While Elementary
> might be stable, I'm using it via Eo, so the problem might be in Eo.
> 
> Another recent bug fix was that the 3D models where not turning up.  I
> can't recall off the top of my head how I fixed that.  Evas_3D isn't
> stable, so I expect problems every now and then.  Also in Evas_3D, I
> was using the example cube and sphere code originally.  Some time last
> year the ability to click on that cube or sphere stopped working,
> around about the time primitives where added to Evas_3D.  I fixed this
> by switching to primitives, and clicks work fine now.
> 
> There have been many other issues like those.
> 
> The one remaining problem, though it's entirely possible it's masking
> more, is to do with very complex communication between the client,
> world server, and script server.  I think, proving to be tricky to
> track down.  Some of the stuff is working, but I should be getting a
> dialogue popping up as the result of interacting with a script, and
> that isn't working now.  I know the dialogue itself works, popping it
> up other ways is fine.
> 
> 
> 
> The following novel describes how complex this is.  Skip it if you
> like.  lol
> 
> I start the client, it tries to connect to a world server (local only
> for testing), if it can't find one, it starts one, then tries again.
> The world server does the same thing for the script server, try to
> connect, on failure, start one.
> 
> Once it's all up and running, the world server tells the script server
> to start compiling all the scripts it finds in the world.  These are
> ordinary LSL scripts (Linden Scripting Language), as invented for
> Second Life (SL) by Linden Labs.  Commonly used open source scripts
> are what I'm testing with.  I'm trying to maintain backwards
> compatibility with both that and the OpenSim (OS) variation of LSL.
> It's common to have thousands of these scripts in one 256 x 256 meter
> region, or even dozens on an avatar.
> 
> LSL is a  insert REALLY STRONG SWEAR WORDS here ... of a language,
> trying to do stuff often involves multiple scripts communicating with
> each other.  The script server translates them into Lua, then uses
> LuaJIT to compile them.  The script server tells the world server when
> each script is done compiling, the world server then tells the script
> server to actually run them.  Which it does, using LuaJIT.  I wrote a
> worker thread system to run these scripts, as LSL is event driven.  So
> script response to events is expected to be short.  This is actually
> part of the spec of LSL.  Anyone trying an endless loop in LSL should
> expect their script to be terminated.
> 
> As an aside, I'm doing things this way coz I feel that LuaJIT, being
> the fastest scripting language, could do a far better

Re: [E-devel] [EGIT] [core/efl] master 01/01: configure: Fail if opengl=full is used with EGL

2016-01-17 Thread Jean-Philippe André 
On 16 January 2016 at 09:58, Simon Lees  wrote:

>
>
> On 01/11/2016 05:18 PM, Jean-Philippe ANDRÉ wrote:
> > jpeg pushed a commit to branch master.
> >
> >
> http://git.enlightenment.org/core/efl.git/commit/?id=1f7e8d4253cf5265cba5a8968fb43fa720dde934
> >
> > commit 1f7e8d4253cf5265cba5a8968fb43fa720dde934
> > Author: Jean-Philippe Andre 
> > Date:   Mon Jan 11 13:47:41 2016 +0900
> >
> >  configure: Fail if opengl=full is used with EGL
> >
> >  So many problems from people who customize their builds in this
> >  incompatible manner.
> >
> >  There really should be only one configure option as we don't
> >  support opengl+egl (although possible in theory) or gles without
> >  egl. Keeping both to not break existing builds.
> How does this effect distro packaging where some users presumably want
> opengl=full for X11 and then others EGL for wayland? or should that not
> be possible at the moment, id rather not use separate efl packages for
> wayland vs x11 that would just be messy.
>

Considering how the configure currently works, I believe this was not
possible.
Here I'm just trying to clarify the limitations of our build system.

If you want wayland, then you want EGL, which will mean you also want
GL-ES. Since this is a global option, this will also apply to X11 (so, EGL
instead of GLX).

I'm not saying that it would be impossible to support EGL with full opengl,
or GLX and Wayland. Just that it probably doesn't work right now.

JP


> Cheers
> Simon
> > ---
> >   configure.ac | 18 --
> >   1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/configure.ac b/configure.ac
> > index 35c166b..5e4865e 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -1636,7 +1636,7 @@ if test "${want_sdl}" = "yes"; then
> >  EFL_PKG_CHECK_STRICT([sdl2 >= 2.0.0])
> >   fi
> >
> > -# We only enable SDL with opengl if it is not the full version and not
> ES
> > +# We only enable SDL with opengl if it is the full version and not ES
> >   # This can be changed if we ported our SDL code over to SDL 2.0. For
> older
> >   # versions the SDL_opengles.h has never been released.
> >   want_gl_sdl="no"
> > @@ -1829,6 +1829,14 @@ AC_ARG_ENABLE([egl],
> >  ],
> >  [want_egl="no"])
> >
> > +# Verify OpenGL + EGL modes match (full+glx or es+egl)
> > +if test "x${want_egl}" = "xyes" && test "x${with_opengl}" != "xes" ;
> then
> > +  AC_MSG_ERROR([Full OpenGL with EGL is not supported, please add
> --with-opengl=es to your configure options to switch to EGL + OpenGL ES.])
> > +fi
> > +if test "x${want_egl}" = "xno" && test "x${with_opengl}" = "xes" ; then
> > +  AC_MSG_ERROR([OpenGL ES requires EGL, please add --enable-egl to your
> configure options to switch to EGL + OpenGL ES.])
> > +fi
> > +
> >   # Pixman
> >   AC_ARG_ENABLE([pixman],
> >  [AS_HELP_STRING([--enable-pixman],[enable pixman for software
> rendering. @<:@default=disabled@:>@])],
> > @@ -5247,6 +5255,12 @@ else
> >  osname="${host_os}"
> >   fi
> >
> > +if test "x${want_egl}" = "xyes" ; then
> > +   opengl_egl="(EGL)"
> > +else
> > +   opengl_egl=""
> > +fi
> > +
> >   echo "Configuration...: ${COLOR_OTHER}profile=${build_profile}
> os=${osname}${COLOR_RESET}"
> >   echo "  EFL API Set...: ${efl_api}"
> >   echo "  CPU Extensions: ${host_cpu} (${features_cpu})"
> > @@ -5254,7 +5268,7 @@ echo "  System Feature: ${features_system}"
> >   echo "  Threads...: ${efl_have_threads} (${features_thread})"
> >   echo "  Cryptography..: ${build_crypto}"
> >   echo "  X11...: ${with_x11}"
> > -echo "  OpenGL: ${with_opengl}"
> > +echo "  OpenGL: ${with_opengl} ${opengl_egl}"
> >   echo "  C++11.: ${have_cxx11}"
> >   echo "  JavaScript: ${want_js}"
> >   echo "  JavaScript flg: $EINA_JS_LIBS"
> >
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Jean-Philippe André
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
enlightenment-devel mailing list