<div dir="ltr">On Thu, May 8, 2014 at 4:13 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">On 05/08/2014 11:31 AM, Jasper St. Pierre wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I don't know how you can have been on the Wayland mailing list for this<br>
long and not grasp core Wayland protocol concepts. Clients cannot get<br>
global surface positions, and it's been that way since day 1 six years<br>
ago.<br>
</blockquote>
<br></div>
Yes I know that. I said EXACTLY that in my email:<div class=""><br>
<br>
>     As any such x/y position has been explicitly stated as being<br></div>
>     disallowed by Wayland...<br>
<br>
Maybe my email is hard to read. I have a SIMPLE question:<br>
<br>
"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."<br></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I also have never seen a patch or a line of code from you, ever.<br>
</blockquote>
<br></div>
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.<br>
</blockquote><div><br></div><div>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.<br>
<br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

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.<br>

</blockquote></div><br></div><div class="gmail_extra">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.<br>
<br></div><div class="gmail_extra">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.<br></div><div class="gmail_extra">
<br>-- <br>  Jasper<br>
</div></div>