On 01/03/2016 03:51 PM, Cedric BAIL wrote:
> On Sun, Jan 3, 2016 at 9:09 PM, David Seikel <[email protected]> wrote:
>> I've recently come out of a contract where I was adding Oculus Rift
>> support to an existing application.  This is something I always wanted
>> to play with.  Having had that experience, now I want to add generic
>> HMD (Head Mounted Display, like the Rift) support to Evas_3D.  It will
>> be great for my major, years long, virtual worlds project.
>>
>> There's a few different HMDs being released soonish, many variations on
>> Google Cardboard have been out for a while, Samsung Gear VR was released
>> last month, Oculus Rift is likely to be released in the next month or
>> three, HTC Vive probably released later this year, and many more.
>>
>> http://www.hypergridbusiness.com/faq/best-virtual-reality-headsets/
>> lists dozens of them (mostly Cardboard variations).
>>
>> I was using an Oculus Rift DK2 (Developer Kit 2) supplied by the client
>> for this contract.  I have to hand that back in about a week, but I'll
>> be buying my own Oculus Rift when it gets released.  I'll probably get a
>> Google Cardboard style device as well.
>>
>> The contract used the Oculus SDK, but obviously that only handles
>> Oculus HMDs, and these days only on Windows.  Oculus used to support
>> Linux and Mac OS X, but they dropped that to concentrate on Windows
>> for the release.  Oculus claim the other OS support will return.
>> There's a couple of open source, cross platform, generic HMD libraries
>> that are trying to handle a bunch of HMDs, and that's what I'd rather be
>> using for EFL.  It's still early days for this tech, so no standards or
>> anything yet.
>>
>> http://hg.sitedethib.com/libvr
>>
>> http://openhmd.net/
>>
>> And a conversion of the Oculus SDK (horrid bit of C++ coding, not all
>> of it open surce) into open source C -
>>
>> https://github.com/ultranbrown/libovr_nsb
>>
>> What do people think of adding generic HMD support to Evas_3D?
>
> I am guessing that what you really need to add is support for
> stereoscopic output. This is definitively one of the reason why we
> have added Evas_3D. There is still some work to be done to reach the
> point where that would work out of the box. The step I see so far are
> :
> - Negotiate with the compositor over Wayland protocol if it can handle
> a 3d stereoscopic output
> - Add detection of 3d stereoscopic output to Enlightenment and
> ecore_drm backend (If I remember correctly Intel GPU support under
> Linux 3d output over HDMI somewhere in libdrm)

Correct.

/**
  * DRM_CLIENT_CAP_STEREO_3D
  *
  * if set to 1, the DRM core will expose the stereo 3D capabilities of the
  * monitor by advertising the supported 3D layouts in the flags of struct
  * drm_mode_modeinfo.
  */
#define DRM_CLIENT_CAP_STEREO_3D        1

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.

dh

> - Add viewport definition and support to render evas scenegraph with a
> slight change in the camera definition for both left and right eyes
>
> We could also take advantage of a Z property on normal Evas_Object to
> have some kind of floating UI in 3D. There are a also few tricks to
> handle, like the resolution changing between when you are turning on
> stereoscopic display from where you are not. Anyway, that would be my
> idea on what to do for this, sadly I don't think we have any plan to
> move that forward at this point, but I will be happy to help you
> figure out detail on this.
>
> Have fun,
>


------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to