new xwayland protocol

[Nick Kisialiou]

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.
http://www.youtube.com/watch?feature=player_embedded&v=Ec0JgisJqGA

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:
http://www.youtube.com/watch?feature=player_embedded&v=nglk96pxaLQ

In addition to that, lenses in a VR headset introduce the fish-eye
(spherical) distortion:
http://en.wikipedia.org/wiki/Distortion_%28optics%29

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


On Fri, Sep 14, 2012 at 12:01 PM, Bill Spitzak <spitzak at gmail.com> wrote:

> Pekka Paalanen wrote:
>
>  What is going to happen is Wayland clients are going to use the X api
>>> just to get this information.
>>>
>>
>> No, that is impossible.
>>
>
> 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.
>
>
>  I can tell you right now that our own software is not going to be usable
>>> unless we can save window layouts,
>>>
>>
>> Saving layouts will be solved differently than in X.
>>
>>  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.
>>>
>>
>> I don't understand what you mean by portability here. You cannot run an
>> X app in Windows without an X server, either.
>>
>
> 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.
>
>
>  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.
>>
>
> 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.
>
> ______________________________**_________________
> wayland-devel mailing list
> wayland-devel at lists.**freedesktop.org<wayland-devel at lists.freedesktop.org>
> http://lists.freedesktop.org/**mailman/listinfo/wayland-devel<http://lists.freedesktop.org/mailman/listinfo/wayland-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20120914/20376557/attachment.html>