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

[Olivier Fourdan]

Hi Pekka,

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

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

Yes, but that means that all compositors need to have this "configurability", even though it's actually Xwayland that uses it.

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

That's what I use myself, when I am debugging an issue, but but it's no so practical to tell users top write a wrapper script, rename the binary from their distro package and replace it with their own script... That's precisely why I am looking in other solutions.

As glamor also depends on the drivers and thus the hardware, there are issues (including rendering issues) that I can never reproduce myself.
 
> 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.

I have seen glamor issues with Xwayland that do not show up in Xephyr, we cannot always use Xephyr to investigate glamor issues (or the underlying layers), https://bugs.freedesktop.org/show_bug.cgi?id=99400 is one of them...

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

Not that I am aware, except GLAMOR_DEBUG.
 
> Are there other features in Xwayland one might want to configure too?

Not really, I was starting to write a man page for Xwayland and realized few options are actualy to any use for the reguilar user, as Xwayland is mostly useful when started by the compositor.

> Should Xwayland get its own configuration file a la xorg.conf, or
> should we go with just arguments passed from parent process (the
> compositor)?

I thought of that, but deemed it a overkill :)
 
> 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?

That's an ideal workld unfortunately, mutter requires Xwayland t orun and won;t survive a crash in Xwayland (unlike weston), so if Xwayland dies s does the entire gnome-shell Wayland session.

Besides, that won't help much with rendering issues with glamor.

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

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

Yeap, I appreciate your views and share most of them, I am not a big fan of environment variables for such purpose either (that's why I sent this patch as an RFC), but I've felt many times that frustration of not being able to tell simply to a user to try Xwayland without glamor...

Cheers,
Olivier