Hey, Exciting stuff! Just unboxing my rift - will be happy to help test where I can :-D
Andy On Tue, 5 Jan 2016 at 21:45, David Seikel <[email protected]> wrote: > On Tue, 5 Jan 2016 11:47:09 -0800 Cedric BAIL <[email protected]> > 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 what I could find there to run on the DK2 I have, and found > stuff that worked fine under Windows at least. Google Cardboard is > obviously an Android thing, but there's software that uses that protocol > at the end of a network link, driven from Windows. > > > Also the situation is more complex that I think it would be. There is > > actually 2 differents content that are streamed to an HMD. 360 view > > (either spherical or cylinder mapped) and stereoscopic view. Of > > course, some HMD support one or the other or both, enjoy ! > > It's way worse than that. VR movies are all over the place as far as > formats are concerned. Each of those DRM_MODE_FLAGS DH mentioned > before, plus a few more, have been used to make movies. Movie players > have a dozen or more complex controls to try to sort out what to do for > any particular movie. Some movies bypass the entire problem and come > embedded inside their own viewer, or rather three of them to support > the major HMDs. > > > But that's only the beginning of the trouble, each HMD has different > > lense which means they need different transformation (and I have not > > gotten the confirmation that you could write one filter that cover > > every HMD). > > I doubt if you could get a generic filter. One of the big issues is > support for people that have to wear glasses, I'm one of those. > There's various options for dealing with that used by various > manufacturers. This includes providing standard frames for > optometrists to fit prescription lenses into. Each individuals lenses > can be custom! > > The Oculus Rift DK1 came with three different pairs of lenses to help > the glasses wearers, the DK2 cut that down to two. Some allow similar > dioptric adjustment as is in top end camera viewfinders. I think the > CV1 just goes with "give 'em a bit more room for their specs", and > maybe a standardised frame? Hopefully I'll have mine shortly after my > birthday, and then go visit my eye doctor. > > > Now, my understanding is that there is also no common API on Windows > > or Mac at this stage, but each HMD provide their own SDK. Of course on > > Linux situation is even worse as there is not even a SDK. > > There are the older Oculus SDKs for Linux that still work fine with the > released developer kits. I think the Linux and Mac support where > "paused" at about the same time. > > > I am not to sure of the course of action that should be taken as > > making Occulus Rift or Gear VR work on Linux is going to be a massive > > under taking. I am thinking that the most easy target for development > > would be Mac as we are close to have 100% EFL working there already > > and you would add a new backend there for each HMD (at least at this > > stage). > > Well, I have separate Linux, Mac, and Windows development workstations > now, though I have to upgrade the Linux one to suit HMD development. > Linux is my preferred development environment, I have the other two coz > in the virtual world area, users want their Mac and Windows support. > Oddly enough, Second Life supports Solaris as well, I think their > developers started off using Solaris workstations, so the viewer had to > work there to. > > > > In the end though, I expect the existing generic HMD libraries deal > > > with that for us, if they don't, I can send patches. That's where > > > HMD device detection and configuration should live. > > > > Does that already exist ? If it does, that should definitively be the > > layer we work on top of. > > Yes. I mentioned two open source cross platform library efforts in my > initial post (OpenHMD and libvr), and a port of the Oculus SDK to open > source C (libovr_nsb). I have since found one more open source generic > HMD library - (OpenVR, have yet to find a web site). There maybe more. > I've read through some of the reverse engineering process that has been > used by the first two libraries, so I'm up to speed with their problems > and progress. These libraries generally support Linux, Mac, and > Windows, as well as trying to target the major HMDs. > > On the controller front, there has long been an open source effort to > generically support all sorts of oddball input devices that would be > useful in HMD / VR work. I can't recall the name off the top of my > head, but I've got notes on it somewhere. I plan on trying it out in > my SledjHamr project eventually. > > So a lot of the massive work we can skip, others have done a lot of it > already, and are working on the rest. Best leave it to them, but I > hope there's some consolidation of effort there sooner rather than > later. We might have to try to predict the winner, and hope we don't > get that wrong. > > Reminds me, one more thing I should have mentioned about controllers. > A lot of the Oculus Rift software these days is written with the XBox > One controller in mind, as that's what will come with the initial > release of the CV1. I don't have one of those, but I do have a Sony > sixaxis controller that I got with my PS3. After finding drivers for > it under Windows, it worked fine for Rift use on that software, they > all think I'm using an XBox gamepad. I also use it for Android games, > and I recall it worked under Linux as well. This sort of compatibility > issue has been around for a while, they get solved. B-) > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
