I would like to share with you a couple of demos of the 3D virtual reality desktop, courtesy of Hesham Wahba. I believe it will give you a better idea of what Pekka was talking about: Demo 1 shows the side-by-side view for left and right eyes. It also shows orientation control by a gyroscope in iPhone. Eventually, the orientation sensor will be done from the head tracker, so that your head movement would change the view in the virtual world. <a href="http://www.youtube.com/watch?feature=player_embedded&v=Ec0JgisJqGA">http://www.youtube.com/watch?feature=player_embedded&v=Ec0JgisJqGA</a> Demo 2 shows the stereo view of the same desktop. By default, YouTube converts it into the overlapping red/cyan view. If you turn it on/off with the 3D button on YouTube: <a href="http://www.youtube.com/watch?feature=player_embedded&v=nglk96pxaLQ">http://www.youtube.com/watch?feature=player_embedded&v=nglk96pxaLQ</a> In addition to that, lenses in a VR headset introduce the fish-eye (spherical) distortion: <a href="http://en.wikipedia.org/wiki/Distortion_%28optics%29">http://en.wikipedia.org/wiki/Distortion_%28optics%29</a> To overcome that you can use a classical VR headset that relied on a lot of heavy and expensive optics to compensate. Alternatively, you can get rid of all the other lenses and pre-distort the image in the pixel shader to get nice rectangular windows in the output. The client windows should not have any knowledge of it since they should work alright on flat monitors as well. I agree with the statement that VR desktops are a niche market yet. But so were smartphones and tablets 5 years ago, and laptops 15 years ago. So, the question to the Wayland developers is: + Are you designing Wayland to be something what X _should_have_been_ 5 or 10 years ago? or + Are you designing Wayland to support graphics technologies for the next 10 - 20 years? Nick <div class="gmail_quote">On Fri, Sep 14, 2012 at 12:01 PM, Bill Spitzak <<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Pekka Paalanen wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> What is going to happen is Wayland clients are going to use the X api just to get this information. </blockquote> No, that is impossible. </blockquote> </div> I do believe it will be impossible to use the Wayland API and be able to set window x/y positions by somehow messing with the X api. My worry is that clients will actually skip using Wayland and use X just because it gives them this ability.<div class="im"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I can tell you right now that our own software is not going to be usable unless we can save window layouts, </blockquote> Saving layouts will be solved differently than in X. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and we are interested in portability to Windows and OS/X where the way to place windows on various outputs is to use the coordinates, not an id for the output. </blockquote> I don't understand what you mean by portability here. You cannot run an X app in Windows without an X server, either. </blockquote> </div> Both Linux and windows support text files that say something like this (we wrote the code that reads/writes these files): window_position: 10,30,400,500 It is true that after this file is parsed different calls are used for X and Wayland and WIN32. But at the moment both X and WIN32 have calls that take two integers called the x and y position, making this portable. The lack of this on Wayland is a problem. The best I can do with Wayland right now is make up an x/y position based on the upper-left corner of the output the window is on (at least I believe this info is available). Another alternative is to write the output name to the file and do the translation on the Windows and Xlib backends, but I very much doubt that idea will be accepted.<div class="im"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Apparently you have forgot all about, say, dome projectors or virtual displays, where the output is a half sphere. Good luck mapping Cartesian global coordinates there in any meaningful way. </blockquote> </div> Seems like there are two coordinates of finite range, thus fitting into a rectangle that can be made to not overlap the rectangles for any other output. For instance you could use a square where .5,.5 is the north pole, and the four sides are tangent to the equator. You could also use cylindrical coordinates where there is a square and one edge is the equator, one edge is scaled to 0 length at the pole, and the two other edges touch. The only requirement for the transformation from window to screen is that a unique transformation is chosen for a given x/y position and window size. There is no need for it to be affine. If you had a display that was actually a 3D volume, so that there are more than 2 independent coordinates, then I could see a problem. I don't think we need to worry about that just yet, however.<div class="HOEnZb"><div class="h5"> _______________________________________________ wayland-devel mailing list <a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </div></div></blockquote></div>