Bug 78372 - create multiple windows with offset

[Bill Spitzak]

On 05/08/2014 01:34 PM, Jasper St. Pierre wrote:

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

Yes. However older x servers do require xorg.conf(.d) to exist and 
contain lots of text, all of which should be irrelevant to xwayland, and 
possibly causing odd problems (as the file certainly is parsed and sets 
internal data in the x server). As currently written a user must use 
sudo to hide/rename any required xorg.conf file before running xwayland 
if they want to try the "no configuration" option.

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

My patch did two things:

1. Made it default to xwayland.conf(.d) when --wayland is provided. User 
can still use --config and --configdir make it read xorg.conf(.d) but it 
made a lot more sense to have one switch to make xwayland work rather 
than three.

2. Fixed a bug in xserver so that if the command-line switch selected .d 
directory is not found it does not read xorg.conf.d but instead acts 
like no configuration was found, thus allowing the built-in wayland 
default to be used.

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

This is running on the X11 compositor, on a wayland/weston where EGL 
clients do not work, but SHM ones appear to work fine. Previously this 
required a custom xorg.conf file so xserver avoided EGL, which is what 
led to the above patch. Recent xwayland seems to figure out that EGL 
will not work and render using SHM, thus avoiding the patch, though I do 
wonder if the contents of my xorg.conf are screwing things up.

Main bug is that parts of the frame are either missing or drawn 
incorrectly. In particular the shadow is often drawn reversed. Attached 
is the same screenshot I sent long ago, the bugs are the same.

It also is exposing what I think is a bug in fltk, where fltk may be 
relying on some event from X window managers that is not sent. It acts 
like it does not think the mouse is pointing at the window until after 
you resize the window some. Though this is a bug in fltk, it may be 
based on an assumption that many X clients make, so it may be better to 
make xwayland emulate whatever is being relied on.

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

Okay that sounds like no.

I was more imagining that an EGL client would talk to Mesa, which would 
then use software rendering to produce images that are passed through 
SHM to Wayland. I was not interested in speed, just getting an image.

It may be best to not work. Otherwise too many things could accidentally 
make EGL/GL slow by triggering the software rendering. Also I guess this 
would require adding a lot more wayland to Mesa.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xevInXWaylandOnX11.png
Type: image/png
Size: 19178 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140508/f325a638/attachment-0001.png>