[RFC PATCH xserver] xwayland: RFC Disable glamor with an env var?
ofourdan at redhat.com
Thu Mar 2 10:47:10 UTC 2017
> 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.
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
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
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?
> 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...
More information about the wayland-devel