Re: Bug 78372 - create multiple windows with offset
On Thu, 08 May 2014 13:13:34 -0700 Bill Spitzak spit...@gmail.com wrote: I posted the same patch for the xserver for 6 months to allow it to read a different xorg.conf file. I finally got sick of being ignored and gave up, also recent xwayland can now work on a non-EGL wayland without having a special xorg.conf file, thus fixing it for me. However the underlying bug still exists and I'm sure there will be text that has to be in one xorg.conf file or the other that makes the other server choke. Maybe then somebody will fix it. Maybe you completely missed it, but the X server part of xwayland was rewritten almost from scratch. It does not use Xorg anymore at all. No DDXes. I'm not sure if it even tries to read any config files anymore. Now, the same source code tree that produces the familar 'Xorg' program and lots of modules, can also produce a program called 'Xwayland'. That single binary is now probably the only thing you need from the xserver tree for xwayland to work. See the new xwayland build instructions. For hardware accelerated GLX clients you might have to wait a bit more, but I see that glxgears works just fine - it gets llvmpipe. I didn't try to enable Glamor at all. With the very little effort I used, I'm in a state, where I can run 'glxgears' inside Weston, and it just works. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Bug 78372 - create multiple windows with offset
On Thu, 08 May 2014 10:52:51 -0700 Bill Spitzak spit...@gmail.com wrote: On 05/07/2014 10:54 PM, Pekka Paalanen wrote: This is similar to session save/restore, lacking a better term for it. We do not even pretend to support or enable this yet. It is just yet one more feature that the shell protocol suite for desktop should cover, but so far no-one has done any work on it AFAIK. If there is not one already, you are welcome to open a feature request bug about application layout save/restore. But the only practical method I can see is to allow the client to query and set the output and x/y position of any surface directly. You have just been starting at X11 for too long. Possibly you are reading the words save/restore literally, in that you are imagining some blob of data stored in the compositor that is recognized to restore the layout. However this is NOT what is wanted. Sure, that's the first thing comes to my mind. Let the client save a cookie or an encrypted blob, that it can pass back to the server when it creates the windows again. /handwaving/ When I say that I have not heard anyone working on it, it really means I do not have nor seen any plan *yet*. It is a complicated issue, which cannot be designed in an email, and especially not by me. Clients must be able to generate a usable layout the first time they are run, they must be able to do something intelligent if the set of windows changes from that in the saved layout, and use a layout from one system on another (including cross-platform), and be able to choose layouts from a list and add the current layout as a new item on the list. No. With separate windows you simply cannot do that. The client has no clue whatsoever on e.g. what positions on an output might be ok, what else is on the screen, or which outputs would be ok to conquer. You also might be on a tiling compositor, where your expectations simply totally fail. Your program would have to be a mind-reader to get the initial layout right for any user. Instead, what an application could do, is describe the expectations it has for its initial window layout, if possible. That is again left up for the desktop shell protocol suite to develop. If you want to be in absolute control of the layout (you the app, not even the user), use a single big window with compartments or something, maybe per output. If you think that sucks, I would probably agree. But I still cannot see how you could guess which output to pick for what, but that's probably just me never using special purpose monitors. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Bug 78372 - create multiple windows with offset
Hi, On 9 May 2014 08:34, Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 08 May 2014 10:52:51 -0700 Bill Spitzak spit...@gmail.com wrote: Possibly you are reading the words save/restore literally, in that you are imagining some blob of data stored in the compositor that is recognized to restore the layout. However this is NOT what is wanted. Sure, that's the first thing comes to my mind. Let the client save a cookie or an encrypted blob, that it can pass back to the server when it creates the windows again. /handwaving/ When I say that I have not heard anyone working on it, it really means I do not have nor seen any plan *yet*. It is a complicated issue, which cannot be designed in an email, and especially not by me. I wouldn't say it's that much of a handwave: it's actually exactly what we came up with a couple of years ago when we were talking about session management and persistent state. Seemed to be the best option indeed. But, like you say, no-one's really approached it yet. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Bug 78372 - create multiple windows with offset
On 05/09/2014 12:34 AM, Pekka Paalanen wrote: Possibly you are reading the words save/restore literally, in that you are imagining some blob of data stored in the compositor that is recognized to restore the layout. However this is NOT what is wanted. Sure, that's the first thing comes to my mind. Let the client save a cookie or an encrypted blob, that it can pass back to the server when it creates the windows again. /handwaving/ That is what I was worried about. This will not work, as we need layouts that work the first time the client is run, that can be used by different compositors, and can port to non-Wayland systems. The client has no clue whatsoever on e.g. what positions on an output might be ok, what else is on the screen, or which outputs would be ok to conquer. You also might be on a tiling compositor, where your expectations simply totally fail. Your program would have to be a mind-reader to get the initial layout right for any user. I have no problem with the compositor moving the windows from the client's expected positions. It is a *HINT*. Clients can probably assume that if they reuse the positions from a previous run on the same compositor with the same outputs, they will get the same positions. I think also they can assume that if a window has a smaller x value than another it will be further to the left. That is all I am trying to get. I think an x/y position in some global space will fulfill these requirements and anything more complex is unnecessary and confusing, as well as making it impossible to port these positions to other operating systems. I think it is acceptable that the actual client api is output+x+y along with another api that says the x+y of the corner of each output is this. Then the client can do the conversion from global x/y to per-output x/y. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Bug 78372 - create multiple windows with offset
What should happen if the user unplugs monitors, or adds an additional one, or repositions them? What should be restored where? On Wed, May 7, 2014 at 4:10 PM, Bill Spitzak spit...@gmail.com wrote: Good to see there is an actual bug on this, but I need to ask for our exact case: Our app can be configured to have 2 (well actually any number) of windows. Normally each window is maximized or fullscreen on a different output. User expects to be able to rearrange the windows, change their size and whether they are fullscreen/maximized, and then do save layout, and later when they run the software again or do a load layout they get EXACTLY the same arrangement of windows. In particular the windows must not be on different outputs than they were previously, they cannot overlap and there must be absolutely no way they can be swapped no matter what order the client creates them. Preserving the exact size and position is less important. In particular I have no problem with the compositor moving the windows if they do not fit on the current outputs. It is also acceptable for maximized or fullscreen to be more important than the size if the output changes size. It is nice to not change the size without a good reason however. If you want example clients, take a look at Nuke or Maya or 3DStudioMax or Photoshop or Blender or virtually every other application in special effects or video editing. As far as I can tell, Wayland explicitly makes this impossible. Requiring a special compositor is not acceptable as we need to run more than one piece of software on the same machine simultaneously. I would greatly appreciate an answer to this question: is Wayland not going to support this, or is there a plan to do so? On 05/07/2014 02:51 AM, Rohit Nandan wrote: Please go through this NOTABUG bug. https://bugs.freedesktop.org/show_bug.cgi?id=78372 Rohit Nandan ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Bug 78372 - create multiple windows with offset
On 05/07/2014 10:54 PM, Pekka Paalanen wrote: This is similar to session save/restore, lacking a better term for it. We do not even pretend to support or enable this yet. It is just yet one more feature that the shell protocol suite for desktop should cover, but so far no-one has done any work on it AFAIK. If there is not one already, you are welcome to open a feature request bug about application layout save/restore. But the only practical method I can see is to allow the client to query and set the output and x/y position of any surface directly. For portability it would help if each output was given an x/y in some global space so that only a single x/y must be stored (it is ok if the client has to translate from global x/y to output + x/y, but there is a requirement that the compositor can be queried for these output x/y). As any such x/y position has been explicitly stated as being disallowed by Wayland, I am a bit stumped as to what, if any, solution is being imagined. Possibly you are reading the words save/restore literally, in that you are imagining some blob of data stored in the compositor that is recognized to restore the layout. However this is NOT what is wanted. Clients must be able to generate a usable layout the first time they are run, they must be able to do something intelligent if the set of windows changes from that in the saved layout, and use a layout from one system on another (including cross-platform), and be able to choose layouts from a list and add the current layout as a new item on the list. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Bug 78372 - create multiple windows with offset
I don't know how you can have been on the Wayland mailing list for this long and not grasp core Wayland protocol concepts. Clients cannot get global surface positions, and it's been that way since day 1 six years ago. I also have never seen a patch or a line of code from you, ever. It's incredibly frustrating to talk to you, since you seem to have your own imagination of what the Wayland protocol is, and what it provides to clients. Go and write a simple Wayland client, read the wayland.xml file, do anything to try to understand the actual Wayland protocol as it exists today. Until you show that you've made some attempt at properly understanding the protocol today, I'm going to ignore all messages from you, since you're just wasting my time otherwise. On Thu, May 8, 2014 at 1:52 PM, Bill Spitzak spit...@gmail.com wrote: On 05/07/2014 10:54 PM, Pekka Paalanen wrote: This is similar to session save/restore, lacking a better term for it. We do not even pretend to support or enable this yet. It is just yet one more feature that the shell protocol suite for desktop should cover, but so far no-one has done any work on it AFAIK. If there is not one already, you are welcome to open a feature request bug about application layout save/restore. But the only practical method I can see is to allow the client to query and set the output and x/y position of any surface directly. For portability it would help if each output was given an x/y in some global space so that only a single x/y must be stored (it is ok if the client has to translate from global x/y to output + x/y, but there is a requirement that the compositor can be queried for these output x/y). As any such x/y position has been explicitly stated as being disallowed by Wayland, I am a bit stumped as to what, if any, solution is being imagined. Possibly you are reading the words save/restore literally, in that you are imagining some blob of data stored in the compositor that is recognized to restore the layout. However this is NOT what is wanted. Clients must be able to generate a usable layout the first time they are run, they must be able to do something intelligent if the set of windows changes from that in the saved layout, and use a layout from one system on another (including cross-platform), and be able to choose layouts from a list and add the current layout as a new item on the list. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Bug 78372 - create multiple windows with offset
On 05/08/2014 11:31 AM, Jasper St. Pierre wrote: I don't know how you can have been on the Wayland mailing list for this long and not grasp core Wayland protocol concepts. Clients cannot get global surface positions, and it's been that way since day 1 six years ago. Yes I know that. I said EXACTLY that in my email: As any such x/y position has been explicitly stated as being disallowed by Wayland... Maybe my email is hard to read. I have a SIMPLE question: Can you supply a vague idea on how you imagine a client can control it's window layout without adding an x/y position to the api. Unless there is an answer to this question I see no reason to make a feature request that, as far as I can tell, is impossible to fulfill. I also have never seen a patch or a line of code from you, ever. I posted the same patch for the xserver for 6 months to allow it to read a different xorg.conf file. I finally got sick of being ignored and gave up, also recent xwayland can now work on a non-EGL wayland without having a special xorg.conf file, thus fixing it for me. However the underlying bug still exists and I'm sure there will be text that has to be in one xorg.conf file or the other that makes the other server choke. Maybe then somebody will fix it. I would love to work on Wayland, but until I can be confident that I am compiling and running it correctly there is little I can do. I have posted questions about whether anybody else is seeing the rendering errors in X clients, and whether EGL clients should work on a non-EGL backend, but have not gotten any response, despite the fact that I am only interested in trivial yes/no answers. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Bug 78372 - create multiple windows with offset
On Thu, May 8, 2014 at 4:13 PM, Bill Spitzak spit...@gmail.com wrote: On 05/08/2014 11:31 AM, Jasper St. Pierre wrote: I don't know how you can have been on the Wayland mailing list for this long and not grasp core Wayland protocol concepts. Clients cannot get global surface positions, and it's been that way since day 1 six years ago. Yes I know that. I said EXACTLY that in my email: As any such x/y position has been explicitly stated as being disallowed by Wayland... Maybe my email is hard to read. I have a SIMPLE question: Can you supply a vague idea on how you imagine a client can control it's window layout without adding an x/y position to the api. Clients should simply not attempt their window layout. There's a lot of issues, like hotpluggable outputs, that make it difficult for a client to do. Unless there is an answer to this question I see no reason to make a feature request that, as far as I can tell, is impossible to fulfill. I also have never seen a patch or a line of code from you, ever. I posted the same patch for the xserver for 6 months to allow it to read a different xorg.conf file. I finally got sick of being ignored and gave up, also recent xwayland can now work on a non-EGL wayland without having a special xorg.conf file, thus fixing it for me. However the underlying bug still exists and I'm sure there will be text that has to be in one xorg.conf file or the other that makes the other server choke. Maybe then somebody will fix it. xorg.conf is outdated, and really shouldn't be used in production. It's been replaced by /etc/xorg.conf.d. Xwayland shouldn't require *any* configuration. At all. If we need to configure Xwayland somewhere, we've messed up. If you're still having issues getting Xwayland up and running, you can email the list for support, or ask on the IRC channel. Keep in mind that `Xorg -config` and `Xorg -configdir` have existed for some time now, so I'm not exactly sure what your patch did. I would love to work on Wayland, but until I can be confident that I am compiling and running it correctly there is little I can do. I have posted questions about whether anybody else is seeing the rendering errors in X clients, and whether EGL clients should work on a non-EGL backend, but have not gotten any response, despite the fact that I am only interested in trivial yes/no answers. I haven't seen any rendering errors in X clients, but there's a lot of variables there. More feedback on what you're seeing, with what drivers, and on what hardware would be appreciated. EGL clients can theoretically work on a non-EGL backend for certain cases where we can poke under the hood of the FOSS stack, but neither Weston nor mutter do that. -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Bug 78372 - create multiple windows with offset
Please go through this NOTABUG bug. https://bugs.freedesktop.org/show_bug.cgi?id=78372 Rohit Nandan ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Bug 78372 - create multiple windows with offset
The rationale explained in the bug by Pekka and Emilio sounds OK to me. Explaining a bit more about your use case with your data visualization app might be helpful. What kinds of systems do you want your app to be run on? Generic desktop systems? If so, then you can't guarantee anything about utilizing hardware overlays, as the user might be watching a video at the same time, which should take HW overlay priority over your application to prevent a YUV - RGB conversion in software. If you have a special usecase like a Bloomberg terminal, then making your own shell and shell protocol like the IVI team is doing might be a better solution, so you can guarantee window position and HW utilization. The default desktop-shell is very much designed for desktop Linux use cases, where we don't want to expose global window positions or make any guarantees to the client about where they are on screen, precisely so you don't assume you are the only user of the HW. On Wed, May 7, 2014 at 5:51 AM, Rohit Nandan pulkitnan...@gmail.com wrote: Please go through this NOTABUG bug. https://bugs.freedesktop.org/show_bug.cgi?id=78372 Rohit Nandan ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Bug 78372 - create multiple windows with offset
Yes i'm working for embedded platform where with current desktop shell we cant debug two overlays visually running same apps with same size. Thanks You . Rohit Nandan On Wed, May 7, 2014 at 6:49 PM, Jasper St. Pierre jstpie...@mecheye.netwrote: The rationale explained in the bug by Pekka and Emilio sounds OK to me. Explaining a bit more about your use case with your data visualization app might be helpful. What kinds of systems do you want your app to be run on? Generic desktop systems? If so, then you can't guarantee anything about utilizing hardware overlays, as the user might be watching a video at the same time, which should take HW overlay priority over your application to prevent a YUV - RGB conversion in software. If you have a special usecase like a Bloomberg terminal, then making your own shell and shell protocol like the IVI team is doing might be a better solution, so you can guarantee window position and HW utilization. The default desktop-shell is very much designed for desktop Linux use cases, where we don't want to expose global window positions or make any guarantees to the client about where they are on screen, precisely so you don't assume you are the only user of the HW. On Wed, May 7, 2014 at 5:51 AM, Rohit Nandan pulkitnan...@gmail.comwrote: Please go through this NOTABUG bug. https://bugs.freedesktop.org/show_bug.cgi?id=78372 Rohit Nandan ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Bug 78372 - create multiple windows with offset
On Wed, 07 May 2014 13:10:31 -0700 Bill Spitzak spit...@gmail.com wrote: Good to see there is an actual bug on this, but I need to ask for our exact case: No, there is not. The bug report was not a valid bug, and is now closed. Our app can be configured to have 2 (well actually any number) of windows. Normally each window is maximized or fullscreen on a different output. User expects to be able to rearrange the windows, change their size and whether they are fullscreen/maximized, and then do save layout, and later when they run the software again or do a load layout they get EXACTLY the same arrangement of windows. In particular the windows must not be on different outputs than they were previously, they cannot overlap and there must be absolutely no way they can be swapped no matter what order the client creates them. This is similar to session save/restore, lacking a better term for it. We do not even pretend to support or enable this yet. It is just yet one more feature that the shell protocol suite for desktop should cover, but so far no-one has done any work on it AFAIK. If there is not one already, you are welcome to open a feature request bug about application layout save/restore. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
