[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 <ofourdan at redhat.com> 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
-------------- 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/030bebf2/attachment.sig>