[RFC PATCH xserver] xwayland: RFC Disable glamor with an env var?

[Pekka Paalanen]

On Wed,  1 Mar 2017 17:45:11 +0100
Olivier Fourdan <ofourdan at redhat.com> wrote:

> Hi all,
> 
> I am seeing quite a few Xwayland crashes related to glamor.
> 
> Various issues, could be with glamor itself or with the drivers (like the
> issues I witness with nv30), whatever.
> 
> To investigate those issues (or even unblock affected users) it's often
> useful to disable glamor -even temporarily- but Xwayland doesn't use an
> xorg.conf and relies solely on the command line.
> 
> Not all compositors allow for customizing the command line, gnome-shell
> or mutter for example have the command line and path to the Xwayland binary
> hardcoded, which makes it harder for users to disable glamor acceleration
> in Xwayland by adding -shm to the command line (glamor being used by
> default).
> 
> Would adding an environment variable such as XWAYLAND_NO_GLAMOR (similar
> to what Xephyr does with e.g. XEPHYR_NO_SHM) make sense here? 
> 
> I tried and it works with the following patch added, by setting the
> environment variable XWAYLAND_NO_GLAMOR in a /etc/profile.d/ script on
> Fedora 25.

Hi,

I understand the attractiveness of adding an override, bypassing the
compositors like this. But, essentially it is just that: a
configuration bypass.

I would prefer leaning towards just making the compositors more
considerate about their Xwayland configuration. I believe the global
trend is to move towards the compositor having all the configurability
in itself, and all the other components having a single source of
configuration in the running system: the compositor. I would compare
Xwayland to libinput here.

I realize recognizing glamor issues is a pain at the moment as you
don't have a setting to disable glamor. However, the environment
variable you suggest needs to be already set when the compositor
starts. You suggest an /etc/profile.d/ script, which requires root to
set up. I might ask if adding that env var to avoid writing a script,
replacing the Xwayland binary, to exec the original Xwayland binary
with an additional command line argument is that much of an improvement?

Xwayland is not a program launched manually, but Xephyr is, isn't it?
That makes an env var very convenient with Xephyr, less so with
Xwayland.

Are there already other env vars useful with Xwayland (debugging)?

Are there other features in Xwayland one might want to configure too?
Should Xwayland get its own configuration file a la xorg.conf, or
should we go with just arguments passed from parent process (the
compositor)?

Here's another thought:

If the compositor detects that Xwayland crashed, maybe it could
automatically disable glamor when restarting Xwayland? Or show a dialog
saying what happened and let the user choose whether to try with or
without glamor the next time to help diagnose the issue?

I suppose that's not an option for gnome-shell as gnome-shell crashes
with Xwayland, does it not? Maybe in the future it could though?


This is just food for thought, I don't want to NAK this patch just by
my own opinion.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170302/36b2b091/attachment-0001.sig>