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

[Olivier Fourdan]

Hi Jonas,

> > > 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.
> > 
> 
> For a compositor that supports respawning Xwayland, to be able to change
> the Xwayland configurations without restarting the actual compositor
> would still need this "configurability", as any user set environment
> variable will be static for the whole session.

Obviously, with a compositor able to survive respawning Xwayland, adapting the 
Xwayland command line options dynamically when it detects a crash in Xwayland, 
the use of environment variable is a lot less attractive.

But I am not aware of any compositor able to do that (and given how mutter is 
dependent on X even on Wayland, I would not expect such a mechanism to be 
available in gnome-shell any time soon).

Cheers,
Olivier
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

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

[Jonas Ådahl]

On Thu, Mar 02, 2017 at 05:47:10AM -0500, Olivier Fourdan wrote:
> 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.
> 

For a compositor that supports respawning Xwayland, to be able to change
the Xwayland configurations without restarting the actual compositor
would still need this "configurability", as any user set environment
variable will be static for the whole session.


Jonas
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

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

[Pekka Paalanen]

On Thu, 2 Mar 2017 05:47:10 -0500 (EST)
Olivier Fourdan  wrote:

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

Indeed, the same arguments as with libinput.

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

I meant that "Xephyr uses env vars, Xwayland should too" was not exactly
a good justification to add any env vars to Xwayland due to how
Xwayland vs. Xephyr get launched.

> > Are there already other env vars useful with Xwayland (debugging)?  
> 
> Not that I am aware, except GLAMOR_DEBUG.

That's a precedent, at least.

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

Yes, I understand.

I wonder if you'd like to have more toggles in your Wayland stack,
though, e.g. disable certain aspects of hw-accel or hw-accel completely
in the compositor too. Like Weston/DRM has --use-pixman which
consequently causes Xwayland to fall back from GLAMOR. But you probably
use LIBGL_ALWAYS_SOFTWARE or something for that, right?

What about GLAMOR with software-GL? Or forcing GLAMOR to use a GL
flavour it normally would not pick because another one more suitable is
available? I suppose those would be controlled via Mesa env vars, but
then how do you set them only for Xwayland so they don't affect your
compositor too?


Thanks,
pq


pgpTr5sD2sCyS.pgp
Description: OpenPGP digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [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
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

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

[Pekka Paalanen]

On Wed,  1 Mar 2017 17:45:11 +0100
Olivier Fourdan  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


pgpyuP3PNH25Y.pgp
Description: OpenPGP digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel