new xwayland protocol
spitzak at gmail.com
Fri Sep 14 12:01:23 PDT 2012
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):
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
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.
More information about the wayland-devel