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.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
